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

Re: Squid experts

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 6 Nov 2008 09:32:01 +1100
Message-ID: <2c0e02830811051432t2ac84457ie84794a09dc92161@mail.gmail.com>
To: "Davy Van Deursen" <davy.vandeursen@ugent.be>
Cc: "Jack Jansen" <Jack.Jansen@cwi.nl>, "Media Fragment" <public-media-fragment@w3.org>

Hi Davy, Jack, all,

On Tue, Nov 4, 2008 at 1:00 AM, Davy Van Deursen
<davy.vandeursen@ugent.be> wrote:
>>From: public-media-fragment-request@w3.org [mailto:public-media-
>>fragment-request@w3.org] On Behalf Of Jack Jansen
>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
>>>
>>
>>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.

I am not sure how this works with RTSP. However, we cannot do
transcoding on the fly for media resources on HTTP. Transcoded
resources are not bit-wise identical to the original media resource
and can therefore not be cached in Web proxies. Then the media
resource becomes identical to an output of a script that is different
each time and therefore not a cachable resource. So, I'd prefer it if
we could accept those two conditions.


>>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 :-).

Even if the cache understands codecs, how can it deal with several
fragments that each have been recoded to meet the fragment needs? I
cannot easily serve them by concatenation. It would need to do another
recoding - and this time not from one file, but from multiple recoded
fragments. Do you really think that is possible? And without loss of
quality??

Cheers,
Silvia.
Received on Thursday, 6 November 2008 02:56:15 GMT

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