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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Mar 3 14:38:32 PST 2014


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

--- Comment #4 from tcdgreenwood at hotmail.com 2014-03-03 23:00:43 UTC ---
(In reply to comment #3)
> Imho, if the gap is less than one packet, you should just ignore it (and get
> desynchronized a bit), if it is more,than you can just call into libopus
> multiple times ?

If you look at the opus codec API docs:

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.

It seems like it doesn't go badly wrong if you pass in different times, but I
am trying to get the PLC/FEC to work as well as it can.  I think if the timing
was based on the RTP timestamps I think it could be pretty exact.

>From looking at the jitterbuffer code it seems that the DTS is based on the
times received so has jitter.  Though I am still trying to work things through.
 I was wondering if another alternative was to use PTS as I understand it's got
the smoothed out values which might give a value much closer to the difference
in RTP timestamps.

-- 
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.


More information about the gstreamer-bugs mailing list