Rtspsrc gets deepstream pipeline stuck

Accelerated Computing Intelligent Video Analytics DeepStream SDK
1

Please provide complete information as applicable to your setup.

• Hardware Platform (tested on both Jetson and dGPU)
• DeepStream Version 6.3/6.4
• JetPack Version (5.1.2)
• NVIDIA GPU Driver Version (535)
• Issue Type( questions, new requirements, bugs)

I have observed an issue while using the rtspsrc element in my pipeline, where it sometimes becomes stuck (maybe instead of receiving an EOS). When this occurs, there are no logs or additional information to diagnose the problem. Using GST_DEBUG=3, I receive the following warning before the application becomes unresponsive:

WARN         rtpjitterbuffer rtpjitterbuffer.c:587:calculate_skew: delta - skew: 0:00:14.483526194 too big, reset skew
 WARN         rtpjitterbuffer rtpjitterbuffer.c:764:rtp_jitter_buffer_calculate_pts: backward timestamps at server, schedule resync
WARN            videodecoder gstvideodecoder.c:2761:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:03.850748385 < 0:00:03.962295429)

This issue has been encountered with DeepStream 6.3. I have read that DeepStream 6.4 includes an update_rtpmanager.sh script, which could potentially address this problem. Unfortunately, this script did not resolve the issue either. In both DeepStream 6.3 and 6.4, I am able to view the stream without interruption using ffplay, even when the pipeline is stuck.

Is this a known issue? Is there a way to resolve it in Deepstream 6.3?

• How to reproduce the issue ?
Reproducing this issue with a real camera is challenging, as the pipeline can become stuck at any time. However, simulating an RTSP stream using rtsp-server seems to consistently reproduce the issue.

• Requirement details

The pipeline links the following elements to read the stream:

    rtspsrc latency=500, protocol=udp
    queue
    rtph264depay
    h264parse
    avdec_h264

Using these elements along with a fakesink or autovideosink can produce the issue.

3 
gst-launch-1.0 rtspsrc location="rtsp://xxx" latency=500  protocols=udp ! queue ! rtph264depay ! h264parse ! nvv4l2decoder ! fakesink

In fact, I used the command line above to test the internal rtsp camera and it worked fine.

I think the problem is related to your network, I don’t know what happened

Some advices.
1.Use protocols=4 to enable TCP.

2.Use the following command to dump stream to ts file for easy reproduce the problem

gst-launch-1.0 -e urisourcebin uri="rtsp://xxx" ! queue ! parsebin ! queue ! h264parse ! mpegtsmux ! filesink location=rtsp.ts
4

Even if the issue is network-related, the problem lies in the pipeline not receiving an error event or EOS (End of Stream), so it incorrectly considers everything to be running smoothly even when rtspsrc stops receiving frames. For example, I used the following GStreamer pipeline:

gst-launch-1.0 rtspsrc location=rtsp://xxx latency=500 protocol=udp ! queue ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! jpegenc ! multifilesink location=folder/%05d.jpg

Initially, frames are saved successfully, but after a certain point, no additional frames are saved. The terminal where the pipeline is running doesn’t show any issues or unexpected events, which is misleading.

Using TCP as the protocol results in more frequent disconnections compared to using UDP.

What’s also confusing me is that ffplay for example can stream the video just fine, but when I use rtspsrc, both in a deepstream pipeline and with a gst-launch command, I keep getting these disconnections.

5

1.ffplay will handle short disconnects and reconnect.You can check here.

If you want reconnect in DeepStream, Please set a suitable value for the rtsp-reconnect-interval property of nvurisrcbin

https://docs.nvidia.com/metropolis/deepstream/dev-guide/text/DS_plugin_gst-nvurisrcbin.html

EOS events are sent by rtspsrc, which is not a feature provided by DeepStream. You can go to the gstreamer forum to discuss, there is relevant code.

6

Okay, thanks for clarifying. I will see if I can find something more on Gstreamer source code.

7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.