rtpjitterbuffer: Option to disable rtx-delay-reorder
authorHavard Graff <havard.graff@gmail.com>
Sat, 9 Jul 2016 21:47:41 +0000 (23:47 +0200)
committerOlivier CrĂȘte <olivier.crete@collabora.com>
Wed, 14 Sep 2016 23:37:50 +0000 (19:37 -0400)
commit1436fc01e9e123fd6c7e5e957f04ca162150bf04
tree0da2e05a9b076aafee7b4f57c6911278c3f35e7e
parent0c7e3a860c1ec86ed3fc44f3fd32a497efed8da2
rtpjitterbuffer: Option to disable rtx-delay-reorder

When disabled we can save some iterations over timers.

There is probably an argument for rtx-delay-reorder to exist, but
for normal operations, handling jitter (reordering) is something a
jitterbuffer should do, and this variable feels like functionality that
is not "in-sync" with what the jitterbuffer is trying to achieve.

Example: You have 50ms jitter on your network, and are receiving
audio packets with 10ms durations. An audio packet should not be
considered late until its rtx-timeout has expired (and hence a rtx-event
is sent), but with rtx-delay-reorder, events will be sent pretty much
all the time due to the jitter on the network.

Point being: The jitterbuffer should adapt its size to the measured network
jitter, and then rtx-delay-reorder needs to adapt as well, or simply
get out of the way and let the other (better) rtx-mechanisms do their job.

Also change find_timer to only use seqnum as an argument, since there
will only ever be one timer per seqnum at any given time. In the
one case where the type matters, the caller simply checks the type.

https://bugzilla.gnome.org/show_bug.cgi?id=769768
gst/rtpmanager/gstrtpjitterbuffer.c