Workaround for broken(?) m4a files from ffmpeg, was Re: [PATCH] Output AAC as M4A for iTunes with metadata tags
get_iplayer at cjnash.com
Tue Apr 12 12:34:32 EDT 2011
> 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
> 220.127.116.11 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?
> get_iplayer mailing list
> get_iplayer at lists.infradead.org
More information about the get_iplayer