mp4 overhead

[Doom9]

I'm sure some of the MP4 fans can help me here. I need some numbers on the overhead of MP4 files. I have some MPEG-4 content in MP4 container and I'm going to add an AAC file.. what kind of overhead can I expect to get? In the end I'll have my AAC file with a known size and I have to set the proper video bitrate so that when everything is muxed I reach the desired filesize.

[SeeMoreDigital]

In my experience the overhead in MP4 is less than for AVI... and get this, when you mux Mpeg4/AAC streams into the MOV container it's even lower!

I wonder to how much affect the muxing tools will make to the overhead?

I will do some tests...


Cheers

[yakima]

from looking at some files here, the overhead should range b/w 600 and 1500 kB, that is: - using an aac-only mp4 (which often is smaller than the aac file) and
- video size within the avi as given by avimux (that should be raw, shouldn't it?).
i don't think it makes a difference which muxer u use, as these figures (using mp4box) are the same as the ones i remember using mp4creator.

[bobololo]

From several reports from Ateme's AVC beta test, the mp4 container overhead was around 0.5% for full movie length encode (duration 1h40 - 2h20) with a 600 - 800 kb/s avc video track and a 128 kb/s aac audio track.

[SeeMoreDigital]

Is this any help to you: -

http://img27.exs.cx/img27/5001/MP4_overhead.gif

I used mp4UI through-out. And generated muxes with and without ISMA (BIFFS and OD data)!

I also generated an Mpeg4+AAC in AVI using AVI-mux. As you can see, the overhead is greater in AVI, than in MP4.


Cheers

[Doom9]

are there any fiable full lenght movie numbers? I've been going over it with bobololo and it turns out that for short clips the overhead is higher than for longer ones.

here's what he suggested: (video+audio bitrate)*length*1.005 = final size

I was wondering if that corresponds to the experiences other mp4 users have made.

[SeeMoreDigital]

In my experiance there does not appear to be any "hard fast" rule for estimating the overhead in MP4.

Here's another thing to ponder over. If you generate an encode with Recode2 directly to MP4, then de-mux the streams using say mp4UI and then re-mux the streams back into MP4. The overhead of the two files will be quite different.


Cheers

[neo75903]

I am not sure what caused a file increase when i do the following:
a mp3 file at 128 bitrate (4.3MB) transcoded to a mp4 audio only file at 96 bitrate became 6.14MB.
VideoLan and ffmpeg gave me the same result. Where is this increase of file size came from?


Directory of C:\ffmpeg.2004.10.27

15/11/2004 14:02 <DIR> .
15/11/2004 14:02 <DIR> ..
26/10/2004 16:09 4.907.520 ffmpeg.exe
19/10/2004 14:30 52.148 libogg-0.dll
19/10/2004 14:53 181.650 libvorbis-0.dll
15/11/2004 14:03 6.442.754 test.mp4
15/10/2004 22:12 4.518.557 test.mp3



Used syntax was:
C:\ffmpeg.2004.10.27>ffmpeg.exe -y -i "test.mp3" -acodec aac -ac 2 -ar 44100 -ab 96 -f mp4 "test.mp4"

edit:
same test done with Quicktime, result file size is 3,66MB.
Presume this is because they both are based on the same muxer.

edit 2:
i have extract the aac file from test.mp4 and it appears that the aac file alone is over 6MB! guess something to do with the encoder, search continues.
the -ab bitrate appearantly indicates bitrate/channel!

[SeeMoreDigital]

Originally posted by neo75903
I am not sure what caused a file increase when i do the following:
a mp3 file at 128 bitrate (4.3MB) transcoded to a mp4 audio only file at 96 bitrate became 6.14MB.
VideoLan and ffmpeg gave me the same result. Where is this increase of file size came from? Sorry to report... No such massive file size differences here: -

http://img107.exs.cx/img107/9148/Audio_overhead_comp_tests.gif

EDIT: Note the overhead in MOV is less than in MP3.... amazing!


Cheers

[neo75903]

@SeeMoreDigital:
Thx, but the confusing started cause mp4creator -list gave me some wrong information.

C:\ffmpeg.2004.10.27>mp4creator60.exe -list "test 1 6MB.mp4"
Track Type Info
1 audio MPEG-4 AAC LC, 282.331 secs, 98 kbps, 44100 Hz

C:\ffmpeg.2004.10.27>mp4creator60.exe -list "test 2 3MB.mp4"
Track Type Info
1 audio MPEG-4 AAC LC, 282.331 secs, 98 kbps, 44100 Hz

C:\ffmpeg.2004.10.27>


"test 1 6MB.mp4" should report 192kbps(2*96). I caint not verify if ffmpeg created some wrong headers in the resulted mp4 file because mp4box -info does not show the bitrate of the track.

[SeeMoreDigital]

I posted the wrong information anyway :eek:

The info I posted was for muxing MP3 stream into different containers and not transcoding MP3 to AAC :(


Sorry about that...

[gotaserena]

@neo75903: what does "faad -i" say?

@all: I thought I would throw in my experience in the matter. Well, not all of it, just two 1-hour files:

File 1:
Audio: 5.1 AAC LC, 3998.453 secs, 319 kbps, 48000 Hz, raw size 159483568 bytes
Video: MPEG-4 Simple @ L3, 3997.920 secs, 1124 kbps, 99949 frames, 640x512 @ 25fps, raw size 561787817 bytes

MP4 (ISMA): 722186521 bytes (with MP4Box)
MKV: 723143074 bytes (with mkvmerge)
AVI: 726148342 bytes (with AVIMux)

File 2:
Audio: 5.1 MPEG-4 AAC LC, 3223.445 secs, 311 kbps, 48000 Hz, raw size 125344030 bytes
Video: MPEG-4 Simple @ L3, 3222.880 secs, 1496 kbps, 640x512 @ 25fps, raw size 603046306 bytes

MP4 (ISMA): 729221890 bytes
MKV: 729737048 bytes
AVI: 732201616

[neo75903]

thats it, after extracting the aac file out of the mp4 i got this:

C:\ffmpeg.2004.10.27>faad -i "test 1 6MB.aac"
test 1 6MB.aac file info:
ADTS, 282.331 sec, 182 kbps, 44100 Hz

C:\ffmpeg.2004.10.27>faad.exe -i "test 2 3MB.aac"
test 2 3MB.aac file info:
ADTS, 282.331 sec, 97 kbps, 44100 Hz

C:\ffmpeg.2004.10.27>

Looks like mp4creator has another bug in reporting the right bitrate.

Thx all.

@SeeMoreDigital:
I noticed that, idd mov is suprisingly efficient, maybe it is true, they were ahead of us :)

[gotaserena]

if compiled with libmp4v2, faad should support .mp4 extensions, so in principle you wouldn't need to extract the aac track.

But the notion that the -ab flag in ffmpeg is actually the bitrate per channel sounds about right.

[neo75903]

@gotaserena:
faad does not report the bitrate when quering a mp4 file.
C:\ffmpeg.2004.10.27>faad -i "test 1 6MB.mp4"
test 1 6MB.mp4 file info:

LC AAC 282.056 secs, 2 ch, 44100 Hz

C:\ffmpeg.2004.10.27>

The -ab flag is to me surprisingly per channel. Does that mean faac doesnt use cross channel compression? Dont know the exact word, something like joint stereo with mp3s?

[gotaserena]

AFAIK neither faac nor nero uses joint stereo fully. In faac since v1.18 there is M/S matrixing which can be (roughly) described as joint-stereo for midranges. It's a lossless process, so it should be turned on by default. The developers have still to implement Channel Coupling (which is the method used by lame), which is lossy and effective only at lower bitrates.

Maybe it's safe to assume that ffmpeg just throws both channels to libfaac and leave coding to it? Maybe someone with more knowledge about ffmpeg can butt in.

[SeeMoreDigital]

pssssst!

What's this got to do with mp4 overhead?

[bond]

Originally posted by Doom9
I need some numbers on the overhead of MP4 files. I have some MPEG-4 content in MP4 container and I'm going to add an AAC file.. what kind of overhead can I expect to get?talking about raw adts .aac files vs. aac-in-mp4, the .mp4 file will be smaller than the raw adts .aac file!

In the end I'll have my AAC file with a known size and I have to set the proper video bitrate so that when everything is muxed I reach the desired filesize. i have posted a rule of thumb in my mp4 faq about .mp4 overhead according to my findings, which is that the video AVI filesize = final audio+video MP4 size (like 700MB) - audio MP4 size + 3MB

[gotaserena]

From the numbers above I found ~900KB of overhead per hour at 25fps.

[alexnoe]

here's what he suggested: (video+audio bitrate)*length*1.005 = final sizeThat can't be right: MP4 is definitely frame-based, meaning that just using a lower audio sample rate with the same bitrate (like 70 kbps HE-AAC instead of 70 kbps LC-AAC) will change the overhead. I am not sure if MP4 has something like lacing, but if it has, overhead will be as hard to predict as for AVI or MKV (or even worse).

Actually, AAC is currently the only audio type for which AVI overhead prediction makes sense without knowing the muxing settings, because it's the only audio format that still requires frame-wise packing without any possibility to change the number of frames per chunk.

And AVI is still the least complex one, compared to MKV or MP4. Also, take into account that a normal AAC file has 7 bytes of overhead per 1024 samples itself.
MP4 (ISMA): 722186521 bytes (with MP4Box)
MKV: 723143074 bytes (with mkvmerge)
AVI: 726148342 bytes (with AVIMux)Could you use AVI-Mux GUI, disable "write PrevClusterSize", "write Position", "index clusters in seekhead", "force matroska 1.0" and enable "video lacing" with 4 frames per lace, and try MKV output then?

[stephanV]

Originally posted by alexnoe
That can't be right: MP4 is definitely frame-based, meaning that just using a lower audio sample rate with the same bitrate (like 70 kbps HE-AAC instead of 70 kbps LC-AAC) will change the overhead.

I asked bobololo on IRC, as I too found the 0.5% rule very strange... you cannot base overhead on filesize.

An example he gave me (removed my stupid comments ;) )

