[Mp4-tech] MP4 data clarification for atoms

[Dave Singer]

At 12:14  -0700 31/08/06, Adam Potolsky wrote:
>First let me say thank you to everyone who 
>responded to my first post. Your responses have 
>been very helpful. Based on that, I want to make 
>a few statement and ask a question or 2 for 
>clarification to make sure I'm understanding 
>this properly.
>
>1) Based on what I've read, is it correct to say 
>that w/o some kind of header data (wrapper?) 
>around the actual mpeg4 encoded media content, 
>that content is useless. That is to say it's not 
>possible (or effectively useless) to try and 
>play the content. Further, it would be 
>impossible to gather a correct bitrate, height, 
>width, etcŠ from here because that information 
>is necessary to even know how to decode the 
>content.
>

I'm not sure what level you are wrapping, but 
yes, you need to know what decoders, what 
parameters to those decoders, width, height, 
timing, sampling rates, and so on.
>2) For any given file, there are conceptually 4 
>states of 32/64 bit implementation. Although the 
>standard strongly recommends not using 64bit for 
>anything that doesn't need it, it's not 
>forbidden. So, for example, there could be a 
>17GB mpeg movie with some "size-type-content" 
>boxes that are 32bit, while at least one must be 
>64bit. Something like:
>
>0000 0020 6674 7970 XXXX XXXX XXXX XXXX XXXX XXXX <ftyp> (32-bit)
><A moov atom>
>0000 0078 6d76 6864 0000 0001 <120 bytes, mvhd, 
>version = 1 (32-bit size with 64bit content)
>XXXX XXXX XXXX XXXX <create time>
>XXXX XXXX XXXX XXXX <mod time>
>XXXX XXXX <timescale>
>XXXX XXXX XXXX XXXX <duration>
>XXXX XXXX XXXX XXXX <etcŠ>
>XXXX XXXX XXXX XXXX
>XXXX XXXX
>XXXX XXXX
>XXXX XXXX XXXX XXXX (twice)
>XXXX XXXX XXXX XXXX (9 times)
>XXXX XXXX XXXX XXXX (6 times)
>XXXX XXXX XXXX XXXX
><More atoms>
>0000 0001 6d64 6174 0000 0003 fff9 1a4b <64-bit 
>size, mdat, 17179417163 byte size> (64-bit size)
><Lots and lots of mdat content>
>
>This is hand built so excuse any little 
>technical stuff, but I tried to make a 
>combination 32/64 file with a 32/64 atom in it.

This looks reasonable.  As you say, you ought to be able to handle
64-bit durations
64-bit timestamps, if you want your software to work after 2040
64-bit atom sizes
64-bit chunk offsets
>
>3) In looking over the atom portion of the spec, 
>it appears that there is no "biggest 
>height/width" field that covers the entire file. 
>It looks like the highest exposure is the 'tkhd' 
>atom. Even still, this is the "recommended 
>presentation" size, not an actual recorded size. 
>So if there is more than one track in an mp4, 
>wouldn't I need to look at them all and pick the 
>"biggest" (height * width?) to report a size?

right, you have to determine the bounding box of 
all the tracks, unless there is a composition 
system like laser or bifs which 'captures' the 
other tracks and defines the composition.
>
>4) Bitrate still eludes me. I have a movie file, 
>assume an MP4 file for now, and I want to find 
>the bitrate (or calculate it.) The file has a 
>H264 component, and a AAC component, so this is 
>already a bit confusing since they certainly 
>have different bitrates. (Šdon't they?)  I will 
>further assume I can use the video bitrate as 
>the 'file' bitrate when it's opened.

a crude calculation is to take sum(sample size 
table)/track-duration for each track, and sum 
those.  this is a long-term average.  the mpeg4 
bitrate atom or an elementary stream descriptor 
can have more precise information given by the 
content author.
the way the various tracks' bitrates might 'play 
off' against each other is not covered.
>
>Thank you all very much for the continued assistance you provide,
>
>Adam Potolsky
>
>_______________________________________________
>NOTE: Please use clear subject lines for your 
>posts. Include [audio, [video], [systems], 
>[general] or another apppropriate identifier to 
>indicate the type of question you have.
>
>Note: Conduct on the mailing list is subject to 
>the Antitrust guidelines found at 
>http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php

-- 
David Singer
Apple Computer/QuickTime
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20060901/4884ee2d/attachment.html