W3C home > Mailing lists > Public > public-media-fragment@w3.org > March 2010

Re: bandwidth conservation use case, objection to use of Range for non-byte sections

From: Conrad Parker <conrad@metadecks.org>
Date: Tue, 9 Mar 2010 17:51:13 +0900
Message-ID: <dba6c0831003090051u526fe33eu1cbaa33385db404d@mail.gmail.com>
To: Yves Lafon <ylafon@w3.org>
Cc: Media Fragment <public-media-fragment@w3.org>
On 9 March 2010 17:37, Yves Lafon <ylafon@w3.org> wrote:
> On Tue, 9 Mar 2010, Conrad Parker wrote:
>> Hi,
>> I would like to introduce a use cases that is not covered by the
>> existing specification: that a user agent may wish to retrieve a media
>> resource in chunks, so that the amount of content buffered ahead of
>> the user's current play position does not grow too large.
>> In order to handle this use case, i propose to introduce a new HTTP
>> Request and Response header pair. Following the naming of yesterday's
>> F2F discussions, these could be Range-Equivalent and
>> Content-Range-Equivalent; they could similarly be part of whatever
>> Fragment and Content-Fragment are now being called. Let's call it Foo.
>> The syntax would be as has been suggested for non-byte dimensions of
>> Range/Content-Range.
>> Then, a user agent wishing to retrieve the first 10kB of the resource
>> http://example.com/video.ogv#t=10,20 would translate this into:
>> Range: bytes=0-10000
>> Foo: t:npt=10-20
>> An origin server would respond with:
>> Content-Range: bytes 0-10000/*
>> Content-Foo: t:npt 10-20/0-75
>> Vary: Content-Foo
> Does it mean that you are 100% sure that the time interval will match to the
> byte the byte interval?

No, I don't expect that and it is not relevant.

> Your use case is better addressed through heuristics and using only byte
> ranges. (with some part of decoding, you can infer the average amount of
> bytes for some amount of time).

That would address a different concern. Here I'm simply talking about
transferring the data for 10-20s a few kB at a time.


>> The use of a header other than Range for non-byte sections has various
>> advantages:
>> 1. As a consequence, an existing, HTTP/1.1 compliant intermediate
>> caching proxy would cache this response and could re-use it when
>> providing all or part of a subsequent request for
>> http://example.com/video.ogv#t=10,20. For example, the response
>> containing only the first 5kB of the resource would be:
>> Content-Range: bytes 0-5000/*
>> Content-Foo: t:npt 10-20/0-75
>> Vary: Content-Foo
>> Such a caching proxy would separately cache parts of the response
>> generated by the origin server for
>> http://example.com/video.ogv#t=30,40 as indicated by the Vary header.
>> 2. This mechanism can be used in cases where the client specifies only
>> "Accept-Ranges: bytes" (ie. all current browsers and proxies)
>> 3. Only the media-related URL translation parts of user agents and web
>> servers would require modification to support this mechanism; whereas
>> if a new Range dimension is introduced, the transport portions of web
>> servers, the caching portion of user agents, and the caching portion
>> (ie. all) of caching proxies and content distribution networks would
>> need to be re-implemented to allow such ranges to be cached.
>> Semantically, I see the Foo header as describing a desired
>> representation (much like language handling), but Range has a
>> lower-level function related to transport and caching. I think it is
>> useful to allow both concerns to be handled by HTTP, which is
>> difficult if Range is overloaded.
>> I think it is useful to agree on a specification that meets the aims
>> of this working group without requiring all WWW implementations to be
>> rewritten. Hence I object strongly to
>> http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers
>> and instead suggest the use of this minor variation that does not
>> overload the existing Range/Content-Range transport mechanism.
>> Concerning the process of resolutions: I was not present for that
>> resolution as it was after midnight here, and had already raised this
>> objection and suggestion during the teleconf prior to its discussion.
>> cheers,
>> Conrad.
> --
> Baroula que barouleras, au tiéu toujou t'entourneras.
>        ~~Yves
Received on Tuesday, 9 March 2010 08:51:46 UTC

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