Hi,
I am using your DeepStream test example deepstream-demux-multi-in-multi-out with multiple RTSP streams.
When one of the RTSP streams goes down (becomes non-functional) and then comes back online after some time, it is no longer considered by the pipeline — the processing FPS remains stuck (e.g., at 0.2). As a result, I need to manually kill and restart the pipeline for it to work again.
How can I make this recovery automatic, so that the pipeline resumes processing the RTSP stream when it becomes functional again?
You’re encountering a common issue in DeepStream where an RTSP stream that goes down and later comes back online is not automatically recovered by the pipeline, causing the pipeline to freeze.
Recent DeepStream versions include a “new” nvstreammux that handles stream disconnections and reconnections more robustly. If you’re not already using it, you can try switching.
Please provide complete information as applicable to your setup. Thanks Hardware Platform (Jetson / GPU) DeepStream Version JetPack Version (valid for Jetson only) TensorRT Version NVIDIA GPU Driver Version (valid for GPU only) Issue Type( questions, new requirements, bugs) 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) Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)
Thank you @miguel.taylor for your help.
I am using the latest version of DeepStream with the updated new nvstreammux, but I’m still encountering the same issue: when an RTSP stream goes down and then comes back online, it is not automatically reconnected to the pipeline.
As a workaround, I currently restart the entire pipeline when any RTSP stream becomes functional again. However, I’m looking for a more dynamic and optimized solution that can handle reconnections without restarting the pipeline.
Any suggestions or best practices would be greatly appreciated.
Please provide complete information as applicable to your setup. Thanks Hardware Platform (Jetson / GPU): JetPack Version (valid for Jetson only): NVIDIA GPU Driver Version (valid for GPU only):
For the deepstream_demux_multi_in_multi_out.py sample, the default source plugin is uridecodebin which cannot support the reconnect feature. You can try to replace that with our nvurisrcbin and set the parameters related to the reconnect.
I am encountering an issue related to RTSP stream handling when using the new nvstreammux component in DeepStream.
When one of the RTSP streams goes down, the frame rate (FPS) of the remaining active streams drops significantly — for example, from around 20 FPS to 5 FPS. Once the disconnected RTSP stream comes back online, the FPS returns to its normal level.
This problem does not occur when using the legacy (old) nvstreammux, where each stream appears to operate independently and the FPS of functional streams remains stable, even when others are down.
Is there a recommended configuration or approach to ensure that, with the new nvstreammux, each RTSP stream can operate independently — such that a disconnection in one does not impact the processing performance (FPS) of the others?
However, the issue of FPS drop for the functional RTSP streams still occurs when using nvurisrcbin with the new streammux. We chose nvurisrcbin specifically to benefit from its automatic reconnection feature when an RTSP stream goes down and later comes back online.
That said, with the old streammux combined with nvurisrcbin, when one RTSP stream goes down, it does not affect the FPS of the other functional streams—the FPS remains stable.
Is there a way to ensure that the FPS of the functional RTSP streams remains stable (not impacted by other failing streams) while still using the new streammux and nvurisrcbin, in order to benefit from automatic stream management and reconnection?
I have tried that on my side. If you are using new nvstreammux, please set the config-file-path=new_mux.txt parameter for the nvstreammux. new_mux.txt (2.4 KB)
Why did you use max-num-frames-per-batch=1 for the first source and max-num-frames-per-batch=2 for the second one?
Wouldn’t it be better to use a dynamic configuration instead of setting these values statically?