[Bug 758158] opusdec: in-band FEC has no effect

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=758158

Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|git master                  |1.7.2

--- Comment #7 from Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> ---
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 at 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).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.