okey,i will try. But it cant explain why it not get deadlock if the input is an invalid file uri.
When the uri is invalid and it is the only one input of nvstreammux, there is no input to nvstreammux, so the batch is empty, pad release can not be evoked.
nvstreammux has its own release_pad implementation.
but for invalid file uri (like file:///home/bbb/bbb.b)as the only one input of nvstreammux,there is no input to nvstreammux, BUT the PAD CAN RELEASE SUCCESSFULLY
file source is not live source, nvstreammux works in another way.
alright, sth get wrong, with input an invalid rtsp and an valid rtsp, the pad CAN BE RELEASE NORMALY for the invalid rtsp, but the pipeline blocked somewhere. Then I commented all the code for remove sourceBin from pipeline, it still leads to block.But with two valid rtsp as inputs,it works well.
the case for 2 valid rtsps as inputs
the case for invalid rtsp and valid rtsp as input
maybe it cased by decoder？
code:deepstream_test3_app.c (19.7 KB)
even for the case: “pad release can only be done when the nvstreammux batch is not empty”, you still dont think its a bug here?
The error needs to be handled, you can not just comments them out. Using g_main_loop_quit() or set the pipeline to NULL state is the way the most gstreamer applications use.
It is not a bug but a limitation. Only for pad release interface, the invalid rtsp uri is just one of the case which will cause the batch empty, but sometimes it is just other reason to cause this happen(e.g. the decoding takes a little bit long time to send the frame to nvstreammux, nvstreammux is waiting for the frame) and the pad may be used later, it is not safe to allow the pad to be released at anytime. The error captured by bus_call may be caused by any reason at any stage of the pipeline, the safest way is to quit the loop which can handle all kinds of errors.
think this sinario please: a multi rtsp inference server built with deepstream framework that can add rtsp url as source dynamicly and do inference.Based on your comment, if the server get an invalid rtsp url as input , what should the server do? shutdown and restart?
1 Like
okey， I uncommented the code for error print
there is no error except source0 timeout：
log here: log.txt (45.8 KB)
have you some advices for this sinario？
any update？
The only suggestion is to check the unreachable rtsp source before you setup the pipeline.
but if the internet is not stable, It still has probability falling to deadlock. For example, the rtsp server is normal during doing the valid checking, but it changes to broken after valid checking.
No, that is not the same case. If the network is not stable and the connection is broken during pipeline playing, the pipeline status is playing status, the pad release will not be blocked.
you misunderstand my words,I mean before add the rtsp source to the pipeline, the rtsp server is normal. But when we decide to add the rtsp uri to our pipeline and playing, the connection is broken,or the rtsp server is down.
so, Can you change sth in streammux to avoid this risk ？
cause this risk can make the infer server dead.
If you want to avoid the blocking, please do not change the element state to NULL before you remove the pad. Just remove the line of “state_return =gst_element_set_state (element, GST_STATE_NULL);” in GST_MESSAGE_ERROR handling will help.