After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 758158 - opusdec: in-band FEC has no effect
opusdec: in-band FEC has no effect
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
Other Linux
: Normal normal
: 1.6.4
Assigned To: Luis de Bethencourt
GStreamer Maintainers
Depends on:
Reported: 2015-11-16 06:19 UTC by Peter Randeu
Modified: 2016-04-14 17:43 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Peter Randeu 2015-11-16 06:19:25 UTC
I am experimenting with gstreamer (1.6.1 Debian packages) and the opus plugins.

My sender pipeline looks like this:
gst-launch-1.0 -v \
 audiotestsrc is-live=true \
 ! audio/x-raw,rate=8000,channels=1 \
 ! opusenc \
   bandwidth=narrowband \
   complexity=0 \
   inband-fec=true \
   packet-loss-percentage=10 \
   bitrate=32000 \
 ! rtpopuspay \
 ! identity drop-probability=0.05 \
 ! udpsink port=5000 host=

The receiving pipe is:
gst-launch-1.0 \
 udpsrc port=5000 \
 ! $CAPS \
 ! rtpjitterbuffer do-lost=true \
 ! rtpopusdepay \
 ! opusdec plc=true use-inband-fec=true \
 ! alsasink

Depending on how I set the parameters of opusdec, I get unexpected results for the quality of the decoded audio signal:

plc=true use-inband-fec=true:
ERROR: from element /GstPipeline:pipeline0/GstOpusDec:opusdec0: Decoding error: -2 (sometimes sooner, sometimes later)

plc=true use-inband-fec=false:
short glitches

plc=false use-inband-fec=true:
longer glitches

plc=false use-inband-fec=false:
longer glitches

Why do I get "best" results, if I disable use-inband-fec? And why do I get a decode error if I enable both, plc and use-inband-fec?
Is there something wrong with how I use opusenc and opusdec?
Comment 1 Elshad Mustafayev 2015-12-10 12:52:18 UTC

I am facing the same exact problem.

Comment 2 Luis de Bethencourt 2015-12-10 19:57:46 UTC
I have been looking at opusdec lately. I will look into this bug once I am finished with Opus in MP4.

Thanks for reporting this! :)
Comment 3 Vincent Penquerc'h 2016-02-02 11:14:40 UTC
I'll be looking at this, since the last comment was from a month and a half ago, so I assume I'm not duplicating work, let me know if otherwise, Luis.
Comment 4 Vincent Penquerc'h 2016-02-02 11:39:48 UTC
The decoding error was introduced by a595874aac5d8b7a5c628ef34d749d558c791d5f.
Comment 5 Vincent Penquerc'h 2016-02-02 11:47:16 UTC
Replacing that patch with the original one fixes it. Not sure what the salient difference is yet.

PLC sounds ok, it looks like the FEC use is broken though. I will debug that too.
Comment 6 Vincent Penquerc'h 2016-02-02 15:25:11 UTC
This fixes the API error part of the bug.

commit 36125a844dd6475e2d6e334d481de3ed2a451695
Author: Vincent Penquerc'h <>
Date:   Tue Feb 2 15:20:48 2016 +0000

    opusdec: fix wrong buffer being checked for missing data
    This caused a decoding error if the resulting (wrong) buffer size
    was passed to the Opus decoding API.
Comment 7 Vincent Penquerc'h 2016-02-03 16:44:01 UTC
All fixed, I think.
Note that FEC relies on PLC being enabled. This could possibly be changed, but one would have to work around the base class as it didn't like me sending audio when I get gap events. Possibly decoding but keeping decoded audio, then prepending it to next finish call might work. Not sure it's worth it since setting plc to true is easy anyway.

commit 730d92ea8db364f2ac175089854e7f0cba572699
Author: Vincent Penquerc'h <>
Date:   Wed Feb 3 16:28:42 2016 +0000

    opus: fix FEC
    FEC may only be used when PLC is enabled on the audio decoder,
    as it relies on empty buffers to generate audio from the next
    buffer. Hooking to the gap events doesn't work as the audio
    decoder does not like more buffers output than it sends.
    The length of data to generate using FEC from the next packet
    is determined by rounding the gap duration to nearest. This
    ensures that duration imprecision does not cause quantization
    to 2.5 milliseconds less than available. Doing so causes the
    Opus API to fail decoding. Such duration imprecision is common
    in live cases.
    The buffer to consider when determining the length of audio
    to be decoded is the previous buffer when using FEC, and the
    new buffer otherwise. In the FEC case, this means we determine
    the amount of audio from the previous buffer, whether it was
    missing or not (and get the data either from this buffer, or
    the current one if the previous one was missing).
Comment 8 Luis de Bethencourt 2016-02-04 11:39:58 UTC
Thanks Vincent!

Sorry I didn't find time to look at this issue.