GNOME Bugzilla – Bug 764889
rtpjitterbuffer: Drops wrong number of packets with drop-on-latency=true
Last modified: 2016-04-13 06:44:58 UTC
rtp_jitter_buffer_get_ts_diff should return the difference in rtptime from the oldest -> newest packet. In the current implementation, it returns the opposite. To test this you can do: gst-launch-1.0 audiotestsrc num-buffers=1 ! audioconvert ! avenc_g722 ! rtpg722pay mtu=9999 ! rtpjitterbuffer drop-on-latency=true latency=500 ! fakesink dump=true AND gst-launch-1.0 audiotestsrc num-buffers=1 ! audioconvert ! avenc_g722 ! rtpg722pay mtu=9999 ! rtpjitterbuffer drop-on-latency=false latency=500 ! fakesink dump=true Since there is no latency, these should both dump the same number of buffers (4 locally), but with this bug and drop-on-latency=true, it dumps 3. I suspect in the code that the g_queue_peek_head_link/g_queue_peek_tail_link should be reversed
commit 4a0de53cc17fa4ee9762df0f58d7a29729eb4939 Author: Sebastian Dröge <sebastian@centricular.com> Date: Tue Apr 12 10:15:39 2016 +0300 rtpjitterbuffer: Fix rtp_jitter_buffer_get_ts_diff() fill level calculation The head of the queue is the oldest packet (as in lowest seqnum), the tail is the newest packet. To calculate the fill level, we should calculate tail-head while considering wraparounds. Not the other way around. Other code is already doing this in the correct order. https://bugzilla.gnome.org/show_bug.cgi?id=764889