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

[richard]

On Tue Apr 12 11:20:00 EDT 2011 dinkypumpkin wrote:

>
> 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.
>
> 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.

Testing has shown that when the avgBitrate (average bit rate) in the
DecoderConfigDescriptor of the esds atom is zero, a m4a file will not
play in the Marantz CD6003. 

Both EasyTag and mp4tags makes a m4a file playable by changing the
average bitrate from zero to a non zero value, but there is a delay
(approx 25 seconds in the test file I used) before play starts. I think
this delay is caused because EasyTag and mp4tags move the mdat atoms
from the end to near the front (before the moov atom). The -optimize
option of mp4creator removes the free atoms and moves the mdat atoms
back to the end.

Clearly the Marantz player is fickle about how m4a files are written. It
appears to me that the problem is not due to a bug in ffmpeg or the
Marantz firmware, but (as dumpypumpkin says) because rtmpdump doesn't
set a field for the avgBitrate, or perhaps because the avgBitrate is
incorrectly set to zero.