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