W3C home > Mailing lists > Public > public-media-fragment@w3.org > April 2009

Re: Review of section 7

From: Yves Lafon <ylafon@w3.org>
Date: Sun, 12 Apr 2009 14:55:04 -0400 (EDT)
To: Conrad Parker <conrad@metadecks.org>
cc: Media Fragment <public-media-fragment@w3.org>
Message-ID: <Pine.LNX.4.64.0904121449250.23968@ubzre.j3.bet>
On Mon, 13 Apr 2009, Conrad Parker wrote:

> 2009/4/13 Yves Lafon <ylafon@w3.org>:
>> 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 :)
> HTTP/1.1 byte-range caching is a format-agnostic method, and already
> specified in an established standard. This WG has already determined
> that format-specific media proxy caching is not necessary for at least
> Ogg and MP4. If it is necessary for any other formats, we need to
> specify in detail what the format developers need to implement.

Oh, did I miss that byte range was in rfc2616 and httpbis drafts?
Can you point me to the decision saying that format-specific caches were 
not wanted?
The merging algorithm depends on the format, and it is not this WG's task 
to specify the algorithm. It is up to implementers and format 

>>>   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.
> What is the use-case for both HTTP request headers?

Do the mapping between seconds and bytes.

> I haven't yet seen a use for Range units other than bytes that does
> not cause complications :-)

You think that the use of byte unit is without complications? :)

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

Received on Sunday, 12 April 2009 18:55:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:42 UTC