[Bug 646167] New: [gstrtpjitterbuffer] stops processing when mode=buffer and drop-on-latency=1
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Tue Mar 29 15:13:25 PDT 2011
https://bugzilla.gnome.org/show_bug.cgi?id=646167
GStreamer | gst-plugins-good | 0.10.30
Summary: [gstrtpjitterbuffer] stops processing when mode=buffer
and drop-on-latency=1
Classification: Platform
Product: GStreamer
Version: 0.10.30
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: gst-plugins-good
AssignedTo: gstreamer-bugs at lists.freedesktop.org
ReportedBy: tiagokatcipis at gmail.com
QAContact: gstreamer-bugs at lists.freedesktop.org
GNOME target: ---
GNOME version: ---
I was doing some tests with gstrtpjitterbuffer, basically generating audio with
audiotestsrc and sending it using rtp (ptime must be 20ms on my tests).
The pipeline used to generate audio is:
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
And on the receive side i have an application that does some measurements using
pad probing on the gstrtpjitterbuffer element. Everything was ok until i
started to set the gstrtpjitterbuffer "mode" property to "buffer". I got a
little audio and them silence. First thing i thought was "my test must be
broken". But when i started to debug to find out what i was doing wrong i found
that what was making my test getting locked was:
g_object_set(G_OBJECT (jitter_buffer), "drop-on-latency", TRUE, NULL);
so i tried to reproduce the problem using gst-launch and it really stops
processing, (the "buffering" message gets on 71% and stops, no audio is
heard). If i don't set drop-on-latency=1, this don't happens, or if the mode is
not buffer it works with drop-on-latency=1.
Basically:
works: gst-launch udpsrc port=5000 caps=application/x-rtp,clock-rate=8000 !
gstrtpptdemux ! gstrtpjitterbuffer mode=none drop-on-latency=1 ! decodebin !
autoaudiosink
works: gst-launch udpsrc port=5000 caps=application/x-rtp,clock-rate=8000 !
gstrtpptdemux ! gstrtpjitterbuffer mode=none drop-on-latency=0 ! decodebin !
autoaudiosink
works: gst-launch udpsrc port=5000 caps=application/x-rtp,clock-rate=8000 !
gstrtpptdemux ! gstrtpjitterbuffer mode=slave drop-on-latency=1 ! decodebin !
autoaudiosink
works: gst-launch udpsrc port=5000 caps=application/x-rtp,clock-rate=8000 !
gstrtpptdemux ! gstrtpjitterbuffer mode=slave drop-on-latency=0 ! decodebin !
autoaudiosink
works: gst-launch udpsrc port=5000 caps=application/x-rtp,clock-rate=8000 !
gstrtpptdemux ! gstrtpjitterbuffer mode=buffer drop-on-latency=0 ! decodebin !
autoaudiosink
stop processing on 71%: gst-launch udpsrc port=5000
caps=application/x-rtp,clock-rate=8000 ! gstrtpptdemux ! gstrtpjitterbuffer
mode=buffer drop-on-latency=1 ! decodebin ! autoaudiosink
i didn't find anything saying that the drop-on-latency property must not be set
to true when the buffering mode is "buffer", so i thought this must be a bug
(it is pretty simple to reproduce and the pipelines are quite simple too).
The problem happened on Ubuntu 10.10/Gstreamer 0.10.30.
--
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