[FFmpeg-devel] Bug - MP3 Issues
Brian Brice
bbrice
Tue Dec 4 22:49:02 CET 2007
Hello.
I'm having quite a few issues with MP3 data. I'm working directly with
the libraries, so it's not as easy as giving a command line to reproduce
some of these.
* Seeking and the decoder:
I'm in an environment where seeking is used majorly, not just simple
playback. So a typical operation would be: av_read_frame and
avcodec_decode_audio with calls to av_read_seek happening. Also, I
typically call avcodec_flush_buffers before seeking. Once seeking
happens, the decoder is usually pretty noisey with av_logs. Sample
output is here:
http://heapify.org/static/ffmpeg/ffmpeg-log-current.txt
In an older version of ffmpeg, I'd get even more output with an
eventual crash. Even though there is still this noise coming out, I'm
worried it might still crash. Here is sample output from an older
version of ffmpeg:
http://heapify.org/static/ffmpeg/ffmpeg-log-old.txt
I also uploaded a clip and sample code to perform random seeks to
produce this output:
http://heapify.org/static/ffmpeg/
* 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
--
Brian Brice
More information about the ffmpeg-devel
mailing list