nvv4l2h264enc w Docker Jetson Orin: rozwiązywanie problemów

Automatyczne rozwiązywanie problemów: dlaczego nvv4l2h264enc przestaje działać w Dockerze na Jetson Orin NX

Sprzętowe kodowanie H.264 przez nvv4l2h264enc działa na hoście Jetson Orin NX z JetPack 6.2.2, ale kończy się błędem wewnątrz kontenerów Docker. Potok GStreamer videotestsrc ! nvvidconv ! 'video/x-raw(memory:NVMM), framerate=5/1' ! nvv4l2h264enc ! fakesink na hoście generuje logi inicjalizacji NVENC: NvMMLiteOpen, NvVideo: NVENC. W kontenerze z --runtime=nvidia --privileged — awaria: ENC_CTX(...) Error in initializing nvenc context i Could not get/set settings from/on resource. Device is in streaming mode.

Konfiguracja: Jetson Orin NX, JetPack 6.2.2 (L4T R36.5.0, jądro 5.15.185-tegra), kontener nvcr.io/nvidia/deepstream-l4t:7.1-samples-multiarch.

Wykluczone przyczyny

Sprawdzenie wykazało pełną identyczność środowisk:

• Urządzenia /dev/nvmap, /dev/host1x-fence, /dev/dri/renderD128, /dev/nvgpu/igpu0/*, /dev/v4l2-nvenc dostępne z pasującymi numerami major/minor.
• Sumy kontrolne bibliotek (libnvtvmr.so, libnvrm_host1x.so, libtegrav4l2.so, libv4l2_nvvideocodec.so, libnvmmlite_video.so) identyczne na hoście i w kontenerze.
• Test DRM na DRM_IOCTL_TEGRA_CHANNEL_OPEN (klasa NVENC 0x21) udany: context=1, version=35, capabilities=1.
• --privileged wyłącza seccomp/AppArmor/cgroups, NVIDIA_VISIBLE_DEVICES=all nie ma wpływu.
• sysfs (/sys/bus/nvmem/devices/fuse/nvmem, /sys/devices/soc0/*) czytelny, chip identyfikowany jako Tegra234 (soc_id=35).

Diagnostyka przez strace

Śledzenie strace -f -e trace=ioctl wykazało różnicę:

| Metryka | Host | Kontener |

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

| Wszystkie ioctl | 2016 | 1644 |

| DRM_IOCTL | 236 | 36 |

| DRM_IOCTL_TEGRA_CHANNEL_OPEN | Tak | Nie |

Na hoście strumień enkodera otwiera kanał DRM NVENC. W kontenerze — tylko DRM_IOCTL_VERSION, bez przejścia do kanału. Pełne śledzenie strace -f pokazało: wątek w kontenerze tworzy procesy potomne lsmod (exit 127) i grep nvgpu (pusty potok, exit 1).

Biblioteka NVMM sprawdza obecność modułu nvgpu przez polecenie shell lsmod | grep nvgpu. Brak lsmod prowadzi do niepowodzenia inicjalizacji NVENC.

Łańcuch:

libnvv4l2.so
  └─ libv4l2_nvvideocodec.so
       └─ libnvtvmr.so (Tegra Video Resource Manager)
            └─ system("lsmod | grep nvgpu")
                 └─ sh: lsmod: not found
                      └─ grep czyta pusty potok → exit 1
                           └─ libnvtvmr: brak GPU → anulowanie NVENC

Naprawa

Instalacja pakietu kmod rozwiązuje problem:

apt-get install -y kmod

W Dockerfile:

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

Po instalacji potok się inicjalizuje:

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

Przyczyny i kontekst

W JetPack 5.x (Xavier) kontenery pobierały kmod jako zależność. DeepStream L4T 7.1 dla JetPack 6.x używa kompaktowej bazy bez niego. Na hoście Ubuntu kmod jest zainstalowany domyślnie.

Błąd Error in initializing nvenc context jest nieinformatywny. Ostrzeżenie sh: lsmod: not found od gst-plugin-scanner ginie wśród logów, stderr przekierowany do /dev/null.

Co jest ważne

• --privileged nie kompensuje braku binarek: DRM/sysfs dostępne, ale biblioteka je ignoruje.
• Zależność NVMM od wywołań shell (lsmod) komplikuje debugowanie zamkniętych bibliotek — wymaga strace.
• Instaluj kmod w kontenerach Jetson dla zadań NVMM (H.264/AV1 encode/decode, VIC).
• Ignorowanie lsmod: not found w gst-plugin-scanner prowadzi do awarii potoków.
• Problem specyficzny dla JetPack 6.x: sprawdzanie modułów przez narzędzia zamiast /proc/modules lub sysfs.

— Editorial Team