some additional infos:

I'm reproducing this error after 2/3 play/stop sequence with vlc (1.1.7) as rtsp client. The pipeline I'm using with gst-rtsp is the following:

souphttpsrc location=... ! queue ! matroskademux ! mpeg4videoparse ! rtpmp4vpay name=pay0 pt=96

If I not set export G_DEBUG=fatal_warnings the program will continue to run and I can access http stream with pipeline such the following:

souphttpsrc location=... ! queue ! matroskademux ! decodebin2 ! xvimagesink

but the rtsp stream (based on the http one) is unavailable

same test case another crash:

GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

CRITICAL **: gst_rtsp_media_factory_get_auth: assertion `GST_IS_RTSP_MEDIA_FACTORY (factory)' failed

gdb) bt

+ Trace 226338

connecting/disconnecting to gst-rtsp cause a 100% cpu usage too. These problems are more evident if you have a slow network beetwen the rtsp server and the source stream, however sometimes happen even with source stream and rtsp server on the same LAN (less frequently)

forget the 100% cpu usage this is caused by gstpoll (https://bugzilla.gnome.org/show_bug.cgi?id=645746), I can confirm the other issues

Hello,

I am experiencing the same problem.

GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

CRITICAL **: gst_rtsp_media_factory_get_auth: assertion
`GST_IS_RTSP_MEDIA_FACTORY (factory)' failed

Rob Krakora

> I am experiencing the same problem.
> 
> GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
> 
> CRITICAL **: gst_rtsp_media_factory_get_auth: assertion
> `GST_IS_RTSP_MEDIA_FACTORY (factory)' failed

Great, maybe you can help track it down and fix it :)

If I set the "shared" property to "true" I don't see this assertion anymore...however, I fail to see the root cause of the bug with the "shared" property set to "false".

Something to do with the "shared" property...as it's state gets set on the GstRTSPMedia param in the function below...

default_configure (GstRTSPMediaFactory * factory, GstRTSPMedia * media)
{
  gboolean shared, eos_shutdown;
  guint size;
  GstRTSPAuth *auth;

  /* configure the sharedness */
  GST_RTSP_MEDIA_FACTORY_LOCK (factory);
  shared = factory->shared;
  eos_shutdown = factory->eos_shutdown;
  size = factory->buffer_size;
  GST_RTSP_MEDIA_FACTORY_UNLOCK (factory);

  gst_rtsp_media_set_shared (media, shared);
  gst_rtsp_media_set_eos_shutdown (media, eos_shutdown);
  gst_rtsp_media_set_buffer_size (media, size);

  if ((auth = gst_rtsp_media_factory_get_auth (factory))) {
    gst_rtsp_media_set_auth (media, auth);
    g_object_unref (auth);
  }
}

Could you try with latest git as of now? There was a refcounting fix which looks like it might be related (http://cgit.freedesktop.org/gstreamer/gst-rtsp-server/commit/?id=aa128813fedf6075720275f672edf78039b5ad3f)

Hi Tim,

I have tried with the latest Git and the problem persists.  However, I believe that this is just a symptom of another problem that may exist in v4l2src which is part of the pipeline that is passed to the server.  Seems like after a successful connection is torn down along with the pipeline and a new one created, that the parameters on the USB webcam cannot be get/set.  If I set "shared" to "true" then it seems that the pipeline is never torn down between connections and all is well.  This will need more investigation on my part as I have not see this behaviour with webcams other than these three new H.264 webcams (FaceVsion, Logitech and Creative).  It may even be a problem with v4l2 and not the v4l2src element.  I will keep you posted.

Best Regards,

Rob Krakora

Created attachment 192817 [details]
GST_DEBUG_NO_COLOR=1 GST_DEBUG=rtsp*:5,v4l2src:5,pipeline:5 Debug Trace

Here is a trace of the problem...

GST_DEBUG_NO_COLOR=1 GST_DEBUG=rtsp*:5,v4l2src:5 /home/silentm/Development/gst-rtsp-server/examples/.libs/test-launch "v4l2src device=/dev/video0 always-copy=false ! image/jpeg, width=1280, height=720, framerate=30/1 ! rtpjpegpay pt=26 name=pay0" &>problem.txt

FV TouchCam E1 webcam attached as V4L2 device.

This bug appears to be related to https://bugzilla.gnome.org/show_bug.cgi?id=628640 as I see this message as indicated in 628640.

0:00:15.066838730  6775      0x1171490 WARN               rtspmedia rtsp-media.c:1500:default_handle_message: 0x121e8e0: got error Device '/dev/video0' cannot capture at 1280x720 (gstv4l2object.c(2111): gst_v4l2_object_set_format (): /GstPipeline:media-pipeline/GstPipeline:pipeline1/GstV4l2Src:v4l2src1:
Call to S_FMT failed for MJPG @ 1280x720: Device or resource busy)

So, it looks like even though the first connection has been closed the pipeline associated with it never gets torn down and it is still in PLAY state and grabbing frames and thus has the v4l2 device.  The second connection comes in and the RTSP server builds another pipeline for it and the v4l2src element in this pipeline attempts to utilize the same v4l2 device in use by the other pipeline and this produces the "resource busy" message.  So, the pipeline instantiated by the first connection is never getting torn down, so it makes since that when I set the RTSP server property "shared" to "true" that this problem is not encountered since the pipeline instantiated by the first connection would always be present and shared by many clients.

The problem occurs when the client abruptly closes the connection without
issuing a TEARDOWN.  The TEARDOWN handler in the rtsp-client.c file of the RTSP
server is where the pipeline gets torn down.  Since this handler is not called,
the pipeline remains and is up and running.  Subsequent clients get their own
pipelines and if the do not issue TEARDOWNs then those pipelines will also
remain up and running.  This is a resource leak in my opinion.  I have a patch
which I am testing and will be posting soon for your inspection and testing.

Created attachment 192819 [details] [review]
Patch to destroy pipeline on client disconnect with no prior TEARDOWN.

Here is the patch...

Let me know if there are alternate proposals to this proposed patch.  I don't know the RTSP server very well, the change in this patch made sense to me, but there may be a more elegant and sensible solution.

(In reply to comment #6)
> > I am experiencing the same problem.
> > 
> > GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
> > 
> > CRITICAL **: gst_rtsp_media_factory_get_auth: assertion
> > `GST_IS_RTSP_MEDIA_FACTORY (factory)' failed
> 
> Great, maybe you can help track it down and fix it :)

