GNOME Bugzilla – Bug 323314
gstbasertpdepayload takes 100% CPU
Last modified: 2007-04-24 12:31:03 UTC
Running the following pipeline with gst-launch-0.10 takes 100% CPU: gst-launch-0.10 rtpbin rtcp-support=false localport=24516 ! application/x-rtp,media=audio,payload=96,clock-rate=8000,encoding-name=AMR,encoding-params=\(string\)1,octet-align=\(string\)1,crc=\(string\)0,robust-sorting=\(string\)0,interleaving=\(string\)0 ! rtpamrdepay ! fakesink In gstbasertpdepayload.c, the call to "gst_base_rtp_depayload_wait (filter, GST_MSECOND * 5)" doesn't really wait, it returns immediately. I don't know what the problem is or how to fix it, I'm calling g_usleep() instead.
Is gst_element_requires_clock being called on the element? Does it actually have a clock on which to wait?
How should gst_element_requires_clock() be called? By gst-launch? I think the element has a clock to wait on (I don't know where it comes from) because the wait function executes correctly (I verified and gst_clock_id_wait() is called.) static void gst_base_rtp_depayload_wait (GstBaseRTPDepayload * filter, GstClockTime time) { GstClockID id; g_return_if_fail (GST_CLOCK_TIME_IS_VALID (time)); if (GST_ELEMENT_CLOCK (filter) == NULL) { GST_DEBUG_OBJECT (filter, "No clock given yet"); return; } id = gst_clock_new_single_shot_id (GST_ELEMENT_CLOCK (filter), time); gst_clock_id_wait (id, NULL); gst_clock_id_unref (id); }
OK, if it's getting to gst_clock_id_wait the element must have been provided with a clock. If it's not waiting long enough in the clock_id_wait function, we'll have to ask one of the dudes that knows stuff about clocking why that might be.
ping,any news here ?
The jitterbuffer has been moved from the base depayloader class into it's own element, therefore this bug shouldn't definately be gone. I will stub the buffering code in this base class soon.
Is this related to or even fixed with the patch in Bug #347300.