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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Apr 18 07:18:56 PDT 2011


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

tiagokatcipis changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|0.10.30                     |0.10.x

--- Comment #1 from tiagokatcipis at gmail.com 2011-04-18 14:18:54 UTC ---
Testing a little more i found out that if you run the sender pipeline first,
and them the receiver pipeline, it wont block. But if you run the receiver
pipeline first and then the sender pipeline, it blocks.

to reproduce the problem, run:

gst-launch udpsrc port=5000 caps=application/x-rtp,clock-rate=8000 !
gstrtpptdemux ! gstrtpjitterbuffer mode=buffer drop-on-latency=1 ! decodebin !
autoaudiosink

and them:

gst-launch -m audiotestsrc is_live=true ! alawenc !
audio/x-alaw,rate=8000,channels=1 ! rtppcmapay min-ptime=20000000
max-ptime=20000000 ! udpsink host=127.0.0.1 port=5000

it will block on buffering 71%.

it is interesting that changing the sink changes the way the problem happens.
with alsasink the buffering message blocks on 53%, pulsesink blocks on 71%, and
if you use a fakesink, the problem dont happens at all.

can someone confirm if this problem really exist or if im doing something
stupid here?

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