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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Jan 26 20:26:52 PST 2015


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

--- Comment #8 from Jason Litzinger <jlitzingerdev at gmail.com> 2015-01-27 04:26:45 UTC ---
Created an attachment (id=295500)
 View: https://bugzilla.gnome.org/attachment.cgi?id=295500
 Review: https://bugzilla.gnome.org/review?bug=646167&attachment=295500

Proposed fix

This patch (against master) fixes the jitterbuffer in that, if the push thread
is waiting, we wake it up even if the head hasn't changed.  Commit 3cd0e8ae8
introduced the change related to the head, and that commit makes sense, but has
negative effects for this mode.

That said, if you start the receiver in either case above, you still won't hear
audio, even though the buffer is pushing.  The reason is the timestamps
(audiobasesink drops them).  If the receiver is started after, then the first
test results in a smooth tone, while the second (on my machine) is a bit
choppy.

All plugins good jitterbuffer tests pass against master (there was a soup
failure), but I did not add a new one.  I will if this patch looks good upon
review.

-- 
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