rtpjitterbuffer: don't use RTX packets in rate-calc and reset-logic
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:
- priv->next_seqnum will be set to the first RTX packet
- 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:
- Don't use RTX in calculation of the packet-rate.
- Don't use RTX in large-gap logic, as they are likely to be dropped.