RE: Squid experts

Hi Jack,

>-----Original Message-----
>From: public-media-fragment-request@w3.org [mailto:public-media-
>fragment-request@w3.org] On Behalf Of Jack Jansen
>Sent: Monday, November 03, 2008 1:45 PM
>To: Davy Van Deursen
>Cc: 'Media Fragment'
>Subject: Re: Squid experts
>
>
>
>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.

I do not agree that these two points are requirements to stream media
fragments over RTSP in general. On server side, syntax element modifications
can be performed on the fly. Also, if a server has some transcoders at its
disposal, on the fly transcoding of the media fragments is also possible, or
not? As long as you stay on the server side, all possible operations can be
performed to obtain the requested fragments. However, when proxies need to
be taken into account (and we do not want to modify them), you should be
able to express these server-side adaptation operations in terms of byte
ranges. In order to express an adaptation operation in terms of byte ranges,
the two above described requirements are necessary.

>
>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?

Do you mean that in the case of recoding, we do not cache the fragment at
all? Of course, if we do not make any changes on the caches, then we are
stuck to these byte ranges and is indeed the caching of a recoded fragment
impossible. However, it would be nice if the cache really understands the
concept of a fragment and does not (only) rely on byte ranges to cache the
fragment. But that, I think, will not be an easy task :-).

Best regards,

Davy

--
Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems Multimedia Lab
URL: http://multimedialab.elis.ugent.be

Received on Monday, 3 November 2008 14:17:27 UTC