How does bitrate reporting from MP4 files work?

[qyot27]

Is it from reading a specific atom or from calculating it directly?

I ask, because one lingering thing about MP4 files muxed by L-SMASH (through the muxer utility or even as part of x264) is that the audio bitrate doesn't display in some programs or context dialogs - instead, it shows 0kbps for the audio bitrate. Stuff muxed by mp4creator or mp4box or even libavformat (not in the image and samples because I thought of it later) displays the bitrate as expected.

>muxer

L-SMASH isom/mov multiplexer rev559 d3d4a5b
Built on Mar 7 2012 01:12:54
Copyright (C) 2010-2012 L-SMASH project

>mp4info testlsmash.mp4
mp4info version 1.5.11
testlsmash.mp4:
Track Type Info
1 audio MPEG-4 AAC LC, 23.777 secs, 0 kbps, 22050 Hz

>mp4info testmp4creator.mp4
mp4info version 1.5.11
testmp4creator.mp4:
Track Type Info
1 audio MPEG-4 AAC LC, 23.777 secs, 94 kbps, 22050 Hz
2 od Object Descriptors
3 scene BIFS

>mp4info testmp4box.mp4
mp4info version 1.5.11
testmp4box.mp4:
Track Type Info
101 audio MPEG-4 AAC LC, 23.777 secs, 95 kbps, 22050 Hz
2 od Object Descriptors
1 scene BIFS

>mp4info testlavf.mp4
mp4info version 1.5.11
testlavf.mp4:
Track Type Info
1 audio MPEG-4 AAC LC, 23.777 secs, 95 kbps, 44100 Hz
Tool: Lavf54.1.100

http://img19.imageshack.us/img19/3862/lsmashdiff.png


I mean, sure, it's probably fairly likely that this is due to something in the MPEG4IP code that's probably being used by all the affected cases, but it still doesn't explain why files written with mp4creator, mp4box, or libavformat consistently report the bitrate correctly while ones written by L-SMASH consistently don't. That's why I figured it was atomic, since if it was doing a calculation to get the bitrate it should report just fine no matter which muxer was used. Or so I would think.

If necessary, samples:
http://www.mediafire.com/?yy8syklm23drd4y

[VFR maniac]

MPEG-4 Audio ('mp4a') has a CODEC specific structure in moov.trak.mdia.minf.stbl.stsd.mp4a.esds,
and some softwares report average bitrate from avgBitrate field in esds atom (ESDBox).
However, this might be not helpful because of its definition.

According to 14496-1:2010,
avgBitrate – is the average bitrate in bits per second of this elementary stream. For streams with variable
bitrate this value shall be set to zero.

Therefore if the stream is encoded as VBR, then avgBitrate shall be set to 0.

Stream readers can't investigate if a stream is encoded as ABR or not unless the stream has the signal.
So, we (L-SMASH) always set 0 to avgBitrate since there is no CBR AAC.

[qyot27]

That makes sense. So, is it that it needs a specific signal to know whether a stream is ABR or VBR, and only if ABR is set do the values get written to avgBitrate, or that there really is no 'ABR' type of signalling for AAC and older software just ignored that part of the spec and wrote bitrate values there for AAC anyway?

[Chikuzen]

L-SMASH is giving top priority to keep specification as claimed by the project name.
Please ask them about implementation of other projects.
(Of course, if we misunderstand the spec, it should be corrected immediately.)