[FFmpeg-devel] Bug - MP3 Issues

elupus elupus
Fri Dec 7 13:03:41 CET 2007


Brian Brice <bbrice <at> newtek.com> writes:

> 
> No problem!  The following is a dump of that information with the AVI
> demux using AVSTREAM_PARSE_TIMESTAMPS.  Most of this audio is actually
> stored in the first audio chunk.  The part where the PTS values start to
> mess up is when the next chunk comes.
> 
...
> audio dts=6320 pts=6320 duration=316 size=288 [next_pts=6636]
> audio dts=6636 pts=6636 duration=316 size=336 [next_pts=6952]
> audio dts=6892 pts=6892 duration=316 size=288 [next_pts=7208] *
> ...
> 
> The following is a dump with AVSTREAM_PARSE_NONE in place:
> 
> audio dts=0 pts=0 duration=0 size=6573 [next_pts=0] *
> audio dts=6573 pts=6573 duration=526 size=526 [next_pts=7099]
> audio dts=7099 pts=7099 duration=526 size=526 [next_pts=7625]
> audio dts=7625 pts=7625 duration=526 size=526 [next_pts=8151]
> audio dts=8151 pts=8151 duration=526 size=526 [next_pts=8677]
> audio dts=8677 pts=8677 duration=525 size=525 [next_pts=9202]
> audio dts=9202 pts=9202 duration=526 size=526 [next_pts=9728]
> audio dts=9728 pts=9728 duration=526 size=526 [next_pts=10254]
> ...
> 
> Of course while trying to decode those packets, massive errors (even a
> crash!) happened.
> 
> The following is using AVSTREAM_PARSE_FULL, just to be sure:
> 
...
> audio dts=6320 pts=6320 duration=316 size=288 [next_pts=6636]
> audio dts=6636 pts=6636 duration=316 size=336 [next_pts=6952]
> audio dts=6573 pts=6573 duration=316 size=288 [next_pts=6889] *
> 
> The PTS values near the end is slightly different from the version using
> AVSTREAM_PARSE_TIMESTAMPS, but it's still off.
> 

Right, it looks like the bitratebased correction is there, my guess is that 
the duration get's set wrong for each packet. Since duration and size is what 
is used to apply the correction. 

Is that VBR mp3 in that avi? Cause if it isn't the durations of each packet 
are definatly wrong. But I guess it really could be vbr, then the original non 
parsed durations/timestamps look wrong, but I'm not sure. Mikeal has once 
explained (or probably multiple times) how vbr data in avi should be stored, 
and I guess this could be an example on a invalid way of storing it.








More information about the ffmpeg-devel mailing list