GNOME Bugzilla – Bug 729524
rtpjitterbuffer: if retransmissions enabled, a gap larger than the latency can result in a stuck jitterbuffer
Last modified: 2014-05-09 16:15:53 UTC
Created attachment 275833 [details] [review] Test case to demonstrate issue. Observed in git master and the 1.2 branch. Test case and sample fix patches attached. A description of the steps that trigger the stuck buffer are: 1. seqnum 0 arrives, seqnum 1 expected 2. seqnum 1 arrives, seqnum 2 expected 3. Data stops arriving, RTX requests sent for seqnum 2 until it is finally declared lost. 4. lost event for seqnum 2 is pushed, incrementing next_seqnumi to 3. 5. Seqnum 16 arrives, packets 2->6 are part of a single "lost" event. 6. RTX packets begin arriving with seqnum 8 7. Lost event from 5 is popped to be pushed, but seqnum 2 < next_seqnum (3), so it is dropped. 8. jbuf is now stalled forever. The problem is that for large gaps, calculate_expected creates the "bulk" (for lack of a better word) lost event starting at a seqnum that has already been declared lost. This doesn't happen if RTX is disabled, but will stall the buffer if enabled.
Created attachment 275834 [details] [review] An example fix, only tested via the unit test.
For the attached proposed fix, the reason that the do_retransmissions check is performed is to preserve backward compatibility for non RTX enabled cases. If the old behavior is wrong, or this preservation is not necessary, then the following test cases will need updates: * test_only_one_lost_event_on_large_gaps * test_late_packets_still_makes_lost_events
I fixed it slightly differently, the real error was that we still were expecting a packet for which we produced Lost events. commit b2e1598e4abba7beba37e4c43e32598408e82663 Author: Wim Taymans <wtaymans@redhat.com> Date: Fri May 9 18:01:28 2014 +0200 rtpjitterbuffer: increment accepted packets after loss When we detect a lost packet, expect packets with higher seqnum on the input. Also update the unit test. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=729524