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:48:28 -0500 (EST)
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
cc: Conrad Parker <conrad@metadecks.org>, Media Fragment <public-media-fragment@w3.org>
Message-ID: <alpine.DEB.1.10.1003090338040.26153@wnl.j3.bet>
On Tue, 9 Mar 2010, Silvia Pfeiffer wrote:

> While I do not quite understand Conrad's use case, I agree partially
> (and maybe fully) with the objection to that resolution.
>
> I think we can continue using "Range" as the request header from the
> client for all of the dimensions we are talking about (Range on bytes,
> t, track and id).
>
> But, I do not believe we can use "Content-Range" as the reply header
> for any of the dimensions bar bytes. This is why we introduced
> "Content-Range-Equivalent".

You have video foo

   ----------------------------------------
   | H  |    data                         |
   ----------------------------------------
s      0    10   20                      60
b 0  8192 16384 32768                  65536

(for seconds and byte scales)

Why? Look at the example:
GET /foo HTTP/1.1
Host: www.example.com
Range: t:npt 10-20

You get back this:

HTTP/1.1 206 blah
Content-Range: t:npt=10-20/60
Content-Range-Equivalent: bytes=16384-32768/65536

But what you get is really a playable video, with a synthetic header
So the data is
  --------------------------
  | HS |                   |
  --------------------------
s     0                  10
b    4096              20480

So if you reply with Content-Range in byte, it won't work because of the 
presence of the synthetic header, and the fact that it can't match the 
original data stream. What is interesting is to save the 16k chunk sent 
back and map it to the byte range, so that client asking for byte ranges 
after that will get what it needs.

Sending back more data than expected, or a byte ranges with byte that 
can't correspond to the original byte stream can't work with old proxies.

>
> Incidentally, I have a few more questions on that resolution:
> * why are we using comma as a separator for track HTTP headers?
> * also note that the spatial dimension can be resolved on the client
> as in Davy's demo rather than sending anything to the server.
>
> Cheers,
> Silvia.
>
>

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

         ~~Yves
Received on Tuesday, 9 March 2010 08:48:31 GMT

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