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: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 9 Mar 2010 20:09:52 +1100
Message-ID: <2c0e02831003090109m1edff51albb5cd9caeba3772d@mail.gmail.com>
To: Conrad Parker <conrad@metadecks.org>
Cc: Yves Lafon <ylafon@w3.org>, Media Fragment <public-media-fragment@w3.org>
On Tue, Mar 9, 2010 at 7:51 PM, Conrad Parker <conrad@metadecks.org> wrote:
> 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.
> Conrad.
>>> 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.

I think I am starting to understand: what if we want to do what all
the browser vendors do: download a resource successively? But we only
want to do it for a specific fragment?

I would think the byte ranges should actually be enough for that - the
UA can administer what fragment it needs. No?

Received on Tuesday, 9 March 2010 09:10:45 UTC

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