• Hardware Platform (Jetson / GPU) AGX Orin • DeepStream Version 7.1 • JetPack Version (valid for Jetson only) 6.2 (L4T 36.4.3)
I have a pipeline running four RTSP cameras with inference, analytics, and tracking. In previous DeepStream versions (DS 7.0, DS 6.2, DS 6.3), if a camera disconnected, I would receive the following log message:
gst-stream-error-quark: No data from source since last 5 sec. Trying reconnection (1)
However, the camera would instantly reconnect without any noticeable issues.
After upgrading to DeepStream 7.1, I still get the same initial behavior, but now the camera usually does not reconnect. Upon further inspection, I noticed an issue related to the source ID:
When the reconnection is successful, the log shows the correct source ID.
When it fails, I see:
Resetting source -1, attempts: 1
No further reconnection attempts occur, and the camera remains disconnected.
Question:
Why does this issue occur in DeepStream 7.1 but not in previous versions like DS 7.0 or DS 6.2/6.3? Could this be a bug or a change in the way nvmultiurisrcbin/nvurisrcbin handles reconnections?
I haven’t made any pipeline code changes since upgrading to DeepStream 7.1, so I’m unsure if the issue originates from my implementation. However, the fact remains that I did not experience this issue in previous versions.
nvurisrcbin is opensource. the code path is \opt\nvidia\deepstream\deepstream\sources\gst-plugins\gst-nvurisrcbin\gstdsnvurisrcbin.cpp
If sourceid is not set for nvurisrcbin, the app will print “Resetting source -1” when reconnecting.
I can’t reprodcue this issue on DS7.1. could you help to reprodcue this issue? please refer to my test.
start rtspsrever.
play the rtsp url with “gst-launch-1.0 nvurisrcbin uri=rtsp://127.0.0.1:8554/test rtsp-reconnect-interval=10 ! fakesink”
restart rtspserver. the pipeline reconnected successfully even though it printed “Resetting source -1”. please the log log.txt (3.4 KB).
I’m encountering several errors while running the nvcr.io/nvidia/deepstream:7.1-samples-multiarch container.
My pipeline fails to write to the RTSP resource when changed to TCP instead of UDP, and upon further inspection, several GStreamer plugins aren’t loading properly.
With UDP: It tries to reconnect once but hangs afterward.
With TCP: It tries to reconnect but throws “could not write to resource” EOF errors.
After a dozen restarts, the pipeline starts normally, and four cameras in my current setup work without issues — even reconnections function as expected. However, every time I restart, there is high chance one random camera hangs as described.
nvurisrcbin/nvmultiurisrcbin->fakesink seem to work without any problems.
Here’s the specific log output for the GStreamer plugin failures and TCP errors:
(gst-plugin-scanner:147): GStreamer-WARNING **: 04:34:10.791: Failed to load plugin '/usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstfaad.so': libfaad.so.2: cannot open shared object file: No such file or directory.
(gst-plugin-scanner:147): GStreamer-WARNING **: 04:34:10.883: Failed to load plugin '/usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstvoaacenc.so': libvo-aacenc.so.0: cannot open shared object file: No such file or directory.
(gst-plugin-scanner:147): GStreamer-WARNING **: 04:34:10.961: Failed to load plugin '/usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstmpeg2enc.so': libmjpegutils-2.1.so.0: cannot open shared object file: No such file or directory.
(gst-plugin-scanner:147): GStreamer-WARNING **: 04:34:11.008: Failed to load plugin '/usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstmplex.so': libmjpegutils-2.1.so.0: cannot open shared object file: No such file or directory.
(gst-plugin-scanner:147): GStreamer-WARNING **: 04:34:11.034: Failed to load plugin '/usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstopenh264.so': libopenh264.so.6: cannot open shared object file: No such file or directory.
(Argus) Error FileOperationFailed: Connecting to nvargus-daemon failed: No such file or directory (in src/rpc/socket/client/SocketClientDispatch.cpp, function openSocketConnection(), line 205).
(Argus) Error FileOperationFailed: Cannot create camera provider (in src/rpc/socket/client/SocketClientDispatch.cpp, function createCameraProvider(), line 107).
(gst-plugin-scanner:147): GStreamer-WARNING **: 04:34:11.982: Failed to load plugin '/usr/lib/aarch64-linux-gnu/gstreamer-1.0/deepstream/libnvdsgst_inferserver.so': libtritonserver.so: cannot open shared object file: No such file or directory.
(gst-plugin-scanner:147): GStreamer-WARNING **: 04:34:12.015: Failed to load plugin '/usr/lib/aarch64-linux-gnu/gstreamer-1.0/deepstream/libnvdsgst_udp.so': librivermax.so.0: cannot open shared object file: No such file or directory.
2025-03-21 04:34:12,143 INFO LPRDeepstream.pipeline Creating Pipeline [ pipeline.py:55 ].
gst-resource-error-quark: Could not write to resource. (10): ../gst/rtsp/gstrtspsrc.c(6607): gst_rtspsrc_try_send (): /GstPipeline:pipeline0/GstDsNvMultiUriBin:Stream-muxer/GstBin:Stream-muxer_creator/GstDsNvUriSrcBin:dsnvurisrcbin3/GstRTSPSrc:src:.
Could not send message. (Received end-of-file) [ logger.py:26 ].
2025-03-21 04:33:24,885 ERROR LPRDeepstream_out_a Warning: gst-resource-error-quark: Could not write to resource. (10): ../gst/rtsp/gstrtspsrc.c(9034): gst_rtspsrc_pause (): /GstPipeline:pipeline0/GstDsNvMultiUriBin:Stream-muxer/GstBin:Stream-muxer_creator/GstDsNvUriSrcBin:dsnvurisrcbin3/GstRTSPSrc:src:.
Could not send message. (Received end-of-file).
What I’ve tried:
Switched from UDP to TCP for the RTSP stream, but the issue persists.
Verified the missing libraries, but they don’t seem to be included in the container by default.
Tried simple src → fakesink pipeline and it worked without any issues
Questions:
Are these missing plugins required for proper RTSP handling?
Could these missing libraries be the cause of random camera failures on startup and reconnection?
Is there any recommended way to install these plugins or modify the container to avoid these errors?
Additionally, it seems that the source ID is not the issue. From my application logs, I can see that in some cases the correct source ID is received, but the pipeline still hangs on the first reconnect, camera is not starting properly.
please ignore these “Failed to load plugin” warning logs. these are related with rtsp receiving. please refer to Gstreamer opensource rtspsrc.
there is severe error “Received end-of-file” caused by source. why did the rtspsoruce report this error? how did you handle this error on the application layer?
please ignore these “Failed to load plugin” warning logs. if you need to use nvinferserver plugin. “libtritonserver.so: cannot open shared object file” needs to be fixed.
After further investigation, I discovered that the issue was related to linking my full pipeline, including both of my models. It took longer than expected to set up, which ended up blocking the RTSP connection.
Because my RTSP reconnect interval was set to 5 seconds, if the camera didn’t initialize correctly during the pipeline setup, it would never reconnect. Interestingly, when I increased the RTSP reconnect interval to 10 seconds, the issue disappeared entirely.
I’m not sure if this is technically a bug—probably is—since it doesn’t provide any errors or meaningful feedback. For now, I’ve worked around it by introducing a delay during the initialization of some pipeline elements, which allows everything to settle properly before continuing.
