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

Accelerated Computing Intelligent Video Analytics DeepStream SDK
,
1

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.

3

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

5

@Amycao

Is there any updates or alternative to get this working properly ?

I have tried the following pipeline as a workaround to get the video sink on the HDMI output.
I runs properly (within Docker) but as the buffers are transferred to the CPU for processing the performance is too low to be used for digital signage for example and affect the whole pipeline quality.

GST_DEBUG=3 gst-launch-1.0 nvurisrcbin uri=file:///opt/nvidia/deepstream/deepstream/samples/streams/sample_1080p_h264.mp4 source-id=0 ! \
queue  ! \
nvvideoconvert ! \
video/x-raw, width=1920, height=1080, framerate=30/1 ! \
queue ! \
videoconvert ! \
video/x-raw, width=1920, height=1080, framerate=30/1 ! \
queue ! \
fbdevsink sync=0

Thank you for your help in this matter

6

Probably it’s an unsupported use case, nvdrmvideosink only work well when there’s no compositor running in background, and that’s not possible inside a docker. It may have worked by fluke, but this is not a supported use case IMO.

7

Can you run pipeline 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
directly from device?
if you need nvdrmvideosink, you need to run from device. otherwise, the pipeline which includes transfer the GPU buffer to CPU buffer is unavoidable.
you can consider using nveglglessink instead.

GST_DEBUG=3 gst-launch-1.0 nvurisrcbin uri=file:///opt/nvidia/deepstream/deepstream/samples/streams/sample_1080p_h264.mp4 source-id=0 !
queue !
nvvideoconvert !
video/x-raw, width=1920, height=1080, framerate=30/1 !
queue !
videoconvert !
video/x-raw, width=1920, height=1080, framerate=30/1 !
queue !
fbdevsink sync=0

8

As mentioned in my initial post I can run the pipeline using nvdrmvideosink from the host only but not from the docker container (based on Nvidia official image).
It is a regression in Deepstream 6.1.1 as it was working properly in Deepstream 6.0 (docker image)

As for nveglglessink correct me if I am wrong but it requires a X server / Wayland to run. Our environment is headless which is anyway required for nvdrmvideosink not to conflict with the compositor.

9

see comment 5

10

If the nvdrmvideosink plugin is not supported in docker containers from 5.0.2GA / DP 6.1.1 it would be great if it could be reflected in the documentation to make it clear.
I think as cloud native applications are progressing on the edge being able to support digital signage applications using Docker could be great.
At this stage I understand the Jetson is not the right solution for that if we build such containerized applications.

2 Likes