W3C home > Mailing lists > Public > public-media-fragment@w3.org > December 2008

Re: byte-range redirection

From: Yves Lafon <ylafon@w3.org>
Date: Mon, 1 Dec 2008 05:23:01 -0500 (EST)
To: Conrad Parker <conrad@metadecks.org>
cc: Media Fragment <public-media-fragment@w3.org>
Message-ID: <Pine.LNX.4.64.0812010508480.6555@ubzre.j3.bet>

On Sat, 29 Nov 2008, Conrad Parker wrote:

>
> Hi,
>
> Regarding the method of retrieving media data in two parts over HTTP,
> I think the term "4-way handshake" is a bit of a misnomer. The word
> "handshake" implies protocol setup, whereas what we're really talking
> about is a two-part request, where the first typically retrieves a
> small but not insignificant amount of data (~10-100kB) which is
> particular to the subview being requested -- media headers, keyframes
> etc. As that data is necessary and immediately useful, I think it
> would be incorrect to say that this method adds any appreciable
> latency to the media request.

I wouldn't call it a two-part request, as it's two different requests, 
completely unrelated (as seen form the server). The first request is to a 
new resource with a non-video media type, and the second is a byte-range 
request on another URI to retrieve part of the compressed video.

> Further, use of this method is optional, such that if the user agent
> does not specify to do so in the HTTP request headers then it simply
> receives all the data immediately as a normal GET request.
>
> Perhaps it would be more accurate to talk about an (optional)
> byte-range redirection than a handshake.
>
> cheers,
>
> Conrad.
>

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

         ~~Yves
Received on Monday, 1 December 2008 10:23:10 GMT

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