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.
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.
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().
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.
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
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.