[gstreamer-bugs] [Bug 323017] While(1) loop with sleep(0) in basertpdepayload.c

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Mon Dec 5 03:30:58 PST 2005


Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=323017
 GStreamer | gst-plugins-base | Ver: HEAD CVS





------- Additional Comments From Kai Vehmanen  2005-12-05 11:30 -------
The original intent was probably 'GST_SECOND/filter->clock_rate', but this also
is far from optimal. For example most current depayloaders in gstreamer use a
clock-rate of 8000, and packetization interval of 20 or 30ms (for audio, much
longer intervals for video). Sleeping GST_SECOND/8000 gets us 0.12msec sleep
interval, although packets are received at most every ~20msec. Thus the
depayloader thread is woken up unnecessarily roughly 160 times (with no work to
be done).

Ideally the data should be read from the depayloader/jitter buffer when the
pipeline sink (which is consuming the data) is ready to receive more data. The
next option is to match the wakeup frequency to the packetization (or packet
arrival) frequency. Unfortunately this might not match the consumption rate in
all cases.

When data is read from a reliable source (a file, TCP connection, etc), the
application can set 'queue-delay' to zero, and disable the jitter-buffering
altogether.

I don't know enough about gstreamer architecture to comment on the usability of
getrange in this case. Still, especially for audio, using sleep() to schedule
buffers for playback, does not seem like the right way to go. The
depayloader/jitter buffer should be waken up (=> polled) when more data is
needed for playback.


------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.




More information about the Gstreamer-bugs mailing list