[Bug 771723] opusdec: too short buffers trigger error instead of PLC

[GStreamer (GNOME Bugzilla)]

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

--- Comment #34 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Vincent Penquerc'h from comment #32)
> I think there are two bugs:
> 
> 1 - pts not straight 20ms (I guess this comes from the sending pipeline, but
> the test case is from a pcap file, so no logs about how these are generated,
> would need to set up a pipeline for this).

Check the difference in receive times between packets and the difference
between RTP timestamps. And write that down to get an idea what happens here.
Maybe rtpjitterbuffer behaves correct, maybe not.

> 2 - opusdec does not cope well with that.
> 
> For the second one, I'm thinking that since we don't know how much samples
> is in the FEC data, we could have a loop to increase the buffer size when
> decoding fails. Up to the 120 ms theoretical max.

That sounds not great at all, and like a API or design problem in Opus. But
what can we do (please file a bug against Opus), so let's do that I guess?

However, why does Opus generate 120ms of data here if there is not that much
FEC (or generally not that much data missing)? Can't we prevent Opus from
generating too much output based on the gap duration information we have (and
if it's by clipping the opusdec output afterwards)?

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