Deadlock in gst_element_release_request_pad with nvstreammux

I look forward to the next release. I’m having other problems even after the example given in the adding-and-removing-streams-during-runtime thread. I’ll create a new topic for it.

Hello @CJR, any update or information for this next release solved for this issue? I found this deadlock happened when there are only one source camera, but when have more than one. The deadlock would not happen. Somehow the streammux always need to feed data in buffer ?

Is the problem solved now?

yes it has been fixed.

1 Like

@CJR and @DaneLLL, I’m still running into this problem with the latest release…
If using a single RTSP Source connected to the nvstreammux, and if the source times out - i.e. with a message of

ERROR  default gstrtspconnection.c:1004:gst_rtsp_connection_connect_with_response: failed to connect: Could not connect to 192.168.0.254: Socket I/O timed out

the following code and call to gst_element_release_request_pad will result in deadlock

        gst_pad_send_event(requestSinkPad, gst_event_new_flush_stop(FALSE));
        if (!gst_pad_unlink(staticSrcPad, requestSinkPad))
        {
           // log error ---
            return false;
        }
        gst_element_release_request_pad(streammux, requestSinkPad]);
        gst_object_unref(requestSinkPad);

Is there something else that I need to do?

Thanks,
Robert.

Hi,
There is a sample to demonstrate it:

Please take a look.

Hi @DaneLLL yes, I’m familiar with the example… and if you look at my code snippet above it is identical.

Your example only deals with removing sources that have been successfully connected. If you are using multiple RTSP sources and the first source fails to connect, calling the above snipped of code to unlink the failed source from the streammux will result in a deadlock.

Once you have a connection the above code works correctly to unlink and remove.

Hi @prominence_ai
If you use DeepStream SDK 5.0 GA, please make a new post to share your environment(use which desktop GPU or Jetson platform) and steps for reproducing the issue. If the default runtime_source_add_delete sample cannot be run to reproduce the issue, please provide a patch on it.

@DaneLLL please see Releasing nvstreammux request pad results in a deadlock