GStreamer/DeepStream Times Out with One Camera but Works in VLC/ffplay

I’m running a DeepStream 6.4 application inside the official DeepStream 6.4 Docker container from NGC. My app processes multiple RTSP camera streams. Most of them work fine, except for one specific camera that always times out in GStreamer/DeepStream—yet the same camera opens instantly in VLC or ffplay within the same Docker container.

Below is a simple pipeline I’m testing:

GST_DEBUG=3 gst-launch-1.0 \
    rtspsrc debug=1 protocols=4 location="rtsp://<user>:<password>@<camera-ip>/..." \
    ! decodebin ! nvvideoconvert ! videoconvert ! autovideosink

Here’s the failing log :

Setting pipeline to PAUSED ...
0:00:00.918042613  1156 0x624dba3c0c90 WARN                 kmssink gstkmssink.c:850:gst_kms_sink_start:<autovideosink0-actual-sink-kms> error: Could not open DRM module (NULL)
0:00:00.918060069  1156 0x624dba3c0c90 WARN                 kmssink gstkmssink.c:850:gst_kms_sink_start:<autovideosink0-actual-sink-kms> error: reason: No such file or directory (2)
0:00:00.918104104  1156 0x624dba3c0c90 WARN                basesink gstbasesink.c:5878:gst_base_sink_change_state:<autovideosink0-actual-sink-kms> error: Failed to start
Pipeline is live and does not need PREROLL ...
0:00:00.984404878  1156 0x624dba3c0c90 WARN               structure gststructure.c:2091:priv_gst_structure_append_to_gstring: No value transform to serialize field 'display' of type 'GstEGLDisplay'
Got context from element 'autovideosink0-actual-sink-nveglgles': gst.egl.EGLDisplay=context, display=(GstEGLDisplay)NULL;
Progress: (open) Opening Stream
Pipeline is PREROLLED ...
Prerolled, waiting for progress to finish...
Progress: (connect) Connecting to rtsp://<user>:<password>@<camera-ip>/...
Progress: (open) Retrieving server options
0:00:21.018987408  1156 0x624dba2c2b60 WARN                 rtspsrc gstrtspsrc.c:6523:gst_rtsp_src_receive_response:<rtspsrc0> error: Could not receive message. (Timeout while waiting for server response)
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not read from resource.
Additional debug info:
... gst_rtspsrc.c(6523): gst_rtsp_src_receive_response ():
Could not receive message. (Timeout while waiting for server response)
ERROR: pipeline doesn't want to preroll.
0:00:21.019087035  1156 0x624dba2c2b60 WARN                 rtspsrc gstrtspsrc.c:6621:gst_rtspsrc_try_send:<rtspsrc0> error: Could not receive message. (Timeout while waiting for server response)
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not read from resource.
Additional debug info:
... gst_rtspsrc.c(6621): gst_rtspsrc_try_send ():
Could not receive message. (Timeout while waiting for server response)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
0:00:21.019161250  1156 0x624dba2c2b60 WARN                 rtspsrc gstrtspsrc.c:8216:gst_rtspsrc_open:<rtspsrc0> can't get sdp
0:00:21.019175044  1156 0x624dba2c2b60 WARN                 rtspsrc gstrtspsrc.c:6227:gst_rtspsrc_loop:<rtspsrc0> we are not connected
Freeing pipeline ...

Meanwhile, if I run ffplay "rtsp://<user>:<password>@<camera-ip>/..." in the same container, it connects and plays fine.

What I’ve Tried

  1. Forcing TCP with rtspsrc protocols=4.
  2. Increasing latency/timeout in rtspsrc.
  3. Setting user-agent to mimic ffplay or VLC.
  4. Passing credentials in both the RTSP URL and via user-id/user-pw.
  5. Verified that other RTSP sources work fine using the same pipeline.
  6. Confirmed it’s not a basic network or Docker issue (ffplay inside the container works).

No matter what, the pipeline times out on “Retrieving server options” for this particular camera.

Question

Why can VLC/ffplay receive the stream from this camera without issue, but GStreamer/DeepStream consistently times out?

Any insights or suggestions would be greatly appreciated!

The rtspsrc plugin of the Gstreamer strictly follows RFC 2326 and therefore does not (yet) support RealMedia/Quicktime/Microsoft extensions. It could be that Gstreamer doesn’t support your camera’s rtsp stream.

Thank you for your input. We are working with several typical IP cameras, including the Dahua DH-IPC-HDW1230T1-S5, which we are encountering issues with when using GStreamer and DeepStream. These cameras stream without issue on VLC or ffplay, but we are unable to bring them into GStreamer/DeepStream pipelines. This is causing failures in our DeepStream applications.

Could you provide some guidance on what we can do in situations like this, where cameras that work fine in VLC/ffplay are not compatible with GStreamer/DeepStream?

Any suggestions or insights would be greatly appreciated!

Thank you for your response and clarification regarding GStreamer’s strict adherence to RFC 2326.

After further investigation, I have discovered something important:

  1. GStreamer Version Impact:
  • DeepStream currently supports GStreamer 1.20.3 as its latest version.
  • I tested GStreamer 1.24.7 on a separate Docker container running Ubuntu 24.04.
  • With GStreamer 1.24.7, the problematic camera stream works perfectly without any issues.This suggests that the problem is likely due to GStreamer 1.20.3 lacking support for certain RTSP stream formats, which have been resolved in newer versions.
  1. Workaround Using an NVR:
  • When trying to receive the problematic camera stream directly using GStreamer 1.20.3, it fails to connect.
  • However, when I first connect the camera to an NVR and then receive the stream from the NVR’s output, it works fine in GStreamer 1.20.3.
  • This means the NVR is likely reformatting the stream into a version that GStreamer 1.20.3 can handle.

Conclusion

It seems DeepStream needs to update its GStreamer version in future releases to improve compatibility with newer RTSP camera streams. Since GStreamer 1.24.7 works without issues, this could be a potential solution.

Would NVIDIA consider updating DeepStream’s GStreamer version in upcoming releases? Also, is there any recommended workaround for users experiencing similar compatibility issues?

Looking forward to your thoughts!

Best regards,

Thanks for your investigation. We will update the relevant software in the future version. But for the related future specific OS and Gstreamer version, please pay attention to our future release.