Nvdrmvideosink in a gstreamer pipeline from a docker DP 6.1.1 container fails to start

Environment

  • Jetpack 5.0.2GA
  • Jetson NX demo kit
  • Docker
  • Headless (X server deactivated at init level)
  • Image: deepstream-l4t:6.1.1-samples

Tests

From the host

GST_DEBUG=3 gst-launch-1.0 videotestsrc ! video/x-raw,width=1280,height=720 ! queue ! nvdrmvideosink conn_id=0 plane_id=1 set_mode=1 sync=1 -e

This works perfectly fine.

From the container

From the host create the container

sudo docker run -it --rm --net=host --runtime nvidia --privileged -w /opt/nvidia/deepstream/deepstream-6.1 nvcr.io/nvidia/deepstream-l4t:6.1.1-samples

Inside the container

GST_DEBUG=3 gst-launch-1.0 videotestsrc ! video/x-raw,width=1280,height=720 ! queue ! nvdrmvideosink conn_id=0 plane_id=1 set_mode=1 sync=1 -e

This fails

Setting pipeline to PAUSED ...
Could not open DRM failed
0:00:00.182451894  5302 0xaaaac3192c70 ERROR         nvdrmvideosink gstnvdrmvideosink.c:835:gst_nvdrmvideosink_start: drm_util_init failed

0:00:00.182598807  5302 0xaaaac3192c70 WARN                basesink gstbasesink.c:5367:gst_base_sink_change_state:<nvdrmvideosink0> error: Failed to start
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstNvDrmVideoSink:nvdrmvideosink0: GStreamer error: state change failed and some element failed to post a proper error message with the reason for the failure.
Additional debug info:
gstbasesink.c(5367): gst_base_sink_change_state (): /GstPipeline:pipeline0/GstNvDrmVideoSink:nvdrmvideosink0:
Failed to start
Setting pipeline to NULL ...
Freeing pipeline ...

I don’t understand what is the reason especially as it was working fine with Jetpack 4.6 on my Jetson Nano from a docker container using deepstream 6.0 base image.

I have check the release note but it is not clear to me such limitation is expected from the docker container for this new release.

Thank you for letting us know if some alternative exists especially as the nvoverlaysink has been removed either.

I reproduced in JP 5.0.1, Seems this is a bug, need to confirm.