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

[Simon Nash]

richard wrote:
> 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.
> 
rtmpdump produces FLV files, which have nowhere to put a value for the
average bit rate.  So this isn't something that rtmpdump could fix.

I think ffmpeg is the right place to handle this.  When ffmpeg runs
(using -acodec copy), it displays a status line of the form
  size=   33270kB time=821.71 bitrate= 331.7kbits/s
where these values are updated every second or so.  So ffmpeg does
know the average bit rate, but it doesn't store it in the m4a file.

   Simon
>    
> 
> 
> 
> 
> 
> _______________________________________________
> get_iplayer mailing list
> get_iplayer at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/get_iplayer
> 
>