GNOME Bugzilla – Bug 758158
opusdec: in-band FEC has no effect
Last modified: 2016-04-14 17:43:36 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=127.0.0.1 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?
Hello, I am facing the same exact problem. Thanks.
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! :)
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.
The decoding error was introduced by a595874aac5d8b7a5c628ef34d749d558c791d5f.
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.
This fixes the API error part of the bug. commit 36125a844dd6475e2d6e334d481de3ed2a451695 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> 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. https://bugzilla.gnome.org/show_bug.cgi?id=758158
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 <vincent.penquerch@collabora.co.uk> 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).
Thanks Vincent! Sorry I didn't find time to look at this issue.