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: Yves Lafon <ylafon@w3.org>
Date: Tue, 9 Mar 2010 03:37:52 -0500 (EST)
To: Conrad Parker <conrad@metadecks.org>
cc: Media Fragment <public-media-fragment@w3.org>
Message-ID: <alpine.DEB.1.10.1003090331200.26153@wnl.j3.bet>
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?

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

> 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:37:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:38 GMT