[FFmpeg-devel] Bug - MP3 Issues

[Brian Brice]

Michael Niedermayer wrote:
> On Tue, Dec 04, 2007 at 03:49:02PM -0600, Brian Brice wrote:
> [...]
>> * MP3 audio demuxed from AVI:
>>    Generally, MP3 audio demuxed from AVI works pretty well.  Everything
>>    decodes perfectly.  The big issue here are PTS values.  Often times
>>    the PTS values are skewed slightly, but that value grows as simple
>>    reading is done.  Here is some sample output:
>>
>>        audio current_pts=6320 next=6636
>>        audio current_pts=6636 next=6952
>>        audio current_pts=6892 next=7208 *
>>        audio current_pts=7149 next=7465 *
>>        audio current_pts=7465 next=7781
>>        audio current_pts=7812 next=8128 *
>>        audio current_pts=8159 next=8475
>>
>>    The asterisked lines are ones where the current_pts didn't match the
>>    previously calculated next PTS (packet.pts + packet.duration).  These
>>    inaccuracies in the PTS values causes problems when you're relying on
>>    them to be accurate, especially in sequential reading. :-(  The clip
>>    that generates these PTS values is here:
>>
>>        http://heapify.org/static/ffmpeg/d0pe-hairspraycam-sample.avi
> 
> ive not looked at the sample but i fear that you simply will have to accept
> that many avi files are plain broken
> try to remux it with -acodec copy i suspect that will fix it
> also try to replace AVSTREAM_PARSE_TIMESTAMPS by AVSTREAM_PARSE_FULL in
> avidec.c and also try AVSTREAM_PARSE_NONE
> if NONE doesnt work then the AVI is broken like 99.9% avi files with mp3
> 
> [...]

I can sort of deal with this.  In this particular AVI (maybe others),
the first chunk for audio has quite a few frames of MP3 data in it.  The
parser then takes care of splitting that up and generating PTS/DTS
values until the next audio chunk comes.  I think these values might be
a bit off still or maybe rounded too high?  The audio stream's time_base
in this clip is 1/13148 at a sample rate of 48 kHz.  I'm not sure if
that helps.

>>>        audio current_pts=6320 next=6636
>>>        audio current_pts=6636 next=6952
>>>        audio current_pts=6892 next=7208 *

The loss of time in this case (next should be 6952 but is 6892) is when
the next audio chunk in the AVI file comes about.  Somehow, the parser's
generation of PTS values got ahead of what the AVI demux would return.

I did try AVSTREAM_PARSE_FULL and AVSTREAM_PARSE_NONE, but just didn't
work unfortunately. :-(


On another note, any idea about the MP3 decoder freaking out when
seeking is involved?



-- 
Brian Brice