Warning: gst-resource-error-quark: Could not read from resource

Accelerated Computing Intelligent Video Analytics DeepStream SDK
1

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU) - Jetson Nano
• DeepStream Version - 6.0.1
• JetPack Version (valid for Jetson only) 4.6.3
• TensorRT Version - 8.2
• NVIDIA GPU Driver Version (valid for GPU only) - 10.2
• Issue Type( questions, new requirements, bugs)

Warning: gst-resource-error-quark: Could not read from resource. (9): gstrtspsrc.c(5293): gst_rtspsrc_loop_udp (): /GstPipeline:pipeline0/GstBin:source-bin-05/GstURIDecodeBin:uri-decode-bin/GstRTSPSrc:source:
Unhandled return value -7.
Error: gst-resource-error-quark: Could not read from resource. (9): gstrtspsrc.c(5361): gst_rtspsrc_loop_udp (): /GstPipeline:pipeline0/GstBin:source-bin-05/GstURIDecodeBin:uri-decode-bin/GstRTSPSrc:source:
Could not receive message. (System error)
Exiting app

• 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)

By removing or disconnecting ip cam, you can reproduce this error.

pipeline
pipeline1920×1207 170 KB

• Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)

How to handle above exception and reconnect without Exiting deepstream app?

3
  1. the screenshot is not clear, please share a zip file.
  2. which same are you referring to?
  3. about reconnecting functionality, please refer to watch_source_status in opt\nvidia\deepstream\deepstream-6.3\sources\apps\apps-common\src\deepstream_source_bin.c
4

pipeline.zip (4.3 MB)

5
  1. please refer to the last comment. you can monitor the source fps. if fps becomes zero for a while, you can reconnect the RTSP source. the kind of logic are ready in deepstream-app.
  2. or you can use nvurisrcbin, which already has RTSP reconnecting functionality. please find rtsp-reconnect-interval in this doc.
6

I tried both methods but didn’t observe any changes when manually disconnecting the RTSP stream; both methods yielded the same results.

gst-launch-1.0 nvurisrcbin uri=rtsp://admin:admin123@192.168.1.86/live rtsp-reconnect-interval=5 ! nv3dsink

gst-launch-1.0 uridecodebin uri=rtsp://admin:admin123@192.168.1.86/live ! nv3dsink

7

I used nvurisrcbin instead of uridecodebin , and it successfully reconnects within a given interval. However, this reconnection is causing interruptions in all other streams.

In my setup, where I have 8 streams actively running, if one stream gets disconnected or interrupted, I want the other streams to continue running without causing the entire DeepStream application to exit.

8

Thanks for the update. how did you test? could you share the simplified test code?

9

file_loop = True

10

I had a similar re-connection problem using nvurisrcbin with deepstream python test3.

One of your colleagues responded that they have replicated the issue on their end.

11

it is because nvstreammux is waiting timetout. you can lower batched-push-timeout. for example,
streammux.set_property('batched-push-timeout', 33000)
please refer to the doc explanation.

12

@user87838 @gowtham2
with the following modifications based on test3.py, I tested two RTSP sources. the reconnecting functionality worked fine. please refer to the log.
uri_decode_bin.set_property("rtsp-reconnect-interval", 5) streammux.set_property('batched-push-timeout', 33000)
the command-line is
python3 deepstream_test_3.py -i rtsp://127.0.0.1:8554/test rtsp://127.0.0.1:8500/test --file-loop --no-display
two-rtsp-reconnect.txt (350.4 KB)

1 Like
14

I tested on 6 public RTSP streams, for around 40-45 mins the streams were running fine. But then after that I could see that all streams had been disrupted, which I confirmed from the logs and display. The reconnecting functionality tried to reconnect for quite some time but except for stream3, it was not able to do so as shown in the logs.

I checked the streams in both vlc media player and using a simple opencv script, they were running properly or at least had resumed running after the potential disruption. However, in the deepstream pipeline it did not resume the processing.

Something interesting I noticed in the logs is that for stream3, it was not being reset and also its FPS was showing in the range 0.8-1.2. Stream3 was the only stream which was reconnected to successfully.

Appreciate your help regarding this, thank you.

six-streams-rtsp-reconnection.txt (48.1 KB)

Note: I replaced the actual RTSP urls in the logs due to privacy.

15

thanks for the sharing. we will check this 0.8-1.2fps issue.

16

what is the stream3’s actual fps? did the stream3 disconnect then connect during the test? from the logs I did not see stream3 reconnect because there is no “Resetting source rtsp://stream3” printting. what do you mean about “Stream3 was the only stream which was reconnected to successfully” ?

17

Stream3’s actual fps is 15. Yes it disconnected and then reconnected during the test. I had set --no-display as False so I could see that when stream3’s fps in pipeline dropped down to ~ 0, the stream became unresponsive in the display. Even though like you said, there was no “Resetting source rtsp://stream3”, after some time the stream become responsive in the display and the fps also climbed back to ~ 15 as shown in the logs.

“Stream3 was the only stream which was reconnected to successfully” → this means that all 6 streams became unresponsive and after a certain time stream3 was the only one whose processing resumed in the pipeline. All the other streams remained disconnected in the pipeline even though they were/had started working at that time.

18

I’ve been testing these streams for the last 3-4 days. What I’ve observed is that the stream reconnection functionality mostly works properly whenever the streams are disconnected.

However, there have been 2-3 instances when the streams did not reconnect, the logs for 1 of which I have attached above. In these instances, I had to restart the pipeline manually in order to resume the processing of the streams.

19

Thanks for the sharing. Nvurisrcbin will reconnect rtsp source only if rtsp source did not output data in a specific time. there was no “Resetting source rtsp://stream3”, so rtsp source can always output data. how long did you disconnect stream3? could you use network tool like wirshark to check if Nvurisrcbin can receive stream3’s rtp packets after network reconnecting?

20

I didn’t disconnect it myself, I had just left the pipeline running and some time later I noticed that the stream had become unresponsive in the display. Maybe it disconnected for few secs or mins, I don’t know. At that time, I checked the stream in vlc media player and it did play correctly.

I’ve tested local RTSP streams by disconnecting them myself for up to 1 minute and they reconnect successfully. However, like I mentioned before there have been some instances when I left these streams processing in the pipeline overnight and when I checked them later the next day, the streams processing in the pipeline was idle even though the streams were working at that time.

I haven’t used wireshark before but I’ll try it out.

21

this FAQ can improve the RTSP reconnecting performance.

1 Like
22

I’ve done testing today on 2 local RTSP streams (stream0 framerate = 20 and stream1 framerate = 25). According to the FAQ, I set batch-size as 2 and batched-push-timeout as 1000000 us/25 = 40000.

Could you please help since I don’t know where to include this export: * export NVSTREAMMUX_ADAPTIVE_BATCHING=yes