[Bug 646167] rtpjitterbuffer: stops processing when mode=buffer and drop-on-latency=1

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Jan 28 21:12:16 PST 2015


https://bugzilla.gnome.org/show_bug.cgi?id=646167
  GStreamer | gst-plugins-good | git master

--- Comment #13 from Jason Litzinger <jlitzingerdev at gmail.com> 2015-01-29 05:12:11 UTC ---
Created an attachment (id=295717)
 View: https://bugzilla.gnome.org/attachment.cgi?id=295717
 Review: https://bugzilla.gnome.org/review?bug=646167&attachment=295717

Proposed patch drop-on-latency

The drop-on-latency case is slightly more involved than the drop-on-latency=0
case.

First, the latency, as noted above, will affect the results, but it still
eventually fails.  It passes buffers for a time because most of the early items
in the jbuf are not droppable.  This allows the jbuf a chance to finish
buffering.  However, once the buffer drains, it will likely never push again. 
The reason, from what I've seen, is the call rtp_jitter_buffer_get_ts_diff(). 
It appears the logic is just reversed, i.e. the accounting for wrap is done
when the head < tail, not the other way around.

Because of this, the dropping code always drops a buffer, which means the
buffer never fills.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list