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: Fri, 3 Apr 2009 07:46:18 -0700
Message-Id: <p06240812c5fbd18de433@[17.202.35.52]>
To: Jack Jansen <Jack.Jansen@cwi.nl>
Cc: Media Fragment <public-media-fragment@w3.org>, Eric Carlson <eric.carlson@apple.com>
At 10:12  +0200 3/04/09, Jack Jansen wrote:
>More questions:
>
>On 3 apr 2009, at 01:37, David Singer wrote:
>
>[...]
>
>>samples are stored in chunks;  the chunk offset table gives the 
>>starting sample number, the number of samples, and the absolute 
>>file byte-offset of the first byte of that sample, for each chunk. 
>>find the chunk the sample we want is in, and its byte offset.
>
>This table seems to be unbounded in size, or not? What would be the 
>size for, say, a 1-hour video?
>>
>>(typically, for data loading, we stop here and just add that chunk 
>>start point to the data we need, find the chunk starts for the 
>>other tracks, and if they are close together, load a whole 
>>bunch-o-bytes from the earliest offset, such that we get all of 
>>them)
>>
>>there is also a table which gives (compacted again) the size of 
>>each sample;  for the sample preceding the one we want, but in the 
>>same chunk, add their sizes to the chunk offset.  this gives the 
>>absolute byte offset of the access unit want.
>
>Again, this table seems to be unbounded. Or did I misunderstand, and 
>is this information stored in the chunk (as opposed to in the moov)?

no, this is in the moov.  it's bounded by the number of samples :-)

for CBR data, it's very compact, of course (a count and a single size)
-- 
David Singer
Multimedia Standards, Apple Inc.
Received on Friday, 3 April 2009 14:48:56 GMT

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