[11/15/2004 9:43 PM] <bobololo> let's consider a file with 1 video frame
[11/15/2004 9:43 PM] <bobololo> in the mp4 container will have some constant headers which take around 1 kB
[11/15/2004 9:44 PM] <bobololo> then we have some index array in the mp4 containing stuff like dts/pts/keyframe/etc
[11/15/2004 9:45 PM] <bobololo> the size of an single entry is roughly constant for each video frame
[11/15/2004 9:45 PM] <bobololo> so the total size for the mp4 will be : headerSize + indexSize * numSample + sampleSize
[11/15/2004 9:46 PM] <bobololo> consider indexSize is 1 kB also (which is completely wring but it's for the example)
[11/15/2004 9:47 PM] <bobololo> if sampleSize is 100k, the final file size will be (1k + 1k + 100k) = 102k
[11/15/2004 9:47 PM] <bobololo> the overhead will be 2% right ?
[11/15/2004 9:48 PM] <bobololo> now consider that the sampleSize is 2k
[11/15/2004 9:50 PM] <bobololo> on my previous example, if the sampleSize was 2k, final size would be 4k, the overhead then is equal to 100%


Which proves estimating overhead as a percentage of file size is at least inaccurate. An estimation on the amount of samples (e.g. videoframes) would be more accurate IMO.

But of course theres also this:

[11/15/2004 9:54 PM] <bobololo> we could have a more precise model giving the exact overhead but this would imply the knowledge of data layout and other stuff
[11/15/2004 9:55 PM] <bobololo> and since different muxer doesn't store the data in the same way, this is quite tough to have a very generic model



anyway...

[alexnoe]

you cannot base overhead on filesize. That's a bit rough. Better: You cannot do that for containers other than OGM :)

[gotaserena]

Originally posted by alexnoe
Could you use AVI-Mux GUI, disable "write PrevClusterSize", "write Position", "index clusters in seekhead", "force matroska 1.0" and enable "video lacing" with 4 frames per lace, and try MKV output then? [/B]

723073509 bytes.

Another test:
Audio: 5.1 AAC LC, 3998.453 secs, 319 kbps, 48000 Hz, raw size 159483568 bytes
Video: MPEG-4 ASP (SP+B-VOP), 3997.920 secs, 1155 kbps, 99949 frames, 640x512 @ 25fps, raw size 574712149 bytes

MP4: 735082473 bytes (mp4creator)
MKV: 736077838 bytes (mkvmerge)
MKV: 736008913 bytes (AVIMux)
AVI: 739071996 bytes (AVIMux)