[Bug 725167] New: opusdec PLC doesn't seem to work as well as Chrome

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=725167
  GStreamer | gst-plugins-bad | 1.2.1

           Summary: opusdec PLC doesn't seem to work as well as Chrome
    Classification: Platform
           Product: GStreamer
           Version: 1.2.1
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: tcdgreenwood at hotmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


I have noticed that PLC in opusdec seems far worse than in Chrome - it does
make some difference but not as much as it could.  I think this is to do with
the code in gstopusdec.c line 427 that fixes the samples at 120.  The
documentation for the opus codec (see
http://www.opus-codec.org/docs/html_api-1.1.0/group__opus__decoder.html#ga7d1111f64c36027ddcb81799df9b3fc9)
states:

In the case of PLC (data==NULL) or FEC (decode_fec=1), then frame_size needs to
be exactly the duration of audio that is missing, otherwise the decoder will
not be in the optimal state to decode the next incoming packet. For the PLC and
FEC cases, frame_size must be a multiple of 2.5 ms.

I think gstreamer has this information from the GAP_EVENT that is processed in
gstaudiodecoder.c, and is passed to gstopusdec.c in the 0 size buffer that is
passed in for PLC.  I think that using the correct number for samples may
improve things.

I will try to find a way to get the timings from the GstBuffer and use them to
set the correct size of samples in the PLC case (where the size of the buffer
is 0) in order to create a patch.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.