W3C home > Mailing lists > Public > public-media-fragment@w3.org > November 2008

Re: Squid experts

From: Jack Jansen <Jack.Jansen@cwi.nl>
Date: Mon, 3 Nov 2008 13:45:27 +0100
Cc: "'Media Fragment'" <public-media-fragment@w3.org>
Message-Id: <B9F3964E-B9BB-4F74-BD40-FCA2957B1E7E@cwi.nl>
To: Davy Van Deursen <davy.vandeursen@ugent.be>


On 1 nov 2008, at 22:52, Davy Van Deursen wrote:

> If we want to support caching of media fragments without modifying the
> existing Web caches and proxies, then this will only work under the
> following circumstances (and suppose multi-byte-ranges are possible):
> 1) the media fragments can be extracted in the compressed domain
> 2) no syntax element modifications in the bitstream are needed to  
> perform
> the extraction
>
> Note that one workaround for point 2 is that the server sends the  
> headers
> with the modified syntax elements to the client (as you did with the  
> Ogg
> format). However, I don't think that this workaround will work in  
> general
> for each format.

Davy,
I would think that any format that can be streamed over RTSP must meet  
these 2 requirements: otherwise the RTSP server would have to do  
recoding on the fly when the user agent does a seek.

If we limit support for temporal fragments to media that meet  
requirements (1) and (2), and if RTSP has the same requirements, it  
seems that it isn't really limiting our support. Moreover, if the  
server does support fragments on media items that need to be recoded  
it is in the position to forestall caching by sending out rttp reply  
headers to that effect, or not?
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman
Received on Monday, 3 November 2008 12:46:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:31 GMT