Re: Review of section 7

On Tue, 14 Apr 2009, Silvia Pfeiffer wrote:

>>> and MPEG-1 for the temporal dimension. I don't think this is the case
>>> for many other formats. Even for MP3 an MPEG-1, I don't think they are
>>> capable of storing that they are extracted from a parent resource at a
>>> certain in and out time.
>>
>> Ok, so you want to rule out completely extracting a fragment from a
>> resource.
>
> No, not at all. I am just saying that using the 1-GET request method
> implies that most - if not all - fragmented media resources will not
> be cachable in Web proxies.

You mean they will not be cached by most Web proxies, not "not 
cachable", no?

> Why are you talking about reverse proxies? Why not just have that
> functionality in the Web server itself? In fact, I was not referring
> to a reverse Web proxy.

Between a heavy Web server that is also doing cache, dynamic content 
etc... and a more simple server with a reverse proxy, the latter usually 
wins in term of performance.

> I was talking about caching Web proxies. So let's say the 5h long
> video takes up 3GB. Across a 100MBit pipe that we can flood with the
> video, it will take 4min to get that video into the Web proxy, where
> it then does the extraction and transfers the last 2 min. I don't
> think that is acceptable. That is what I meant by "defeating the
> purpose of fragmenting" because the idea of fragment delivery is to
> avoid the long delay required by downloading the full resource (even
> if this delay is smaller since it's not across a low-bandwidth
> consumer link, but a higher bandwidth Internet link).

Well, such cache won't do that for sure, they will probably cache the 
fragment, and if it is a general purpose cache, will flush it for a 
subsequent request. (and if it is a busy cache, it may be flushed way 
before another access to that video is made).

>>>>> * further we need to mention that there are encapsulation formats
>>>>> (such as MP4) that have an index in their headers that can provide a
>>>>> seconds->byte mapping for any offset. For such cases, an optimisation
>>>>> is possible where a client retrieves the index part of the media file
>>>>> first and then uses that to make byte range requests rather than time
>>>>> range requests. These requests are cachable by any caching Web proxy
>>>>> without replication for differing fragment requests. This is in fact a
>>>>> third means of retrieving fragment URIs, which we might want to make
>>>>> explicit as a section 7.3.
>>>>
>>>> This is needed for both options, btw.
>>>
>>> Which both options? I am confused. I thought about this as an
>>> alternative to the single-GET and the two-GET request.
>>
>> I wanted to say that having a way to do the seconds->byte mapping is always
>> needed, I read too fast that it was in the header :)
>
> OK. :-)
>
>
>> So you propose that every client should do
>> GET http://example.com/fragf2f.mp4 HTTP/1.1
>> Accept: video/*
>> Range: bytes=0-65535 (or anything big enough to get the data headers)
>>
>> then based on what is retrieved, do another partial GET based on what the
>> client mapped between the seconds and the bytes, right ?
>
> It depends how far we want to take this. If we decide the best means
> to deal with such special formats is to always do a request on the
> beginning of the file to retrieve the index part before we do anything
> else, that's possible. I was thinking more about the possibility for a
> User Agent to do an internal improvement once it had received the
> index in a previous retrieval request. Any consecutive media fragment
> URI request can use this knowledge to avoid the need to do a seconds
> range request, but to directly do a bytes range request.

How about something along those lines.
a GET of the media header (so a few bytes, depending on how much is 
enough), and the server answers with that + one or more Link: headers 
linking to different mappings (time to bytes is an example) or at least a 
resolver URI, linking to the sub-resource, to parent etc...

>> It should already work now without changing anything, without using a
>> X-Accept-Range-Redirect header.
>
> You're probably right. Ultimately it is an optimisation that the User
> Agent can make and doesn't need to be included in this standard. We
> can however point out that for some formats there is the possibility
> to identify the byte range mapping from their header and that a User
> Agent can optimise their approach for this.

It's the same for caches, the strategy to cache or not is dictated by 
implementation choice and configuration choices. So we shouldn't say 
anything, implementers are smart enough to realize that one choice will 
fly or not :)

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Tuesday, 14 April 2009 13:49:38 UTC