[Bug 769768] New: rtpjitterbuffer: lots of improvements around RTX

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 769768
           Summary: rtpjitterbuffer: lots of improvements around RTX
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: havard.graff at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
                CC: gstreamer at pexip.com
     GNOME version: ---

We have been focusing on RTX and making it work properly for our use-cases, and
as a result we have a series of patches that we thought it best to present in
one bug instead of splitting them up over several bugs.

The overall thing that these patches is trying to do, is to make the
jitterbuffer act really well against WebRTC and their implementation of RTX,
and also provide the application with the means to determine the right settings
(usually the right latency for the jitterbuffer) based on various stats.

Perhaps the biggest and most important changes are the fact that we now will
"wait" for rtx-packets that have been requested even after they have "expired",
and to mark the rtx-packets with a new flag (patch for plugins-base and
rtprtxreceive) that allows differentiation of "normal" and "rtx" packets. These
changes allow the various rtx-stats to become a lot more reliable and again
allows the application to act on them.

The workflow we have been following have been to observe every "actually" lost
packet (that rtx were unable to recover) and asking why this packets was not
"saved" by rtx, and this has led us to finding many bugs and improvements, all
which have been written proper tests for.

We are pleased to report that up to 10% introduced packetloss from Chrome to
GStreamer (using tools like netem) is now almost completely eliminated in our
application using these changes, while still keeping the end-to-end latency at
an acceptable level for real-time communication.

The patches are ordered, and needs to be applied in that order.

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