[Mp4-tech] MP4 data clarification for atoms

Adam Potolsky adamp ipinfusion.com
Thu Aug 31 13:14:19 EDT 2006


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.
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.
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?
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. 
Thank you all very much for the continued assistance you provide,
Adam Potolsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20060831/3a4c3eb0/attachment.html


More information about the Mp4-tech mailing list