Hi Tim,

When you get a chance, would you review my patch for this bug.  Thanks in advance.

Best Regards,

Rob Krakora

Comment on attachment 192819 [details] [review]
Patch to destroy pipeline on client disconnect with no prior TEARDOWN.

--- /home/silentm/Development/gst-rtsp-server/gst/rtsp-server/rtsp-client.c	2011-08-05 07:48:26.742988486 -0400
+++ /home/silentm/Development/gst-rtsp-server-patched/gst/rtsp-server/rtsp-client.c	2011-08-04 16:48:18.109986945 -0400
@@ -121,8 +121,10 @@
 
   /* unlink all media managed in this session */
   for (medias = session->medias; medias; medias = g_list_next (medias)) {
-    unlink_session_streams (client, session,
-        (GstRTSPSessionMedia *) medias->data);
+    gst_rtsp_session_media_set_state ((GstRTSPSessionMedia *) medias->data, GST_STATE_NULL);
+    unlink_session_streams (client, session, (GstRTSPSessionMedia *) medias->data);
+    /* unmanage the media in the session. */
+    gst_rtsp_session_release_media (session, (GstRTSPSessionMedia *) medias->data);
   }
 }

Created attachment 193306 [details] [review]
Updated: Patch to destroy pipeline on client disconnect with no prior TEARDOWN.

Updated the patch...two function calls were reversed...

Created attachment 193307 [details] [review]
Updated (: Patch to destroy pipeline on client disconnect with no prior TEARDOWN.

Forgot to obsolete prior patches on last update...same as last updated patch...

Thanks!

commit f7223cfdab653409cd92d117c906de166b00623b
Author: Robert Krakora <rob.krakora at messagenetsystems.com>
Date:   Tue Aug 16 12:09:48 2011 +0200

    client: destroy pipeline on client disconnect with no prior TEARDOWN.
    
    The problem occurs when the client abruptly closes the connection without
    issuing a TEARDOWN.  The TEARDOWN handler in the rtsp-client.c file of the RTSP
    server is where the pipeline gets torn down.  Since this handler is not called,
    the pipeline remains and is up and running.  Subsequent clients get their own
    pipelines and if the do not issue TEARDOWNs then those pipelines will also
    remain up and running.  This is a resource leak.