Releasing nvstreammux request pad blocked when input an invalid rtsp url

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU)
GPU
• DeepStream Version
5.0
• JetPack Version (valid for Jetson only)
• TensorRT Version
7.0
• NVIDIA GPU Driver Version (valid for GPU only)
450.80.02
• Issue Type( questions, new requirements, bugs)
questions and maybe its a bug
• How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing)
my issue is same as Releasing nvstreammux request pad results in a deadlock, since this guy did not response, I have to open an new issue.
i provide the demo code(modified from deepstream test 3),and input only an invalid rtsp url (like rtsp://fake.fake.com))
after source get socket timeout ,if you try to release pad from streammux, it blocked.

[deepstream_test3_app.c|attachment]
code here: deepstream_test3_app.c (19.4 KB)
• Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)

I also tried: rtspsrc–>h264Depay–>uridecodebin–>streammux, if source can get connection with rtsp server,all works normally. But if you provide an invalid rtsp url, it’s also blocked.

BTW,if you provide an invalid file uri, it worked normally:

The logic of your codes is wrong. When GST_MESSAGE_ERROR bus error happens, g_main_loop_quit() is evoked, the g_main_loop will finished, you need to handle the pipeline in main(). GLib – 2.0

The original code is OK, the source can not be used, so the app quit.

This is not deepstream related. Even there is no deepstream plugin in your pipeline, you will meet the problem too. Please refer to gstreamer resources.

sorry, this is typo…

i need remove sourcebin before main loop quit

bus_call() is a callback, it is not recommended to do pipeline change in this callback.

For how to remove source, we have a sample. Runtime source addition/removal with DeepStream, DeepStream Reference Application on GitHub — DeepStream 6.1.1 Release documentationdeepstream_reference_apps/runtime_source_add_delete at master · NVIDIA-AI-IOT/deepstream_reference_apps · GitHub

i release streammux pad before the main loop quit() it also blocked:
deepstream_test3_app.c (19.5 KB)

Please refer to Releasing nvstreammux request pad blocked when input an invalid rtsp url - Intelligent Video Analytics / DeepStream SDK - NVIDIA Developer Forums

the sample I have read,but I mean,in this scenario: my pipeline have multi rtsp source to handle, some url may outdate or invalid, so when i added it in pipeline, it would case error(because socket timeout), So I need detect this error then removed this source from pipeline. If I cannot remove source in bus call,how to detect this error?

You want the pipeline keep PLAYING state, right? So you can not use g_main_loop_quit() in GST_MESSAGE_ERROR bus error, whether element delete happens before it or after it, the loop quit, pipeline does not work any longer.

A problem is that all kinds of errors will evoke GST_MESSAGE_ERROR bus call, so how do you know which error to handle the resource?

You can do the pipeline change in another thread. GST_MESSAGE_ERROR bus call captures the error and send message/event to another thread, it is possible. Any way, if you don’t want to finish the pipeline, do not use g_main_loop_quit().

Generally, it is not deepstream related. please google for gstreamer resources.

IT IS THE deepstream related, that is because call “gst_element_release_request_pad (streammux, sinkpad)”; then get dead block, I try to delete “g_main_loop_quit()” in my sample code, it also blocked.

the key point not at g_main_loop_quit() because it blocked before g_main_loop_quit() evoked.

Please run “gst-inspect-1.0 nvstreammux”, the nvstreammux sink pad is not static pad. Pads and capabilities (gstreamer.freedesktop.org)

but why it not blocked if I use an invalid file path?

BTW, the code about “the nvstreammux sink pad is not static pad” is from the sample code: Runtime source addition/removal with DeepStream , DeepStream Reference Application on GitHub — DeepStream 6.3 Release documentationhttps://github.com/NVIDIA-AI-IOT/deepstream_reference_apps/tree/master/runtime_source_add_delete

What is your pad_name? The correct name is “sink_0” or"sink_1" or “sink_2” or …, seems your name is “muxPad”

SINK template: ‘sink_%u’
Availability: On request
Capabilities:
video/x-raw(memory:NVMM)
format: { (string)NV12, (string)RGBA }
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]
video/x-raw
format: { (string)NV12, (string)RGBA }
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]

no…my pad name is sink_0 for thefirst rtspsource, if you run my code ,you can get the log:


muxPad is the key for g_object set/get data(see my code line: 409 g_object_set_data(G_OBJECT(source_bin),“muxPad”,pad_name); and line: 191 padname= (gchar )g_object_get_data((GObject)element,“muxPad”);)
for more details for g_object_set_data/g_object_get_data you can reference:GObject – 2.0

and… if the pad_name not correct then get dead block? I dont think it make sense.

I checked thenvstreammux code, seems the pad release can only be done when the nvstreammux batch is not empty. So you can try with two rtsp streams, one is invalid and the other is valid.