jitterbuffer: Speed up lost timeout handling
authorEdward Hervey <edward@centricular.com>
Wed, 2 Mar 2016 13:25:24 +0000 (14:25 +0100)
committerEdward Hervey <bilboed@bilboed.com>
Thu, 7 Apr 2016 08:14:24 +0000 (10:14 +0200)
commitb82da6292239ff2f8bcf620b1595d6b08ad591f4
tree16d37ad1a3f0820ef81d9213c8f1e0d455ecfa86
parentd656fe8d549ed0ac06e4baf169e06066d0b99e6f
jitterbuffer: Speed up lost timeout handling

When downstream blocks, "lost" timers are created to notify the
outgoing thread that packets are lost.

The problem is that for high packet-rate streams, we might end up with
a big list of lost timeouts (had a use-case with ~1000...).

The problem isn't so much the amount of lost timeouts to handle, but
rather the way they were handled. All timers would first be iterated,
then the one selected would be handled ... to re-iterate the list again.

All of this is being done while the jbuf lock is taken, which in some use-cases
would return in holding that lock for 10s... blocking any buffers from
being accepted in input... which would then arrive late ... which would
create plenty of lost timers ... which would cause the same issue.

In order to avoid that situation, handle the lost timers immediately when
iterating the list of pending timers. This modifies the complexity from
a quadratic to a linear complexity.

https://bugzilla.gnome.org/show_bug.cgi?id=762988
gst/rtpmanager/gstrtpjitterbuffer.c