GNOME Bugzilla – Bug 720655
jitterbuffer fails to send lost event downstream after large gap
Last modified: 2018-05-06 12:22:22 UTC
When both 'do-lost' and 'do-retransmission' are true, the gstrtpjitterbuffer will fail to send the lost event downstream after a gap that exceeds the latency window. The gap results in the creation of two lost events, the first for the last packet prior to gap, and the second for all packets considered lost by calculate_expected(). The first is pushed downstream as expected, resulting in an update to priv->next_seqnum. The second is pulled by handle_next_buffer(), but is not pushed because its seqnum < priv->next_seqnum, which results in it being treated as an old packet. The problem after this is no new packets are pushed downstream because the priv->next_seqnum is stuck at an old seqnum.
This sounds like a duplicate of bug #709800. Can you confirm that it is fixed now? That fix is also in 1.2.2.
I updated to the head of the 1.2 branch and the error still occurs. The test I am running is composed of a server and a single client. The client's endpoint is added to the server and data begins to flow through the client from the server. The client is removed from the server's sink for a short period of time (less than that required for the jitterbuffer to timeout in the presence of no data [the "autoremove" property of the rtpbin is TRUE]), and then re-added. After this addition, data is received on the client side, but stalls due to the condition above. If the jitterbuffer is allowed to timeout and be removed, there is no problem.
Not sure what to do with this, there have been a lot of fixes in the last 2 years. Håvard/Stian, does this sound familiar, any opinion how likely/unlikely it is that it's still an issue? Someone would have to write a unit test I guess ;)
(In reply to Tim-Philipp Müller from comment #3) > Not sure what to do with this, there have been a lot of fixes in the last 2 > years. > > Håvard/Stian, does this sound familiar, any opinion how likely/unlikely it > is that it's still an issue? > > Someone would have to write a unit test I guess ;) We have not yet started using "do-retransmission" in our product, but it is on the schedule for the upcoming months, so if we find anything we will let you know. However, to me this sounds like a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=762211. And also, yes, a test should be easy to create by looking at existing similar ones.
Bug #762211 was caused by code that did not exist when this bug was reported.
We have now been running with do-retransmission for a while, and modifying https://github.com/GStreamer/gst-plugins-good/blob/master/tests/check/elements/rtpjitterbuffer.c#L523 to do retransmission (albeit using these changes https://bugzilla.gnome.org/show_bug.cgi?id=769768) seems to work just fine, indicating this is no longer a problem.