[Bug 747922] rtpjitterbuffer/rtxreceive: Don't reset the jitterbuffer if too old RTX packets arrive

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=747922

--- Comment #13 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
So we already have similar code in rtpsource and should probably make them at
least behave the same. I think the code in both is not ideal though.

For one, rtpsource should use gst_rtp_buffer_compare_seqnum(), currently I
think it just works by accident for seqnum<expected. I think it works the same
but the code makes this very hard to understand :)


Then rtpsource does the following (outside probation): diff=new_seqnum -
last_seqnum

- if diff < 3000 (RTP_MAX_DROPOUT) just forward the packet and do nothing,
unless wraparound (in which case it adds another 64k cycle). However I don't
think the wraparound detection can ever trigger, as if new_seqnum<last_seqnum
then the diff will be something shortly before 65536... which is clearly bigger
than 3000.

- if diff <= 65536 - 100 (RTP_SEQ_MOD - RTP_MAX_MISORDER) it requires two
consecutive seqnums and then considers it a new stream

- otherwise it just passes through the packet (diff >= 65536 - 100),
considering it packet misordering.


I think as a first step I'll rewrite the rtpsource code to use signed integers
instead of magic, and fix up the wraparound detection.


Then I think the expected behaviour should be (in jitterbuffer and rtpsource):

- if -RTP_MAX_MISORDER < diff <= RTP_MAX_DROPOUT, then just consider this
normal (plus wraparound detection)
- otherwise
  - in rtpsource, require 2 consecutive seqnums before resetting anything as we
do now but additionally queue up packets
  - in rtpjitterbuffer, require 5 consecutive seqnums and queue packets

The reason for this 2 vs 5 consecutive packets is that rtpjitterbuffer might
get things mixed together from multiple RTP sources (RTX), which might make
things going out of order much more likely (e.g. getting a few RTX packets in a
row, and also because of the probation period in rtpsource). While rtpsource is
for exactly one source. And of course because it currently uses 2 and that's
what seems to work well ;)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.