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)
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.
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?