rtpjitterbuffer: immediately insert a lost-event on multiple lost packets
authorHavard Graff <havard.graff@gmail.com>
Thu, 19 Mar 2020 22:12:04 +0000 (23:12 +0100)
committerGStreamer Merge Bot <gitlab-merge-bot@gstreamer-foundation.org>
Fri, 20 Mar 2020 13:17:20 +0000 (13:17 +0000)
commit5dacf366c078fdddc6bbb03f6c9ab9c6c946156f
treebd7c44ea1ee611d0afbbba519e26aff2cb30329c
parentd045b40db99eba06ebcc197caf55e9003119e7da
rtpjitterbuffer: immediately insert a lost-event on multiple lost packets

There is a problem with the code today, where a single timer will
be scheduled for a series of lost packets, and then if the first packet
in that series arrives, it will cause a rescheduling of that timer, going
from a "multi"-timer to a single-timer, causing a lot of the packets
in that timer to be unaccounted for, and creating a situation in where
the jitterbuffer will never again push out another packet.

This patch solves the problem by instead of scheduling those lost packets
as another timer, it instead asks to have that lost-event pushed straight
out.

This very much goes with the intent of the code here: These packets are
so desperately late that no cure exists, and we might as well get the
lost-event out of the way and get on with it.

This change has some interesting knock-on effect being presented in
later commits. It completely removes the concept of "already-lost", so
that is why that test has been disabled in this commit, to be
removed later.
gst/rtpmanager/gstrtpjitterbuffer.c
tests/check/elements/rtpjitterbuffer.c