[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