mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-13 12:51:16 +00:00
981d0c02de
The problem was this: Due to the highly irregular arrival of RTX-packet the max-misorder variable could be pushed very low. (-10). If you then at some point get a big in the sequence-numbers (62 in the test) you end up sending RTX-requests for some of those packets, and then if the sender answers those requests, you are going to get a bunch of RTX-packets arriving. (-13 and then 5 more packets in the test) Now, if max-misorder is pushed very low at this point, these RTX-packets will trigger the handle_big_gap_buffer() logic, and because they arriving so neatly in order, (as they would, since they have been requested like that), the gst_rtp_jitter_buffer_reset() will be called, and two things will happen: 1. priv->next_seqnum will be set to the first RTX packet 2. the 5 RTX-packet will be pushed into the chain() function However, at this point, these RTX-packets are no longer valid, the jitterbuffer has already pushed lost-events for these, so they will now be dropped on the floor, and never make it to the waiting loop-function. And, since we now have a priv->next_seqnum that will never arrive in the loop-function, the jitterbuffer is now stalled forever, and will not push out another buffer. The proposed fixes: 1. Don't use RTX in calculation of the packet-rate. 2. Don't use RTX in large-gap logic, as they are likely to be dropped. |
||
|---|---|---|
| .. | ||
| elements | ||
| generic | ||
| pipelines | ||
| gst-plugins-good.supp | ||
| meson.build | ||