RTSP source stops working after 30s - QoS issue

Hi everyone,

Device: Xavier NX Devkit
Jetpack: 5.0.1
L4T 35.1.0
Deepstream 6.1 running on Docker image for ARM
RTSP camera Cisco Meraki MV32 - no metadata attached, 720p, 8fps,

I am running an RTSP-stream using the following Gstreamer string inside a container:

export DISPLAY=:0 gst-launch-1.0 rtspsrc location=rtsp://172.17.15.148:9000/live latency=200 protocols=tcp ! rtph264depay ! h264parse ! nvv4l2decoder ! nvvideoconvert ! nvdsosd ! nvegltransform ! nveglglessink

This pipeline runs for a while until it reaches an EOL signal and closes the connection.
The same happens with uridecodebin or nvurisrcbin. I am getting a drained signaled error that causes the stream to close.

The error messages become a bit less cryptic when switching to rtspsrc. The plugin receives a qos signal and closes the connection. Setting qos=false for the sink did not help.

I suspect an issue with setting up the rtspsink properties properly but I need some guidance regarding the parameters. Is there anything I could / should try?.

See the Debug files attached when running the above pipeline (line 680 in rtsp_gst_debug.txt).
rtsp_gst_debug.txt (138.8 KB)
rtspsrc.txt (769 Bytes)

Can you try the pipeline without any Nvidia plugin?

gst-launch-1.0 rtspsrc location=rtsp://172.17.15.148:9000/live latency=200 protocols=tcp ! rtph264depay ! h264parse ! avdec_h264 ! fakesink

The Problem persists. The rtspsrc log always stops around here:

0:00:39.012627424  2031 0xaaaac8c00cc0 DEBUG                rtspsrc gstrtspsrc.c:5292:gst_rtspsrc_handle_data:<rtspsrc0> pushing data of size 1456 on channel 0
0:00:39.012745889  2031 0xaaaac8c00cc0 DEBUG                rtspsrc gstrtspsrc.c:5483:gst_rtspsrc_loop_interleaved:<rtspsrc0> doing receive with timeout 21 seconds, 149197 usec
0:00:41.013121788  2031 0xffff8003fc00 DEBUG                rtspsrc gstrtspsrc.c:3116:gst_rtspsrc_sink_chain:<rtspsrc0> sending 84 bytes RTCP
0:00:41.013578336  2031 0xffff8003fc00 DEBUG                rtspsrc gstrtspsrc.c:3118:gst_rtspsrc_sink_chain:<rtspsrc0> sent RTCP, 0
0:00:44.398050795  2031 0xffff8003fc00 DEBUG                rtspsrc gstrtspsrc.c:3116:gst_rtspsrc_sink_chain:<rtspsrc0> sending 84 bytes RTCP
0:00:44.399698872  2031 0xffff8003fc00 DEBUG                rtspsrc gstrtspsrc.c:3118:gst_rtspsrc_sink_chain:<rtspsrc0> sent RTCP, 0
0:00:49.452082450  2031 0xffff8003fc00 DEBUG                rtspsrc gstrtspsrc.c:3116:gst_rtspsrc_sink_chain:<rtspsrc0> sending 60 bytes RTCP
0:00:49.453826399  2031 0xffff8003fc00 DEBUG                rtspsrc gstrtspsrc.c:3118:gst_rtspsrc_sink_chain:<rtspsrc0> sent RTCP, 0
0:00:55.313793770  2031 0xffff8003fc00 DEBUG                rtspsrc gstrtspsrc.c:3116:gst_rtspsrc_sink_chain:<rtspsrc0> sending 60 bytes RTCP
0:00:55.316535838  2031 0xffff8003fc00 DEBUG                rtspsrc gstrtspsrc.c:3118:gst_rtspsrc_sink_chain:<rtspsrc0> sent RTCP, 0
0:00:59.033220662  2031 0xaaaac8c00cc0 DEBUG                rtspsrc gstrtspsrc.c:5501:gst_rtspsrc_loop_interleaved:<rtspsrc0> timeout, sending keep-alive
0:00:59.033310679  2031 0xaaaac8c00cc0 DEBUG                rtspsrc gstrtspsrc.c:5190:gst_rtspsrc_send_keep_alive:<rtspsrc0> creating server keep-alive
0:00:59.033840859  2031 0xaaaac8c00cc0 DEBUG                rtspsrc gstrtspsrc.c:5483:gst_rtspsrc_loop_interleaved:<rtspsrc0> doing receive with timeout 59 seconds, 999994 usec
0:01:00.382545984  2031 0xffff8003fc00 DEBUG                rtspsrc gstrtspsrc.c:3116:gst_rtspsrc_sink_chain:<rtspsrc0> sending 60 bytes RTCP
0:01:00.382947171  2031 0xffff8003fc00 DEBUG                rtspsrc gstrtspsrc.c:3118:gst_rtspsrc_sink_chain:<rtspsrc0> sent RTCP, 0
0:01:06.059474662  2031 0xffff8003fc00 WARN                 rtspsrc gstrtspsrc.c:3458:on_timeout_common:<rtspsrc0> source 7d70c1fa, stream 7d70c1fa in session 0 timed out
0:01:06.059559815  2031 0xffff8003fc00 DEBUG                rtspsrc gstrtspsrc.c:3418:gst_rtspsrc_do_stream_eos:<rtspsrc0> setting stream for session 0 to EOS
Got EOS from element "pipeline0".
Execution ended after 0:01:05.899511216
Setting pipeline to NULL ...

Setting latency=50000 increases the lifetime of the pipeline from 30sec to ~10min so it seems like I have a performance problem.
Setting do-latency-drop=true did not resolve the problem either.

Streaming with VLC works indefinetly, so I am certain that the rtsp itself works.

Can you raise this issue to GStreamer community? It has nothing to do with DeepStream.

Contributing to GStreamer

That answer is a bit disappointing but understandable given the fact that the problem lies between the camera stream and Gstreamer, not Deepstream.

Thank you nonetheless.

Just to one follow up to make things clear:
The usual, nvidias intended way to access an rtsp stream from IP cameras should be made via uridecodebin, or nvurisrcbin, right?

uridecodebin also uses rtspsrc inside. nvurisrcbin uses uridecodebin inside. You can use any of them for your convenience.

THanks for clarifying, marking this as “solved”.

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