Can't reliably generate rtsp TEARDOWN requests from rtspsrc

[Glen Diener]

Folks,

I'm struggling to find a way to reliably shut down a pipeline
containing an rtspsrc element.   I have an rtspserver that is relaying
several audio/video streams from cameras to a remote client process,
while simultaneously recording those streams to disk. On the client,
an rtspsrc-based pipeline is controlling and displaying these
audio/video streams from the rtspserver: starting, pausing, stopping,
etc.  My goal is to shut down the muxer on the server cleanly from the
client to "stop" the recording, and my approach is to have the client
pipeline effect this by sending an rtsp TEARDOWN request to the
server. Unfortunately, I haven't been able to get the client pipeline,
and its rtspsrc element, to reliably generate TEARDOWN requests.

The shutdown methodology I am using is  based on Sebastian Dröge's
comments posted here:

   http://stackoverflow.com/questions/25680796/gstreamer-understanding

Essentially, I do this in my python-based client process (I've tried
numerous variations on this theme):

        self.pipeline.send_event(Gst.Event.new_eos())
        self.bus.timed_pop_filtered(Gst.CLOCK_TIME_NONE, Gst.MessageType.EOS)
        self.pipeline.set_state(Gst.State.READY)
        self.pipeline.set_state(Gst.State.NULL)

...but I find the results are essentially random:  sometimes a
SHUTDOWN message is generated (usually, a string of successes), and
sometimes it isn't.  When it isn't, the code is always accompanied by
the following debug report:

    rtspsrc gstrtspsrc.c:5328:gst_rtspsrc_loop_send_cmd:<src> cancel
            previous request CLOSE

I'm  suspicious that there is a race condition in gstrtspsrc.c, in the
gst_rtspsrc_loop_send_cmd() function:

       gstrtspsrc.c, line 5266 in version 1.5.1.1:
  ....
  if (old != CMD_WAIT) {
    src->pending_cmd = CMD_WAIT;
    GST_OBJECT_UNLOCK (src);
    /* cancel previous request */
    GST_DEBUG_OBJECT (src, "cancel previous request %s", cmd_to_string (old));
    gst_rtspsrc_loop_cancel_cmd (src, old);
    GST_OBJECT_LOCK (src);
  }
  ...

A bunch of additional printf'ing has convinced me that, while this
function is processing a CMD_CLOSE, it will sometimes get interrupted
by a CMD_WAIT just as  soon as the lock is released by
GST_OBJECT_UNLOCK.  This cancels the CMD_CLOSE that,  as far as I can
tell, is the mechanism by which the TEARDOWN request would otherwise
have been sent.

I've read the following thread about a similar, if not identical, issue:

http://lists.freedesktop.org/archives/gstreamer-bugs/2014-October/135436.html

...where it looks like a patch was suggested, but it appears the issue
was closed
 as "NOTABUG", with the  comment:

"If you want to wait for shutdown you should use the PROGRESS messages."

I'm not sure how this would help (or what PROGRESS messages are!), as
I don't see this a problem of "waiting" for shutdown, but rather a
problem of ensuring that an rtsp TEARDOWN request is generated in the
first place.

Any thoughts or advice?

Thanks,

-glen
grd at loganmill.net

(sincere apologies if this accidentally went to the gstreamer-android
list, a gmail-auto-complete fumble on my part!)