- From: David Singer <singer@apple.com>
- Date: Wed, 1 Apr 2009 16:38:49 -0700
- 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 UTC