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@[17.202.35.52]>
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
>approach).
>
>Best regards,
>
>Davy
>
>
>[1]
>http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Fragment_Caches#Media_fo
>rmat_classification
>
>
>--
>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 GMT

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