Re: Review of section 7

Hi Yves, all,

On Mon, Apr 13, 2009 at 3:42 AM, Yves Lafon <ylafon@w3.org> wrote:
> On Sun, 12 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
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.

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


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


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

Received on Monday, 13 April 2009 06:01:13 UTC