Resetting RTSP source from the pipeline causing errors?

On deepstream 4.0.2, observed on both Jetson and Xavier devies, tried applying patch as suggested in,
Reconnection Patch

From the logs I see the source trying to reset when the stream is not readable,
The different logs I get,
On Xavier,
** WARN: <watch_source_status:496>: No data from source 7 since last 60 sec. Trying reconnection
** INFO: <reset_source_pipeline:939>: Resetting source 7
ERROR from src_elem7: Unhandled error
Debug info: gstrtspsrc.c(6161): gst_rtspsrc_send (): /GstPipeline:pipeline/GstBin:multi_src_bin/GstBin:src_sub_bin7/GstRTSPSrc:src_elem7:
Option not supported (551)

Similarly on a Nano,
WARN: <watch_source_status:496>: No data from source 1 since last 60 sec. Trying reconnection
** INFO: <reset_source_pipeline:939>: Resetting source 1
ERROR from src_elem1: Unhandled error
Debug info: gstrtspsrc.c(6161): gst_rtspsrc_send (): /GstPipeline:pipeline/GstBin:multi_src_bin/GstBin:src_sub_bin1/GstRTSPSrc:src_elem1:
Option not supported (551)
ERROR from src_elem1: Could not write to resource.
Debug info: gstrtspsrc.c(8244): gst_rtspsrc_pause (): /GstPipeline:pipeline/GstBin:multi_src_bin/GstBin:src_sub_bin1/GstRTSPSrc:src_elem1:
Could not send message. (Generic error)

And after that it seems like the resetting of the particular source failed. Any idea as to how to fix it. Thanks.

Hi,
We have DeepStream SDK5.0 released. Please update to the release and give it a try.

There’d be a significant amount of porting required since there’s already a lot of work already being done on 4.0.2 on our end. But, I’ve been close to getting to the root of this problem (I think, really unsure),
What I’ve observed in general is that with resetting,

  1. Although the resetting works perfectly fine for a single source, i.e, in a scenario where we have a single source running in the app or multiple sources running with the same url, the reset works as expected.

  2. In a scenario with multiple sources and different url, the source reset seems works but I think there is some aspect of it missing ends up in a scenario where the source is reset but doesn’t get the latest frames to muxer, here is what the fps looks like,
    **PERF: 10.21 (9.22) 5.72 (7.41)
    **PERF: 9.98 (9.33) 0.00 (7.41)
    **PERF: 9.69 (9.38) 0.00 (7.41)
    **PERF: 9.77 (9.43) 0.00 (7.41)
    **PERF: 9.79 (9.46) 0.00 (7.41)
    **PERF: 9.48 (9.46) 0.00 (7.41)
    **PERF: 10.73 (9.57) 0.00 (7.41)
    **PERF: 11.00 (9.69) 0.00 (7.41)
    **PERF: 11.35 (9.81) 0.00 (7.41)
    **PERF: 9.47 (9.79) 0.00 (7.41)
    **PERF: 9.51 (9.77) 0.00 (7.41)
    **PERF: 10.43 (9.81) 0.00 (7.41)
    ** INFO: <reset_source_pipeline:941>: Resetting source 1
    **PERF: 9.84 (9.81) 0.00 (7.41)
    **PERF: 9.39 (9.79) 0.05 (2.26)
    **PERF: 10.36 (9.82) 0.00 (2.26)

    **PERF: FPS 0 (Avg) FPS 1 (Avg)
    **PERF: 9.17 (9.79) 0.00 (2.26)
    **PERF: 9.25 (9.76) 0.00 (2.26)
    **PERF: 10.67 (9.80) 0.00 (2.26)
    **PERF: 10.06 (9.81) 0.00 (2.26)
    **PERF: 9.68 (9.81) 0.00 (2.26)
    **PERF: 9.52 (9.80) 0.00 (2.26)
    **PERF: 10.66 (9.83) 0.00 (2.26)
    **PERF: 9.03 (9.80) 0.00 (2.26)
    **PERF: 10.94 (9.84) 0.00 (2.26)
    **PERF: 10.02 (9.85) 0.00 (2.26)
    **PERF: 10.51 (9.87) 0.00 (2.26)
    **PERF: 9.71 (9.86) 0.00 (2.26)
    **PERF: 10.99 (9.90) 0.00 (2.26)
    **PERF: 10.52 (9.92) 0.00 (2.26)
    **PERF: 10.48 (9.93) 0.00 (2.26)
    **PERF: 9.62 (9.92) 0.00 (2.26)
    **PERF: 9.78 (9.92) 0.00 (2.26)
    **PERF: 10.53 (9.94) 0.00 (2.26)
    **PERF: 10.06 (9.94) 0.00 (2.26)
    PERF: 9.67 (9.93) 0.00 (2.26)
    ^C
    ERROR: <_intr_handler:2818>: User Interrupted…

This issue I felt is somewhat linked to this post,
Similar Scenario

Not sure where to add in the source code the line gst_pad_send_event (mux_sink_pad, gst_event_new_flush_stop (FALSE)); if the issue is something similar. Could you please redirect if the issue is linked to it? Else could you explain what’s going wrong and how to fix it?

After enabling GST_DEBUG with streammux (forgot the syntax but came across it in the forum) the muxer wasn’t getting data from the source where fps turns 0 after reset, but was getting latest frame data from the other source. Would it still be possible to solve it without having to port to 5.

Hi,
Dynamically adding/deleting sources ins demonstrated in the sample:

You may refer to it for developing the application.

Running with unstable RTSP sources is not well verified on DS4.0.2. Several error cases are reported and fixed in DS5.0. There still might be other error cases but should be more stable. The modification is significant and may not able to be applied to DS4.0.2. If you are not able to do uprade, we would suggest terminate and restart the pipeline if RTSP sources are not able to steadily offer video stream and hits error.

Regarding terminating and restarting the pipeline, can it be done within the pipeline, right now the solution that I can think of is using a shell script monitoring the logs of the app and restarting the process. Is there any other solution to it.