Workaround for broken(?) m4a files from ffmpeg, was Re: [PATCH] Output AAC as M4A for iTunes with metadata tags

[dinkypumpkin]

On 11/04/2011 17:24, Simon Nash wrote:
> I've narrowed down the vital difference (with a little more help from
> Richard).  In the DecoderConfigDescriptor within the esds atom, there's
> a field named avgBitrate (average bit rate).  In the file that doesn't
> play, this field is set to zero.  In the file that does play, this field
> is set to a non-zero value.

I see that bufferSizeDB (max sample size) is also zero. That would be a 
bit unfortunate if either of those fields is the cause. I don't think 
ffmpeg will ever fill in those fields in this case, as you're just 
copying streams (i.e., using -acodec copy).  The FLV file generated by 
rtmpdump doesn't seem to have those fields, probably since it's from a 
streaming source, so 0 in -> 0 out.

> I think the most efficient way to get this field set correctly is to
> use ffmpeg to create a .aac file and then use mp4creator -optimize to
> convert this file to a .mp4 file.  This will put the moov atom at the
> start of the file, set the esds descriptor lengths using the 4-byte
> format, and set the average bitrate field correctly.

For any Mac users who may need to do this to their M4A files:  Version 
1.5.0.1  of the mpeg4ip package is in MacPorts, but Fink doesn't appear 
to have anything.  A later version 1.6.1 is in some Linux distros, but 
it wasn't worth the bother to take the source I found and wrangle it 
into shape for OSX.  If you use Homebrew, install the mp4v2 package (a 
successor to the mpeg4ip project), which will give you mp4tags and a 
utility called mp4file that can do the optimization instead of mp4creator.

On 11/04/2011 18:21, bat guano wrote:
> If the Marantz problem is caused only because the avgBitrate field is not filled in
> correctly, then maybe the FFmpeg people will fix it at the FFmpeg-users mailing list.

When mp4tags rewrites the MP4 metadata on save, the underlying MP4 
library does the arithmetic to calculate the necessary values and fill 
in the esds atom.  From perusing the ffmpeg code, it looks like the 
required logic could be added, but I'm not sure it should be.  I don't 
think zero is an incorrect value for those fields, plus it would sort of 
violate the codec-based model of ffmpeg.