Rtspsrc gets pipeline stuck

Application Development
1

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)

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. The following is an example 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

where 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.

I am using Gstreamer 1.16 (included in Deepstream 6.3) and I, for now, am not able to update to a newer version. Is there a possible solution for this version?

2

Not sure at all, but I’d first investigate a bad timestamp issue.
If you have a NTP server in the LAN, you may also try enabling rtspsrc property ntp-sync=1.

Also be sure that your disk for writing frames is not the bottleneck by trying lower resolution or framerate (Well this wouldn’t tell the disk is the culprit, CPU load or else may explain that, but disk write throughput might also be confirmed).

3

I have verified that the CPU load and disk write throughput are not causing the issue, as all system metrics are well below their limits.

Do you have any suggestions on resolving or investigating this timestamp issue? I have experimented with different properties of the rtspsrc element without success. I do not have an NTP server running at the moment.

4

You didn’t tell if a lower resolution works. There may be other possible causes than what I’ve mentioned above such as network buffer size or else.

Maybe you can get some information for your case with something like:

GST_DEBUG=rtpjitterbuffer:5 gst-launch-1.0 rtspsrc location=rtsp://xxx latency=500 protocols=udp ! queue ! rtph264depay ! h264parse ! avdec_h264 ! fakesink sync=1 |& grep pts

You may also try adjusting latency, also try TCP transport protocol, and tell if it better works.

I may not be able to further help your case, though the better picture of your case you give, the better advice you can expect from someone.