nvv4l2h264enc in Docker Jetson Orin: troubleshooting

Automatic Troubleshooting: Why nvv4l2h264enc Fails in Docker on Jetson Orin NX

H.264 hardware encoding via nvv4l2h264enc works on the Jetson Orin NX host with JetPack 6.2.2 but fails inside Docker containers. The GStreamer pipeline videotestsrc ! nvvidconv ! 'video/x-raw(memory:NVMM), framerate=5/1' ! nvv4l2h264enc ! fakesink on the host outputs NVENC initialization logs: NvMMLiteOpen, NvVideo: NVENC. In a container with --runtime=nvidia --privileged, it crashes with: ENC_CTX(...) Error in initializing nvenc context and Could not get/set settings from/on resource. Device is in streaming mode.

Configuration: Jetson Orin NX, JetPack 6.2.2 (L4T R36.5.0, kernel 5.15.185-tegra), container nvcr.io/nvidia/deepstream-l4t:7.1-samples-multiarch.

Excluded Causes

Testing showed identical environments:

• Devices /dev/nvmap, /dev/host1x-fence, /dev/dri/renderD128, /dev/nvgpu/igpu0/*, /dev/v4l2-nvenc are accessible with matching major/minor numbers.
• Library checksums (libnvtvmr.so, libnvrm_host1x.so, libtegrav4l2.so, libv4l2_nvvideocodec.so, libnvmmlite_video.so) are identical between host and container.
• DRM test for DRM_IOCTL_TEGRA_CHANNEL_OPEN (NVENC class 0x21) succeeds: context=1, version=35, capabilities=1.
• --privileged disables seccomp/AppArmor/cgroups; NVIDIA_VISIBLE_DEVICES=all has no effect.
• sysfs (/sys/bus/nvmem/devices/fuse/nvmem, /sys/devices/soc0/*) is readable; chip identified as Tegra234 (soc_id=35).

Diagnosis via strace

Tracing with strace -f -e trace=ioctl revealed a difference:

| Metric | Host | Container |

|---------------------------|------|-----------|

| Total ioctl | 2016 | 1644 |

| DRM_IOCTL | 236 | 36 |

| DRM_IOCTL_TEGRA_CHANNEL_OPEN | Yes | No |

On the host, the encoder thread opens a DRM channel for NVENC. In the container—only DRM_IOCTL_VERSION, without proceeding to the channel. Full strace -f tracing showed: the container thread spawns child processes lsmod (exit 127) and grep nvgpu (empty pipe, exit 1).

The NVMM library checks for the nvgpu module via the shell command lsmod | grep nvgpu. The absence of lsmod leads to NVENC initialization failure.

Chain:

libnvv4l2.so
  └─ libv4l2_nvvideocodec.so
       └─ libnvtvmr.so (Tegra Video Resource Manager)
            └─ system("lsmod | grep nvgpu")
                 └─ sh: lsmod: not found
                      └─ grep reads empty pipe → exit 1
                           └─ libnvtvmr: no GPU → NVENC cancellation

Fix

Installing the kmod package resolves the issue:

apt-get install -y kmod

In Dockerfile:

RUN apt-get update && apt-get install -y kmod && rm -rf /var/lib/apt/lists/*

After installation, the pipeline initializes:

Opening in BLOCKING MODE
NvMMLiteOpen : Block : BlockType = 4
===== NvVideo: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
H264: Profile = 66 Level = 0
NVMEDIA: Need to set EMC bandwidth : 21000
NvVideo: bBlitMode is set to TRUE
Pipeline is PREROLLED ...

Causes and Context

In JetPack 5.x (Xavier), containers pulled kmod as a dependency. DeepStream L4T 7.1 for JetPack 6.x uses a compact base without it. On the host Ubuntu, kmod is installed by default.

The error Error in initializing nvenc context is uninformative. The warning sh: lsmod: not found from gst-plugin-scanner gets lost among logs, with stderr redirected to /dev/null.

Key Takeaways

• --privileged does not compensate for missing binaries: DRM/sysfs are accessible, but the library ignores them.
• NVMM's dependency on shell calls (lsmod) complicates debugging closed libraries—requiring strace.
• Install kmod in Jetson containers for NVMM tasks (H.264/AV1 encode/decode, VIC).
• Ignoring lsmod: not found in gst-plugin-scanner leads to pipeline failures.
• The issue is specific to JetPack 6.x: module checks via utilities instead of /proc/modules or sysfs.

— Editorial Team