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

RE: Description of the 2-ways and the 4-ways handshake

From: David Singer <singer@apple.com>
Date: Thu, 19 Mar 2009 16:54:13 -0700
Message-Id: <p06240878c5e88b66efc4@[]>
To: Davy Van Deursen <davy.vandeursen@ugent.be>, 'RaphaŽl Troncy' <Raphael.Troncy@cwi.nl>
Cc: 'Media Fragment' <public-media-fragment@w3.org>
Of course, as I have previously pointed out, for 
resources with an intrinsic time->data map (like 
mov, mp4), a two-handshake usually achieves what 
we want without needing HTTP protocol extension...

but I think you knew this...

At 14:10  +0100 19/03/09, Davy Van Deursen wrote:
>Hi RaphaŽl,
>>-----Original Message-----
>>From: public-media-fragment-request@w3.org [mailto:public-media-
>>fragment-request@w3.org] On Behalf Of RaphaŽl Troncy
>>Sent: Thursday, March 05, 2009 2:45 PM
>>To: Media Fragment
>>Subject: Description of the 2-ways and the 4-ways handshake
>>Dear all,
>>I have made my stab on the description of the 2-ways and the 4-ways
>>handshake proposal. See
>  >http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_implementation
>>All comments welcome! I asked some questions (regarding the first HTTP
>>response code in the 4-ways handshake). The pro/cons need also to be
>>completed. In particular, I'm not sure about the cachability of the
>>resource in both cases?
>Regarding the pro/cons, you mention 'We create a custom Range unit' as a
>con. However, IMO this does not depend on whether we use 2-way or 4-way, but
>whether the # or ? character is used. If the # character is used, then we
>need a way to tell the server about the fragment (for instance by creating
>custom range units in case of HTTP). Hence, what do you think of the
>following pro/con list:
>* 4-way handshake:
>	+ current web proxies are able to cache media fragments
>	- two roundtrips
>* 2-way handshake
>	+ one roundtrip
>	- specialized 'media'-caches are necessary to cache media fragments
>Further, you mention that the first HTTP response (in 4-way handshake)
>includes "all additional data that cannot be cached but is required by the
>UA to receive a fully functional media resource". Shouldn't we rephrase this
>to "header data, occurring at the beginning of the media resource, that
>cannot be cached but is required by the UA to receive a fully functional
>media resource"? Otherwise, things become very complicated for the UA. Note
>that you could also mention this restriction as a con for the 4-way
>handshake (and/or a pro for the 2-way handshake). For instance, extracting a
>spatial region from a Motion JPEG2000 would not work with the 4-way
>handshake, but would work with the 2-way handshake (see also the table at
>[1]). However, until now, I can only refer to Motion JPEG2000 to illustrate
>this difference in 2- and 4-way handshake; all other media formats are
>characterized by a fixed non-cacheable header occurring at the beginning of
>the media stream (and are thus compatible with the 4-way handshake
>Best regards,
>Davy Van Deursen
>Ghent University - IBBT
>Department of Electronics and Information Systems
>Multimedia Lab
>URL: http://multimedialab.elis.ugent.be

David Singer
Multimedia Standards, Apple Inc.
Received on Thursday, 19 March 2009 23:56:53 UTC

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