Re: Review of section 7

On Mon, 13 Apr 2009, Silvia Pfeiffer wrote:

>>> * we need to mention that the replies are not cachable for the full
>>> resource, but cache only the fragmented resource, which can result in
>>> n copies of some subset of the resource in caching web proxies. Since
>>> it is typically expected that a fragment request will be used
>>> repeatedly (e.g. a fragment URI being shared around), this is
>>> potentially acceptable. But we have no experimental data to confirm or
>>> deny that this may pose a challenge to caching web proxies.
>>
>> Why? it is the case only if the cache can't handle merging timed fragment,
>> which is the case of general purposes caches (they will handle only bytes),
>> but media procies might be able to do so. Once again, it is not sure that
>> they will do that as requesting the whole resource and serve fragments from
>> the cache might be more efficient for such caches anyway :)
>
> What I meant to say with this is: when every media fragment URI on a
> parent resource returns a file that is not a byte-identical subsegment
> of the parent resource, the cache has to eventually store a full copy
> of the original file and n fragmented versions. The only media format
> that would be capable in the single-GET request case to return
> byte-identical subsegments is one that does not require any header
> changes to return a valid resource. I think this is the case for MP3

You mean retrieving the whole resource? or by header you say "data format 
header" (the latter I think)

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

> My point therefore was: where fragmented versions are not a
> byte-identical subpart of the parent resource, merging fragmented
> versions is basically impossible, even for intelligent media proxies,
> simply because splicing in the compressed domain (and we may talk
> re-compressed here) is a futile effort. Therefore they will end up

Well, of course if it is re-compressed, it is impossible to merge things, 
unless it is a lossless compression, as in that case you can 
compress/recompress without changing the content. I can't see lossless 
video anytime soon ;)

> with n copies, unless they trick the system and (as you say) download
> the full resource, but do the fragmenting themselves, which defeats
> the purpose of media fragments for the first time a fragment request
> is being undertaken (think about a 5 hour long video where the client
> requests the last 2 minutes).

Why are you saying that it defeats fragmenting? My point was that for some 
proxies, the one that are likely to really have to deal with lots of 
traffic and content (mostly reverse proxies), the cost of transfer was 
pretty low (fast pipes), and even getting the ful 5h video to extract 2mn 
might be efficient. I am not talking about the proxy on someone's local 
network behind a 28.8kbps modem.

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

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 should already work now without changing anything, without using a 
X-Accept-Range-Redirect header.

>
>
>>>   Example:
>>>
>>>    GET http://example.com/fragf2f.mp4 HTTP/1.1
>>>    Accept: video/*
>>>    Range: seconds=12-21
>>>    X-Accept-Range-Redirect: bytes
>>
>> One thing that I wonder is what happen if the reply is with two Range:
>> header, one in bytes, one in seconds.
>
> I think that firstly User Agents should be discouraged from sending a
> byte range request at the same time as a different range request.

sending a 'seconds' range request, and receiving both, but the more I 
think about it, the more I think a server not knowing this will just 
discard the whole thing :)

> However, if this happens, I would suggest that the byte range request
> has the higher priority. I don't think it would make sense that a
> server should be expected to resolve a seconds request and merge it
> with a given byte range request.
>
>>
>>> with the following:
>>>   1. map the given range type from seconds (or whatever else is given) to
>>> byes
>>>   2. reply with a X-Accept-TimeURI header that indicates to the
>>> client that is has processed the time request and converted to bytes
>>> (similarly this could be extended to X-Accept-SpaceURI,
>>> X-Accept-TrackURI, and X-Accept-NameURI). Incidentally, this part
>>> should probably also be added to section 7.1 so we can generally
>>> indicate that it's a fragment that is being returned and not the full
>>> resource.
>>>   3. create the control section of the partial resource, which is
>>> specific to this fragment URI and not cacheable.
>>>   4. return this control section in the content of the reply.
>>
>> Even in case of Accept: video/* ? (we will keep that for after the
>> publication, as it is a technical issue)
>
> Yes. In the example case of Ogg Theora, we have a video/* accept MIME
> type, but Ogg Theora requires a special control section to create a
> valid Ogg Theora resource.
>
> Cheers,
> Silvia.
>

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

         ~~Yves

Received on Tuesday, 14 April 2009 09:36:19 UTC