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.
_______________________________________________ get_iplayer mailing list [email protected] http://lists.infradead.org/mailman/listinfo/get_iplayer
