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

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

From: David Singer <singer@apple.com>
Date: Wed, 1 Apr 2009 16:38:49 -0700
Message-Id: <p0624084ec5f9a9ad27de@[17.244.11.173]>
To: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>, Jack Jansen <Jack.Jansen@cwi.nl>, 'Davy Van Deursen' <davy.vandeursen@ugent.be>
Cc: Media Fragment <public-media-fragment@w3.org>, Eric Carlson <eric.carlson@apple.com>
At 0:59  +0200 1/04/09, RaphaŽl Troncy wrote:
>Dear Jack, Davy and Dave,
>
>Thanks for your comments! I think I have 
>implemented all of them in the wiki, see the 
>newer version at 
>http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_implementation. 
>In particular, the mp4 file captured by Jack is 
>now stored permanently at 
>http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4
>
>Two remaining issues:
>   - @Jack: do you know how I can have the byte 
>ranges that correspond to the temporal interval 
>[11.85 sec - 21.16 sec]?
>   - @Yves / all: in the first HTTP response of 
>the server in the context of the 4-ways 
>handshake, should the HTTP response code be '204 
>No Content' OR '200 OK'?
>
>That should close my ACTION-52, dear tracker :-)
>Cheers.

Thanks.  Nice video :-)

I'm not sure this really captures the way it works for MP4/MOV family files.

After the UA gets a time-range request (or a 
starting seek request), for a new file:

set section-requested-start 'F' to 0:
loop {
    perform a byte-range request for F to F+ say 3K.
    do I have the start of the moov atom?  yes -> exit
    look at the size of the last atom header we 
have;  set F = offset of last atom + size of last 
atom
}
complete the moov atom, if we need to (one more get)
now use the moov atom to work out what section of 
the media data is needed for the requested seek
do I have it already?  if not, get some amount of 
media at that point (for each track)

Now, in theory, the loop may go round several 
times; 90%+ of the time it exits immediately as 
the moov atom fits into the initial request. 
Occasionally, the mdat is first and we loop twice.

Usually, the moov atom is smaller than the 
initial request, so we don't need to do any 
completion

Usually, the tracks are interleaved and one get 
gets us both the (initial) video and audio, and 
we're playing.

So, this usually completes in two GETs, but is 
resilient to pathological cases that take more.

Makes sense?


Obviously the time->byte mapping could be done in a proxy, as you say.
-- 
David Singer
Multimedia Standards, Apple Inc.
Received on Wednesday, 1 April 2009 23:39:47 GMT

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