nvv4l2h264enc dans Docker Jetson Orin : dépannage

Dépannage automatique : Pourquoi nvv4l2h264enc échoue dans Docker sur Jetson Orin NX

L'encodage matériel H.264 via nvv4l2h264enc fonctionne sur l'hôte Jetson Orin NX avec JetPack 6.2.2 mais échoue à l'intérieur des conteneurs Docker. Le pipeline GStreamer videotestsrc ! nvvidconv ! 'video/x-raw(memory:NVMM), framerate=5/1' ! nvv4l2h264enc ! fakesink sur l'hôte génère les logs d'initialisation NVENC : NvMMLiteOpen, NvVideo: NVENC. Dans un conteneur avec --runtime=nvidia --privileged, il plante avec : ENC_CTX(...) Erreur lors de l'initialisation du contexte nvenc et Impossible d'obtenir/définir les paramètres de/vers la ressource. L'appareil est en mode streaming.

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

Causes exclues

Les tests ont montré des environnements identiques :

• Les périphériques /dev/nvmap, /dev/host1x-fence, /dev/dri/renderD128, /dev/nvgpu/igpu0/*, /dev/v4l2-nvenc sont accessibles avec des numéros majeur/mineur correspondants.
• Les sommes de contrôle des bibliothèques (libnvtvmr.so, libnvrm_host1x.so, libtegrav4l2.so, libv4l2_nvvideocodec.so, libnvmmlite_video.so) sont identiques entre l'hôte et le conteneur.
• Le test DRM pour DRM_IOCTL_TEGRA_CHANNEL_OPEN (classe NVENC 0x21) réussit : contexte=1, version=35, capacités=1.
• --privileged désactive seccomp/AppArmor/cgroups ; NVIDIA_VISIBLE_DEVICES=all n'a aucun effet.
• sysfs (/sys/bus/nvmem/devices/fuse/nvmem, /sys/devices/soc0/*) est lisible ; la puce est identifiée comme Tegra234 (soc_id=35).

Diagnostic via strace

Le traçage avec strace -f -e trace=ioctl a révélé une différence :

| Métrique | Hôte | Conteneur |

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

| Total ioctl | 2016 | 1644 |

| DRM_IOCTL | 236 | 36 |

| DRM_IOCTL_TEGRA_CHANNEL_OPEN | Oui | Non |

Sur l'hôte, le thread d'encodage ouvre un canal DRM pour NVENC. Dans le conteneur—seulement DRM_IOCTL_VERSION, sans passer au canal. Le traçage complet strace -f a montré : le thread du conteneur lance les processus enfants lsmod (sortie 127) et grep nvgpu (tube vide, sortie 1).

La bibliothèque NVMM vérifie le module nvgpu via la commande shell lsmod | grep nvgpu. L'absence de lsmod entraîne l'échec de l'initialisation NVENC.

Chaîne :

libnvv4l2.so
  └─ libv4l2_nvvideocodec.so
       └─ libnvtvmr.so (Tegra Video Resource Manager)
            └─ system("lsmod | grep nvgpu")
                 └─ sh: lsmod: introuvable
                      └─ grep lit un tube vide → sortie 1
                           └─ libnvtvmr: pas de GPU → annulation NVENC

Solution

Installer le paquet kmod résout le problème :

apt-get install -y kmod

Dans Dockerfile :

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

Après installation, le pipeline s'initialise :

Ouverture en MODE BLOQUANT
NvMMLiteOpen : Bloc : BlockType = 4
===== NvVideo: NVENC =====
NvMMLiteBlockCreate : Bloc : BlockType = 4
H264: Profil = 66 Niveau = 0
NVMEDIA: Besoin de définir la bande passante EMC : 21000
NvVideo: bBlitMode est défini sur TRUE
Pipeline est PREROLLED ...

Causes et contexte

Dans JetPack 5.x (Xavier), les conteneurs tiraient kmod comme dépendance. DeepStream L4T 7.1 pour JetPack 6.x utilise une base compacte sans celui-ci. Sur l'hôte Ubuntu, kmod est installé par défaut.

L'erreur Erreur lors de l'initialisation du contexte nvenc est peu informative. L'avertissement sh: lsmod: introuvable de gst-plugin-scanner se perd parmi les logs, avec stderr redirigé vers /dev/null.

Points clés

• --privileged ne compense pas les binaires manquants : DRM/sysfs sont accessibles, mais la bibliothèque les ignore.
• La dépendance de NVMM aux appels shell (lsmod) complique le débogage des bibliothèques fermées—nécessitant strace.
• Installez kmod dans les conteneurs Jetson pour les tâches NVMM (encodage/décodage H.264/AV1, VIC).
• Ignorer lsmod: introuvable dans gst-plugin-scanner conduit à des échecs de pipeline.
• Le problème est spécifique à JetPack 6.x : vérifications de modules via utilitaires au lieu de /proc/modules ou sysfs.

— Editorial Team