Opened 9 years ago
Closed 9 years ago
#4890 closed defect (fixed)
avi file loses A/V sync because decoder mistakenly decodes broken frame
Reported by: | gjdfgh | Owned by: | |
---|---|---|---|
Priority: | important | Component: | avcodec |
Version: | git-master | Keywords: | mp3 regression |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
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.
Attachments (1)
Change History (2)
by , 9 years ago
Attachment: | sample.avi added |
---|
comment:1 by , 9 years ago
Keywords: | mp3 regression added |
---|---|
Priority: | normal → important |
Resolution: | → fixed |
Status: | new → closed |
Should be fixed in cb1da9fb8d71bb611a7b0028914c97afc3f5711d
The same sample as mentioned in the ticket.