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

[Simon Nash]

dinkypumpkin wrote:
> 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.
> 
The buffersizeDB field isn't an issue for the Marantz.  I know that because
I sent Richard two files, one with bufferSizeDB set to zero and one with it
set to non-zero, and both of them played on the Marantz.

>> 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.
> 
This makes sense, but it doesn't explain why ffmpeg sets the maxBitrate
field.  Where does it get the value from?

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