[FFmpeg-trac] #4890(avcodec:new): avi file loses A/V sync because decoder mistakenly decodes broken frame

[FFmpeg]

#4890: avi file loses A/V sync because decoder mistakenly decodes broken frame
---------------------------------+--------------------------------------
             Reporter:  gjdfgh   |                     Type:  defect
               Status:  new      |                 Priority:  normal
            Component:  avcodec  |                  Version:  git-master
             Keywords:           |               Blocked By:
             Blocking:           |  Reproduced by developer:  0
Analyzed by developer:  0        |
---------------------------------+--------------------------------------
 The attached sample file has a strange mp3 audio packet in the beginning,
 and real audio starting at about 7 seconds.

 libavcodec's mp3 decoder decodes this first packet into about 20 seconds
 of silence. The second audio packet has PTs 7.632 seconds, so I conclude
 decoding of the first packet is broken.

 The result is that players using libavcodec lose A/V sync, because the
 first audio packet decodes to too much audio, and/or the audio PTS
 essentially goes backwards after the first packet.

 The sample [1] works with vlc (uses its own mp3 decoder), mplayer2 (uses
 libmpg123), mpv under Libav (Libav doesn't seem to have this problem), but
 _not_ ffplay or mpv linked against ffmpeg.

 Remuxing the audio to raw mp3 via codec copy results in a file that
 behaves very strange with ffmpeg: it first plays 20 seconds (or whatever
 it was) audio, then a timestamp reset happens, and then the normal audio
 (from the second avi packet onwards) plays. The duration of the mp3 file
 is also shown incorrectly. This indicates that libavformat probably
 handles it somewhat correctly, but the decoder outputs too much data.

 Upon a closer look, it actually turns out that the packet consists almost
 entirely of zero bytes. Only towards the end there's something that
 resembles a mp3 frame. So libavcodec's mp3 decoder decodes zeros. I don't
 think this is valid; the decoder should reject this.

 [1] https://0x0.st/z6_.avi

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4890>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker