[gst-devel] rtspsrc takes much longer than specified "latency" to start playing a stream.

yiliang yiliangb at gmail.com
Wed Mar 17 00:35:47 CET 2010


Hi,

This happens when rtp/tcp is used (protocols=4). For example, if I specify
latency of 2000ms, sometimes it can take up to 10 seconds to start. I looked
into the code, and found that rtspsrc is waiting on the state lock in the
following function. This function is called at the right time when latency
expires.

static void
new_session_pad (GstElement * session, GstPad * pad, GstRTSPSrc * src)
{
  ...
  GST_RTSP_STATE_LOCK (src);
  ...
}

It seems that the same lock is repeatedly grabbed and released in the
function communicating with the server.

static GstFlowReturn
gst_rtspsrc_loop_interleaved (GstRTSPSrc * src)
{
    ...
    GST_RTSP_STATE_LOCK (src);
    if (src->state == GST_RTSP_STATE_READY) {
      /* We are looping in a paused mode */
      GST_RTSP_STATE_UNLOCK (src);
      goto already_paused;
    }
    /* protect the connection with the connection lock so that we can see
when
     * we are finished doing server communication */
    res = gst_rtspsrc_connection_receive (src, &message, src->ptcp_timeout);
    GST_RTSP_STATE_UNLOCK (src);
    ...
}

I do not why it happens. If I remove the locking in new_session_pad, the
problem goes away, but probably not a real solution. 

In my test, I run both the server and client on the same machine, with CPU
utilization around 120% on a pentium dual-core machine.

Thanks,
Yiliang
-- 
View this message in context: http://n4.nabble.com/rtspsrc-takes-much-longer-than-specified-latency-to-start-playing-a-stream-tp1595732p1595732.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.




More information about the gstreamer-devel mailing list