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

On 2 apr 2009, at 01:38, David Singer wrote:
> 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.


David,
this pseudocode gets us to moov atom, but how do you then proceed to  
get the right location for playback? In Cannes, you mentioned that  
there's some sort of an index in there, could you elaborate on this a  
bit? Or alternatively, point to a location where this is explained?

Thanks,
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman

Received on Thursday, 2 April 2009 20:10:35 UTC