rtspsrc takes much longer than specified "latency" to start playing a stream.

[yiliang]

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 know why it happens. If I remove the locking in new_session_pad, the problem goes away, but probably it is 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

[Luca Ognibene-3]

On Wed, Mar 17, 2010 at 12:35 AM, yiliang <[hidden email]> wrote:

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.

Look here:
https://bugzilla.gnome.org/show_bug.cgi?id=612411

ciao
Luca

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel