Opened 4 years ago
Closed 4 years ago
#9890 closed defect (fixed)
Opus decoding glitches on sample with LBRR packets
| Reported by: | Tristan Matthews | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | avcodec |
| Version: | git-master | Keywords: | opus |
| Cc: | MarkZV | Blocked By: | |
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description (last modified by )
Summary of the bug:
Using https://people.videolan.org/~tmatth/rev.opus when stream-copied or played back.
How to reproduce:
% ./ffplay rev.opus
./ffplay rev.opus
ffplay version N-107861-gf5a663f2a9 Copyright (c) 2003-2022 the FFmpeg developers
built with gcc 11 (Ubuntu 11.2.0-19ubuntu1)
configuration: --disable-debug --disable-doc --disable-shared --enable-gpl --enable-libmp3lame --enable-libopus --enable-libvpx --enable-libx264 --enable-nonfree --enable-gnutls --enable-libfdk_aac --enable-postproc --enable-small --enable-version3 --enable-libx265 --enable-libsrt --prefix=/home/tmatth/local
libavutil 57. 33.101 / 57. 33.101
libavcodec 59. 42.102 / 59. 42.102
libavformat 59. 30.100 / 59. 30.100
libavdevice 59. 8.101 / 59. 8.101
libavfilter 8. 46.103 / 8. 46.103
libswscale 6. 8.103 / 6. 8.103
libswresample 4. 8.100 / 4. 8.100
libpostproc 56. 7.100 / 56. 7.100
Input #0, ogg, from 'rev.opus': 0KB vq= 0KB sq= 0B f=0/0
Duration: 00:00:06.00, start: 0.000000, bitrate: 64 kb/s
Stream #0:0(eng): Audio: opus, 48000 Hz, stereo, fltp
Metadata:
handler_name : SoundHandler
vendor_id : [0][0][0][0]
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.76.100
Note that:
./ffplay -acodec libopus rev.opus
doesn't glitch but also that this happens with streamcopying via ffmpeg as well (so not specific to ffplay).
The file plays fine with VLC, totem, and opusdec also decodes it to wav without any glitches.
Attachments (4)
Change History (10)
by , 4 years ago
comment:1 by , 4 years ago
This may be related to https://trac.ffmpeg.org/ticket/4641 as the glitches are happening on LBRR frames only.
comment:2 by , 4 years ago
| Cc: | added |
|---|
It looks like the code that was added to decode and skip the LBRR frames needs to at least reset the midonly flag afterwards.
comment:3 by , 4 years ago
| Description: | modified (diff) |
|---|
I've submitted a patch here:
http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300758.html
by , 4 years ago
I've submitted Sample with LBRR packets that could be incorporated into FATE.
by , 4 years ago
| Attachment: | lbrr-reset-midonly.wav added |
|---|
Example of decoding with midonly flag being reset
comment:4 by , 4 years ago
| Description: | modified (diff) |
|---|---|
| Summary: | Opus decoding glitches on sample → Opus decoding glitches on sample with LBRR packets |
comment:5 by , 4 years ago
Added fate test + samples:
https://people.videolan.org/~tmatth/9890-fate/
Patch for fate sent:
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-September/301164.html
comment:6 by , 4 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Fixed in e301143f96639b97a8e9a0045f93b56e0f399289.



Sample that demonstrates the bug