[Bug 768009] New: webrtcdsp: Stop cancelling after several spaced packet lost

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 768009
           Summary: webrtcdsp: Stop cancelling after several spaced packet
                    lost
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: nicolas at ndufresne.ca
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

I just started testing the canceller in real life situation and found that the
resync code only work for large lost, but for small and sporadic lost, it get
confused (or don't detect the discont). This is a combination of bugs here, the
discont detection works with 10ms buffer, but fail otherwise. This is specially
visible when we move from mulaw to opus (opus by default will aggregate to
20ms). And it's even worst if you use an odd buffer size, like 11ms.

Another issue, is that each time we resync, it changes the delay slightly, and
it take a small about of time for the canceller to lock again. This leaks a bit
of echo and is annoying.

For the reverse data, I think the best approach is to fill the losts with
silence. After all, silence is exactly what we are going to play on the
speaker. Now, this is a bit tricky to implement. As of now, we moved to using
the delay setting, that means we consume the reverse data immediately at start.
On life pipeline, that keeps the probe adapter level near to empty. When a lost
packet occure, the adapter would contain less then 10ms. When the probe data is
not aligned to 10ms, that means we may consume let's say 2ms and fill with
silence. if the lost was 5ms, it means we have 2ms of valid echo that we are
going to drop, which will leak a bit of echo.

As the echo probe is always ahead of the recording (there is always latency
between playing to speaker and recording this echo in life cases), I would
suggest to delay by 10ms the moment we start consuming from the probe adapter.
This will still produce good buffering. Another possibility is to use the
documented filter length. It's 128ms, As we found, matching with no delay
didn't work so well, cause it may be slightly miss-aligned in the opposite
direction, though we could find a compromise.

A quick way to test:
  pulsesrc latency-time=xx ! webrtcdsp ! opusenc ! identity drop-probability=..
! opusdec ! webrtcechoprobe ! pulsesink

For real life, use an udpsink, over the wifi, and a microwave (don't turn it
on) to help getting drops.

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