AMD VCN/VCE : pourquoi le bloc codec compte plus que vous ne le pensez

VCN/VCE en termes pratiques de production

Les GPU AMD comportent plusieurs « moteurs ». Les gens s’obsèdent sur les unités de calcul parce que les benchmarks le font. Les pipelines vidéo se soucient d’une autre île de silicium : le bloc codec à fonction fixe.

Ce qu’était VCE

VCE (Video Coding Engine) est l’ancien bloc matériel d’encodage d’AMD, principalement associé à H.264 (AVC) et, sur certaines générations, à HEVC (H.265). Quand VCE fait le travail, votre CPU n’a pas à brûler des cycles pour l’estimation de mouvement, les transformées, le codage entropique et tous les calculs ingrats qui transforment des images en flux de bits.

Ce qu’est VCN

VCN (Video Core Next) est la génération plus récente qui couvre généralement à la fois le decode et l’encode matériels (selon la génération du GPU et les pilotes), et étend le support des codecs. Ce ne sont pas des « shaders plus rapides ». C’est une usine dédiée à la compression et à la décompression vidéo.

Pourquoi la fonction fixe bat le « juste utiliser le GPU »

Le calcul GPU général peut encoder de la vidéo à l’aide de shaders ou de kernels compute, mais ce n’est rarement la meilleure solution en production. L’encodage/décodage à fonction fixe est déterministe, économe en énergie et ne concurrence pas vos charges de rendu ou ML pour les mêmes ressources.

Pensez à VCN/VCE comme au chariot élévateur de votre entrepôt. Vous pouvez porter les cartons à la main (CPU) ou demander au chariot (VCN) de le faire pendant que vos humains s’occupent du travail cognitif. Si vous ne vérifiez pas si le chariot existe, s’il est alimenté et s’il peut atteindre l’étagère, vous continuerez d’embaucher plus d’humains et manquerez toujours les délais d’expédition.

Pourquoi le bloc codec compte plus que vous ne le pensez

1) Il change vos calculs d’évolutivité

Avec l’encodage CPU, la planification de capacité ressemble souvent à : « un transcodage 1080p coûte X cœurs au preset Y ». Avec VCN/VCE, la ressource est généralement une combinaison de :

• débit du bloc codec (sessions, résolution, fps, images B, lookahead, choix de contrôle de débit)
• overhead PCIe et copies mémoire (surtout si vous faites transiter les images CPU↔GPU)
• limitations de concurrence de décodage/encodage du matériel et de la pile pilote
• stabilité du pilote et comportement du firmware sous charge soutenue

Votre nœud peut avoir 64 cœurs CPU et quand même s’étouffer parce que le bloc codec plafonne à moins d’encodages 4K concurrents que prévu. Ou à l’inverse : un CPU modeste peut supporter un nombre surprenant de flux parce que VCN fait le gros du travail.

2) Il change votre profil de latence

Pour le temps réel (WebRTC, visioconférence, streaming live), la latence n’est pas seulement le « temps d’encodage ». C’est aussi la mise en file : des images qui attendent leur tour parce que le bloc codec est saturé ou parce que vous utilisez accidentellement l’encodage logiciel à une étape.

Et oui, vous pouvez avoir un GPU à 10% « d’utilisation » et être pourtant saturé sur VCN. L’utilisation GPU n’est pas une vérité unique ; ce sont plusieurs moteurs avec des plafonds séparés.

3) Il change votre consommation et vos thermiques

L’encodage matériel est en général beaucoup plus efficace énergétiquement que l’encodage CPU. Cela compte dans les datacenters où l’électricité est une limite stricte et dans les appliances en périphérie où le refroidissement est une rumeur.

Petite blague #1 : Rien ne dit « informatique verte » comme déplacer votre encodage de 200W de misère CPU vers un bloc codec qui sue à peine.

4) Il change votre domaine de panne

Les pannes d’encodage logiciel sont généralement « le processus est mort » ou « le CPU est saturé ». Les pannes matérielles peuvent être plus étranges : rechargements de firmware, resets de pilote, anneaux bloqués ou rétrogradations silencieuses vers le logiciel qui ressemblent à des « pics CPU mystérieux ».

Ce n’est pas une raison pour éviter VCN. C’est une raison de le surveiller sérieusement.

5) Il change vos compromis de qualité produit

Tous les encodeurs ne se valent pas. Les encodeurs matériels se sont grandement améliorés, mais ils ont encore des contraintes : moins de réglages, des caractéristiques de contrôle de débit différentes, et parfois une définition différente de « satisfaisant » à bas débit.

Conclusion pratique : si vous livrez un produit où la « qualité par bit » fait la différence, testez l’encodage VCN sur votre mélange de contenu réel. Si vous livrez un produit où « ça marche en temps réel » est le différenciateur, privilégiez VCN et investissez dans le tuning et l’observabilité plutôt que dans une mise à l’échelle CPU héroïque.

Faits intéressants et contexte historique

• Les blocs vidéo à fonction fixe précèdent le battage actuel autour du « GPU compute ». L’assistance au décodage vidéo existe depuis bien plus d’une décennie parce que les codecs sont spécialisés et coûteux en calculs en logiciel.
• Le changement de nom d’AMD de VCE à VCN reflète une refonte plus large. VCN n’est pas juste « VCE v2 » ; c’est une évolution générationnelle qui couvre aussi le décodage de manière plus holistique sur de nombreuses puces.
• Le support des codecs dépend de la génération, pas seulement de la marque. « Radeon » est du marketing ; la génération d’ASIC vous dit ce que le bloc codec peut réellement faire.
• Les piles pilote comptent autant que le silicium. Un bloc codec capable peut être pratiquement indisponible si l’API userspace (AMF/VA-API) n’est pas correctement connectée sur votre build OS.
• Le débit matériel d’encodage n’est pas linéaire avec la résolution. La 4K n’est pas « deux fois du 1080p ». Ce sont plusieurs fois plus de pixels, plus de pression sur les références/la complexité, et parfois des limites internes différentes.
• Des plafonds de session existent en pratique. Même lorsqu’ils ne sont pas officiellement documentés, des systèmes réels atteignent des plafonds de concurrence à cause du firmware, de l’ordonnancement des anneaux ou du comportement des bibliothèques userspace.
• VCN a été façonné par la demande du streaming et de la visioconférence. La montée des appels vidéo ubiquistes a transformé « l’encodage matériel » d’une niche en une attente de base.
• AV1 a changé la donne. Le support du décodage/encodage AV1 est un séparateur générationnel majeur ; il impacte le coût de diffusion de contenu et la stratégie de compatibilité client.

Modes de panne : comment VCN/VCE peut vous gâcher la journée

Rétrogradation silencieuse vers le logiciel : la panne la plus coûteuse

Le désastre le plus courant en production n’est pas « l’encodeur matériel indisponible ». C’est « l’encodeur matériel était indisponible et le système est retombé silencieusement sur le logiciel ». Soudain, vos nœuds de transcodage ont besoin de 4× plus de CPU, la latence explose, et votre autoscaler ressemble à quelqu’un qui essaie de fuir le bâtiment.

Taxe de copie : quand le bus devient le goulot

Si votre pipeline décode sur le GPU, copie les images en mémoire système, exécute un filtre sur le CPU, puis recopie vers le GPU pour l’encodage, vous venez de créer un percepteur de taxe PCIe. Pour des fps élevés ou des résolutions élevées, cette taxe domine.

Instabilité pilote/firmware sous charge prolongée

Des sessions d’encodage longues peuvent déclencher des comportements qui n’apparaissent jamais dans des tests courts : timeouts d’anneau, stalls du firmware ou resets GPU qui font tomber d’autres charges sur le même périphérique.

Régression de qualité déguisée en « problème réseau »

Les différences de contrôle de débit peuvent provoquer des oscillations de bitrate, une qualité instable ou des artefacts de mouvement étranges. Ceux-ci sont souvent attribués au « CDN » parce que c’est le bouc émissaire habituel. Ce n’est pas toujours le CDN.

Contention d’engines à laquelle vous n’avez pas pensé

Sur certaines charges, décodage + encodage + affichage/compute simultanés peuvent se concurrencer pour la bande passante mémoire ou l’ordonnancement, même si le bloc codec lui-même est sain. Cela ressemble à des pertes d’images « aléatoires ».

Petite blague #2 : Si votre monitoring ne suit que « l’utilisation GPU », vous regardez essentiellement le compteur de vitesse pendant que le moteur est en feu.

Guide de diagnostic rapide

L’objectif est de répondre rapidement à une question : quel est le goulot en ce moment—bloc codec, CPU, copies, disque/réseau, ou une rétrogradation logicielle ?

Premier point : prouvez si l’encodage/décodage matériel est réellement engagé

• Vérifiez les logs FFmpeg pour l’initialisation du dispositif matériel et l’utilisation d’images matérielles.
• Vérifiez les capacités VA-API et si le profile/entrypoint correspond à votre codec.
• Surveillez l’utilisation CPU : un job « encodage matériel » qui brûle encore plusieurs cœurs est suspect.

Deuxième point : vérifiez la charge du bloc codec (pas seulement la charge 3D)

• Utilisez radeontop ou les compteurs sysfs si disponibles pour voir l’activité VCN.
• Corrélez la charge VCN avec les images perdues, la profondeur des files d’attente et la latence d’encodage.

Troisième point : identifiez les chemins de copies et conversions de formats cachées

• Cherchez hwdownload/hwupload et les filtres de mise à l’échelle qui forcent des images CPU.
• Vérifiez les formats de pixels ; des conversions RGB accidentelles sont des grenades de performance.

Quatrième point : éliminez l’I/O et le réseau

• Vérifiez le débit de lecture pour les médias sources et le débit d’écriture pour les sorties.
• Pour le live, vérifiez le jitter d’ingest et la congestion de sortie.

Cinquième point : vérifiez les erreurs pilote/firmware

• Scannez les logs du kernel pour les timeouts d’anneau VCN, les resets, et les problèmes de chargement de firmware.
• Vérifiez que les paquets firmware et les versions du kernel correspondent à vos attentes de déploiement.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les vraies tâches « allez regarder » qui vous évitent de deviner. Chacune inclut : la commande, ce que signifie une sortie typique, et la décision suivante à prendre.

Task 1: Identify the GPU and kernel driver in use

cr0x@server:~$ lspci -nnk | sed -n '/VGA compatible controller/,+5p'
0a:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 23 [1002:73ff] (rev c1)
        Subsystem: XFX Limited Device [1682:5005]
        Kernel driver in use: amdgpu
        Kernel modules: amdgpu

Signification : Vous utilisez le pilote kernel amdgpu, requis pour les chemins vidéo matériels principaux sous Linux.

Décision : Si vous voyez vfio-pci (passthrough) ou un pilote générique inattendu, arrêtez-vous et corrigez le binding du pilote avant de toucher FFmpeg.

Task 2: Confirm DRM nodes exist (render node is key)

cr0x@server:~$ ls -l /dev/dri
total 0
drwxr-xr-x 2 root root         80 Jan 10 09:10 by-path
crw-rw---- 1 root video  226,   0 Jan 10 09:10 card0
crw-rw---- 1 root render 226, 128 Jan 10 09:10 renderD128

Signification : renderD128 existe ; l’accès au nœud render DRM/VA-API est possible.

Décision : Si renderD* est absent, suspectez un échec de chargement du pilote, un problème de mapping de périphérique dans un conteneur, ou des permissions.

Task 3: Verify user permissions for the render node

cr0x@server:~$ id
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),44(video),989(render)

Signification : L’utilisateur est dans video et render ; l’accélération matérielle ne faillira pas pour des raisons de permissions.

Décision : Si ce n’est pas le cas, corrigez l’appartenance aux groupes ou le contexte de sécurité du conteneur ; ne faites pas de « sudo FFmpeg » comme stratégie permanente.

Task 4: Check VA-API capabilities (decode/encode profiles)

cr0x@server:~$ vainfo --display drm --device /dev/dri/renderD128 | sed -n '1,35p'
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_20
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.20 (libva 2.20.0)
vainfo: Driver version: Mesa Gallium driver 24.0.0 for AMD Radeon RX 6600 (navi23, LLVM 17.0.6, DRM 3.57, 6.6.0)
vainfo: Supported profile and entrypoints
      VAProfileH264Main            : VAEntrypointVLD
      VAProfileH264Main            : VAEntrypointEncSlice
      VAProfileHEVCMain            : VAEntrypointVLD
      VAProfileHEVCMain            : VAEntrypointEncSlice
      VAProfileAV1Profile0         : VAEntrypointVLD

Signification : VLD = décodage, EncSlice = encodage. Ce GPU/stack supporte l’encodage H.264 et HEVC, et le décodage AV1.

Décision : Si les entrypoints d’encodage sont absents pour votre codec, ne comptez pas sur l’encodage matériel via VA-API sur cette pile ; envisagez AMF (si applicable), une autre génération GPU ou l’encodage CPU.

Task 5: Confirm FFmpeg sees the hardware accelerators

cr0x@server:~$ ffmpeg -hide_banner -hwaccels
Hardware acceleration methods:
vdpau
cuda
vaapi
qsv
drm
opencl
vulkan

Signification : FFmpeg est compilé avec le support VA-API.

Décision : Si vaapi n’apparaît pas, reconstruisez ou installez le paquet FFmpeg approprié. Ne déboguez pas « pourquoi le matériel est lent » si vous ne l’utilisez pas.

Task 6: Test VA-API decode + encode with explicit filters

cr0x@server:~$ ffmpeg -hide_banner -loglevel info \
  -vaapi_device /dev/dri/renderD128 \
  -hwaccel vaapi -hwaccel_output_format vaapi \
  -i input-1080p-h264.mp4 \
  -vf 'scale_vaapi=w=1280:h=720:format=nv12' \
  -c:v h264_vaapi -b:v 3500k -maxrate 3500k -bufsize 7000k \
  -an -y /tmp/out-vaapi.mp4
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_vaapi))
Press [q] to stop, [?] for help
frame= 1800 fps=240 q=-0.0 Lsize=   4521kB time=00:01:00.00 bitrate= 617.1kbits/s speed=8.00x
video:4379kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 3.2%

Signification : Le pipeline reste sur le GPU (images VAAPI), utilisant scale_vaapi et h264_vaapi. Le « speed » indique le débit réel ; comparez au baseline logiciel.

Décision : Si vous voyez des erreurs concernant hwaccel_output_format ou une rétrogradation vers des filtres logiciels, corrigez la chaîne de filtres pour éviter le téléchargement d’images vers le CPU.

Task 7: Detect accidental CPU fallback by checking CPU burn during a “hardware” run

cr0x@server:~$ pidstat -u -p $(pgrep -n ffmpeg) 1 3
Linux 6.6.0 (server)  01/10/2026  _x86_64_  (32 CPU)

09:22:11      UID       PID    %usr %system  %guest   %CPU  CPU  Command
09:22:12     1000     21877    12.00    3.00    0.00  15.00    8  ffmpeg
09:22:13     1000     21877    11.00    3.00    0.00  14.00    9  ffmpeg
09:22:14     1000     21877    13.00    2.00    0.00  15.00    7  ffmpeg

Signification : L’utilisation CPU est plutôt faible ; probablement le matériel est engagé. Pour un transcodage purement GPU, le CPU doit être surtout occupé au demux/mux et à l’orchestration.

Décision : Si le CPU reste à 300–800% pour un processus FFmpeg, vous faites presque certainement un décodage/encodage logiciel ou des filtres côté CPU.

Task 8: Check kernel logs for amdgpu VCN issues

cr0x@server:~$ sudo dmesg -T | egrep -i 'amdgpu|vcn|ring|firmware' | tail -n 20
[Fri Jan 10 09:10:18 2026] amdgpu 0000:0a:00.0: amdgpu: SMU is initialized successfully!
[Fri Jan 10 09:10:19 2026] amdgpu 0000:0a:00.0: amdgpu: VCN decode and encode initialized
[Fri Jan 10 09:27:43 2026] amdgpu 0000:0a:00.0: amdgpu: ring vcn_dec timeout, signaled seq=2419, emitted seq=2421
[Fri Jan 10 09:27:44 2026] amdgpu 0000:0a:00.0: amdgpu: GPU reset begin!
[Fri Jan 10 09:27:48 2026] amdgpu 0000:0a:00.0: amdgpu: GPU reset succeeded, trying to resume

Signification : L’anneau de décodage VCN a timeouté et a déclenché un reset GPU. Ce n’est pas un « problème de flags FFmpeg » ; c’est de la stabilité/pilote/firmware/thermique.

Décision : Réduisez la concurrence, vérifiez les thermiques/la puissance, validez les paquets firmware, et envisagez des changements de kernel/Mesa. Isolez aussi le GPU s’il accueille d’autres charges.

Task 9: Observe GPU engines with radeontop

cr0x@server:~$ radeontop -d - -l 1 | head -n 8
Dumping to -
gpu 7.12%, ee 0.00%, vgt 0.00%, ta 0.00%, sx 0.00%, sh 0.00%, spi 0.00%, sc 0.00%
vram 512.00M  3.10%, gtt 245.00M  1.40%
mclk 34.00%, sclk 12.00%
vcn 78.00%, vcn0 78.00%

Signification : Le moteur 3D est quasi au repos, mais VCN est fortement utilisé. C’est le bloc codec qui travaille, et il peut se saturer indépendamment.

Décision : Si VCN est près de 100% et que vous perdez des images, vous êtes limité par le codec : réduisez la résolution/fps, ajustez la concurrence ou répartissez la charge sur plusieurs GPU.

Task 10: Verify actual encoder used in FFmpeg (avoid lying configs)

cr0x@server:~$ ffmpeg -hide_banner -i input-1080p-h264.mp4 -c:v h264_vaapi -f null - 2>&1 | egrep -i 'Stream mapping|h264_vaapi|Using'
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_vaapi))

Signification : FFmpeg mappe explicitement vers h264_vaapi.

Décision : En automatisation, enregistrez cette ligne. Si vous voyez un jour libx264 ou h264 (native) en sortie, alertez car vous payez la taxe CPU.

Task 11: Detect format conversions that force software paths

cr0x@server:~$ ffmpeg -hide_banner -loglevel verbose \
  -vaapi_device /dev/dri/renderD128 \
  -hwaccel vaapi -hwaccel_output_format vaapi \
  -i input-1080p-h264.mp4 \
  -vf 'format=yuv420p,scale=1280:720' \
  -c:v h264_vaapi -f null - 2>&1 | egrep -i 'hwdownload|auto_scale|format|vaapi'
[Parsed_format_0 @ 0x55c9c2b7b340] auto-inserting filter 'auto_scale_0' between the filter 'Parsed_null_0' and the filter 'Parsed_format_0'
[Parsed_format_0 @ 0x55c9c2b340] auto-inserting filter 'auto_scale_1' between the filter 'Parsed_format_0' and the filter 'Parsed_scale_1'

Signification : Vous forcez des filtres logiciels (format, scale CPU) qui déclenchent souvent des téléchargements et conversions. Les logs indiquent des mises à l’échelle auto-insertées.

Décision : Remplacez par des équivalents GPU-friendly comme scale_vaapi et conservez un format de pixel VAAPI (souvent nv12).

Task 12: Measure disk throughput during transcode (rule out I/O)

cr0x@server:~$ iostat -dx 1 2
Linux 6.6.0 (server)  01/10/2026  _x86_64_  (32 CPU)

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1         12.00   5896.00     0.00   0.00    0.40   491.33    9.00   3120.00    0.55   0.01   1.20

Signification : Le disque est à l’inactivité ; ce n’est pas votre goulot.

Décision : Si vous voyez un await élevé et un %util élevé, arrêtez d’accuser VCN et corrigez d’abord le stockage/la mise en cache.

Task 13: Check network errors and throughput for live ingest/egress

cr0x@server:~$ ip -s link show dev eth0 | sed -n '1,12p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      987654321  123456      0       2       0       0
    TX:  bytes packets errors dropped carrier collsns
      876543210  112233      0       0       0       0

Signification : Quelques drops RX, pas d’erreurs. Ce n’est pas une preuve évidente, mais les drops peuvent compter en temps réel.

Décision : Si les erreurs/drops augmentent pendant les incidents, étudiez les files NIC, MTU, congestion et shaping avant de retoucher les encoders.

Task 14: Confirm container has the right devices mapped

cr0x@server:~$ docker exec transcoder ls -l /dev/dri
total 0
crw-rw---- 1 root video  226,   0 Jan 10 09:10 card0
crw-rw---- 1 root render 226, 128 Jan 10 09:10 renderD128

Signification : Le conteneur voit le nœud render.

Décision : Si ce n’est pas le cas, corrigez --device=/dev/dri ou les réglages du device plugin Kubernetes. N’essayez pas d’« installer Mesa » dans le conteneur et d’espérer que tout aille bien.

Task 15: Check for ffmpeg encoder availability for VAAPI/AMF

cr0x@server:~$ ffmpeg -hide_banner -encoders | egrep -i 'vaapi|amf' | head -n 20
 V....D h264_vaapi            H.264/AVC (VAAPI) (codec h264)
 V....D hevc_vaapi            H.265/HEVC (VAAPI) (codec hevc)

Signification : Les encodeurs VAAPI sont présents. Si AMF est présent sur votre build, vous verriez h264_amf, hevc_amf, etc.

Décision : Choisissez l’API que vous pouvez supporter opérationnellement. Sur Linux, VA-API via Mesa est souvent le choix le moins surprenant ; AMF peut être viable selon l’environnement et le packaging.

Task 16: Validate that your output is what you think it is

cr0x@server:~$ ffprobe -hide_banner -select_streams v:0 -show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate -of default=nw=1 /tmp/out-vaapi.mp4
codec_name=h264
profile=High
pix_fmt=yuv420p
width=1280
height=720
avg_frame_rate=30/1

Signification : Le codec et le format de sortie semblent cohérents pour une compatibilité large.

Décision : Si vous produisez par erreur un format que les clients ne peuvent pas décoder (ou un niveau/profile qu’ils détestent), vous aurez des « saccades de lecture » qui sont en réalité des échecs de décodage client.

Trois mini-récits d’entreprise du terrain

Mini-récit n°1 : L’incident causé par une mauvaise hypothèse

Ils migraient un service de clipping live d’une flotte CPU-heavy vers des nœuds GPU. L’argument était simple : « l’encodage matériel réduira les coûts ». Les tests de staging étaient verts : un flux entrant, un flux sortant, des graphiques propres, tout le monde content.

Le trafic de production est arrivé comme toujours : inégal, en pics, et plein de cas limites. Après la première vague de déploiement, la latence a augmenté. Puis la page d’incident s’est allumée : les clips prenaient trop de temps, les aperçus étaient retardés, et les opérateurs ont commencé à limiter manuellement le débit client.

L’hypothèse était subtile : ils traitaient la « capacité GPU » comme si elle se scaleait comme des cœurs CPU. Ajouter des jobs rend les choses plus lentes, mais de manière lisse. VCN n’était pas « lisse ». Il atteignait un plafond de concurrence puis la mise en file explosait. L’utilisation 3D restait basse, alors l’on-call a chassé des goulots fantômes dans le scheduler et le stockage.

La correction n’était pas exotique. Ils ont ajouté du monitoring au niveau du moteur (utilisation VCN et profondeur de la file d’encodage), imposé des limites de sessions par nœud, et modifié le dispatcher pour répartir les jobs sur plusieurs GPU au lieu de les empiler. Le meilleur : ils n’ont pas eu besoin de nouveau hardware. Ils avaient juste besoin du bon modèle mental.

Mini-récit n°2 : L’optimisation qui s’est retournée contre eux

Une autre équipe voulait une meilleure qualité visuelle pour des flux 720p à bas débit. Ils ont activé des réglages de contrôle de débit plus coûteux et un comportement de type lookahead dans leurs paramètres d’encodage. L’objectif était noble : moins d’artefacts en mouvement.

Sur le papier, l’encodeur matériel le supportait. En isolation, oui. En réalité, ce « petit » changement a déplacé la courbe de débit suffisamment pour que les charges en pointe poussent les nœuds en saturation. Les utilisateurs ont vu des pertes d’images et du drift audio/vidéo, et le résumé des tickets de support était : « le réseau est mauvais ».

L’ingénierie a réagi de façon prévisible : plus de retries, plus de buffering, plus de timeouts. Cela a aggravé la latence. Ça a aussi caché le signal : les encodeurs étaient le goulot, pas le WAN.

Ils ont rollbacké les réglages et adopté une approche consciente du contenu : garder l’encodage matériel rapide pour la couche temps réel, et réserver les encodages CPU (ou des profils plus lents) pour le VOD où la latence importe moins. La leçon : « la qualité » est un budget, et le bloc codec est la banque qui l’applique.

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une plateforme média avait l’habitude, jugée ennuyeuse lors des revues de sprint : ils maintenaient une petite suite de tests synthétiques de transcodage attachée à chaque mise à jour du kernel et de Mesa. Même entrées. Même sorties. Même banc de mesure. Ils l’exécutaient sur un nœud canari par modèle GPU et stockaient les résultats.

Un jour, un déploiement OS routinier a introduit une régression : le décodage matériel continuait de fonctionner, mais l’encodage tombait occasionnellement en fallback logiciel à cause d’une incompatibilité subtle userspace. Personne n’a tout de suite remarqué car le service ne plantait pas. Il devenait juste plus lent.

Le canari l’a détecté en quelques heures. Les graphes montraient un doublement du CPU par transcode pendant que l’utilisation VCN chutait. L’on-call n’a pas eu besoin d’une war room ; ils ont eu besoin d’un rollback. Ils ont mis en pause le rollout, épinglé les versions connues bonnes et remonté le bug en amont avec des étapes de reproduction.

C’est à ça que ressemble l’ingénierie de fiabilité la plupart du temps : pas des exploits, juste un refus de déployer à l’aveugle.

Erreurs communes (symptômes → cause → correction)

1) Symptôme : pics CPU pendant un « transcodage GPU »

Cause : Rétrogradation logicielle (encodeur non disponible, permissions device incorrectes, support VA-API/AMF manquant) ou filtres côté CPU forçant des téléchargements d’images.

Correction : Validez le mapping d’encodeur dans les logs FFmpeg ; utilisez des filtres natifs GPU (scale_vaapi), maintenez les surfaces en matériel, et assurez-vous que /dev/dri/renderD* est accessible.

2) Symptôme : l’utilisation GPU semble faible, mais le débit est mauvais

Cause : Vous regardez le mauvais moteur. VCN est saturé alors que le 3D est au repos.

Correction : Surveillez explicitement VCN (radeontop, sysfs/télémétrie si disponible). Planifiez la capacité sur le débit VCN, pas sur le « % GPU ».

3) Symptôme : saccade aléatoire toutes les quelques minutes sous charge

Cause : Mise en file dans le bloc codec, incidents d’ordonnancement du pilote, ou throttling thermique/alimentation causant des stalls périodiques.

Correction : Réduisez la concurrence par GPU, assurez un refroidissement adéquat, verrouillez les profils d’alimentation et corrélez les stalls avec les logs kernel et l’utilisation VCN.

4) Symptôme : « Ça marchait en staging » mais échoue en production

Cause : Le staging n’exécutait qu’un flux. La production exécute de nombreux flux concurrents, des codecs mixtes et des résolutions variées. Certains contenus déclenchent des chemins différents (10-bit, B-frames, contraintes de niveau étranges).

Correction : Testez avec de la concurrence et du média représentatif. Créez un jeu de torture d’entrées et exécutez-le sur chaque modèle GPU que vous déployez.

5) Symptôme : l’encodage matériel fonctionne sur l’hôte, pas dans le conteneur

Cause : Mapping de périphérique manquant, permissions de groupe manquantes, ou conteneur sans les libs userspace correspondantes.

Correction : Mappez /dev/dri, incluez le groupe render, et alignez les versions Mesa/libva avec l’hôte. Préférez des conteneurs légers utilisant les pilotes stables de l’hôte.

6) Symptôme : l’encodage HEVC est absent bien que « le GPU le supporte »

Cause : La génération GPU ou le firmware le supporte, mais votre pile pilote n’expose pas l’entrypoint ; ou le build OS utilise un driver VA limité.

Correction : Validez avec vainfo. Si VAEntrypointEncSlice pour HEVC est absent, cessez de supposer. Mettez à jour Mesa/libva ou changez d’approche.

7) Symptôme : la qualité vidéo semble pire que l’encodage CPU au même bitrate

Cause : Comportement de contrôle de débit différent ; les presets matériels peuvent être optimisés pour le débit plutôt que pour l’efficacité de compression.

Correction : Ajustez l’échelle de bitrate, utilisez des réglages plus conservateurs de mouvement/qualité quand possible, ou réservez l’encodage CPU pour les paliers archivage/VOD.

8) Symptôme : les resets GPU font tomber des charges non liées

Cause : GPU partagé : un hang VCN déclenche un reset GPU complet affectant d’autres contextes.

Correction : Isolez le transcodage sur des GPU ou hôtes dédiés. Si vous devez partager, imposez des limites de sessions conservatrices et utilisez des canaris pour les mises à jour pilotes.

Listes de contrôle / plan étape par étape

Checklist A : Avant d’acheter du matériel (ou de signer un engagement cloud)

1. Listez vos codecs et profils requis : H.264, HEVC, AV1 ; 8-bit vs 10-bit ; besoins de décodage vs encodage.
2. Décidez de votre stratégie d’API par OS : VA-API, AMF, ou spécifique à l’application (OBS, GStreamer, Jellyfin, etc.).
3. Choisissez une charge représentative : résolution, fps, filtres et échelle de bitrate cible.
4. Mesurez la concurrence : 1 flux, puis N flux jusqu’à ce que la latence ou les pertes apparaissent.
5. Validez la compatibilité client : profils/niveaux/formats de pixels que vos clients décodent réellement.

Checklist B : Pour une nouvelle image de nœud (AMI golden, image PXE, etc.)

1. Épinglez une combinaison kernel + Mesa/libva connue pour votre génération GPU.
2. Installez FFmpeg avec le support d’accélération approprié (vérifiez ffmpeg -hwaccels et ffmpeg -encoders).
3. Validez les nœuds device et les permissions (/dev/dri/renderD*, groupes).
4. Exécutez un transcode smoke qui force les filtres et encodeurs GPU.
5. Collectez des métriques de base : CPU par transcode, utilisation VCN, fps d’encodage, taux d’erreur.

Checklist C : Pour le déploiement en production

1. Canarisez un hôte par modèle GPU.
2. Alertez sur les indicateurs de fallback logiciel : mismatch de nom d’encodeur, pic CPU par job, chute inattendue de l’utilisation VCN.
3. Limitez la concurrence par GPU de manière conservative ; augmentez uniquement avec des preuves.
4. Enregistrez les logs kernel pendant les fenêtres d’incident ; les resets VCN sont de l’or diagnostique.
5. Gardez un plan de rollback pour les pilotes et bibliothèques userspace.

Checklist D : Pour les services live (sensibles à la latence)

1. Priorisez un pacing de trame stable plutôt que la compression maximale.
2. Évitez les allers-retours CPU↔GPU ; maintenez le pipeline sur GPU autant que possible.
3. Utilisez des files bornées et des politiques de drop que vous pouvez expliquer aux clients.
4. Mesurez bout-à-bout : capture → encode → paquetisation → envoi → décodage.

Une citation fiabilité (idée paraphrasée) : John Allspaw a souligné que les incidents viennent des interactions normales du travail de tous les jours, pas d’un seul « mauvais acteur ».

FAQ

1) VCN est-ce la même chose que « encodage GPU » ?

Non. VCN est un bloc vidéo à fonction fixe. « Encodage GPU » peut aussi signifier l’encodage basé sur shaders/compute, qui est une bête différente avec des performances et des caractéristiques de contention différentes.

2) Si mon GPU est puissant pour les jeux, cela garantit-il un bon transcodage ?

Non. Les performances gaming suivent le débit shader et la bande passante mémoire. La capacité de transcodage dépend de la génération du bloc codec, des codecs supportés et de la maturité des pilotes.

3) Pourquoi « l’utilisation GPU » reste faible alors que le système perd des images ?

Parce que VCN peut être saturé alors que les moteurs 3D sont au repos. Beaucoup de tableaux de bord n’affichent qu’un seul chiffre d’utilisation. Pour la vidéo, ce chiffre est souvent hors sujet.

4) Dois-je utiliser VA-API ou AMF sur Linux ?

Utilisez ce que votre application supporte bien et ce que vous pouvez exploiter de manière fiable. Dans de nombreux déploiements Linux, VA-API via Mesa est le plus prévisible. AMF peut être viable mais dépend du packaging et de l’intégration applicative.

5) Quelle est la façon la plus rapide de prouver que l’encodage matériel est actif ?

Exécutez une commande FFmpeg qui force h264_vaapi/hevc_vaapi et une mise à l’échelle côté GPU, puis confirmez le mapping dans les logs et observez une faible utilisation CPU plus une activité VCN.

6) Pourquoi certaines vidéos échouent en encodage/décodage matériel même si c’est le même codec ?

Les profils et formats comptent : 10-bit, niveaux inhabituels, contenu entrelacé ou échantillonnage de chroma étrange peuvent déclencher des chemins non supportés et des rétrogradations. « H.264 » n’est pas une seule chose.

7) Puis-je exécuter plusieurs transcodages par GPU en toute sécurité ?

Oui, mais vous devez mesurer et fixer un plafond de concurrence. Le mode de défaillance de « trop de » est souvent des pics de latence et l’effondrement des files plutôt qu’une erreur nette.

8) Pourquoi l’ajout de réglages « qualité » nuit parfois à la stabilité temps réel ?

Parce que certains réglages échangent le débit contre l’efficacité. Vous pouvez rester en « encodage matériel », mais demander plus de travail par image et le matériel finira par dire non—en prenant du retard.

9) Dois-je me préoccuper du décodage si mon service n’encode que ?

Généralement oui, car beaucoup de pipelines décodent avant d’encoder, et le décodage peut être le goulot ou déclencher une rétrogradation logicielle. De plus, le décodage matériel garde les images sur le GPU pour un pipeline plus propre.

10) Sur quoi dois-je alerter en production ?

Alertez sur : changements de sélection d’encodeur (matériel → logiciel), déviations CPU par job, saturation d’utilisation VCN, images perdues, latence d’encodage, et événements kernel-level de reset GPU.

Prochaines étapes pratiques

1. Inventoriez vos besoins réels en codecs (y compris profils/profondeur de bits), puis validez-les avec vainfo sur l’image OS exacte que vous comptez livrer.
2. Construisez une commande FFmpeg « known-good » qui garde les images sur le GPU de bout en bout. Utilisez-la comme test canari et outil de repro d’incident.
3. Instrumentez le bloc codec : suivez l’utilisation VCN, les fps d’encodage, le CPU par job et les resets kernel. Si vous ne pouvez pas tracer VCN, vous opérez à l’aveugle.
4. Fixez et appliquez des plafonds de concurrence par GPU. Mesurez où la latence casse, puis opérez en production à 60–80% de ce seuil. Laissez de la marge ; votre trafic ne sera pas poli.
5. Cessez de faire confiance aux dashboards « utilisation GPU » qui ne ventilent pas par moteur. Les pipelines vidéo vivent ou meurent selon des parties du GPU que la plupart des gens ignorent.

VCN/VCE n’est pas juste une case à cocher. C’est un primitive de planification de capacité, un levier de latence et une frontière de risque de fiabilité. Traitez-le comme une infrastructure de production, pas un argument marketing, et il vous rapportera des nuits d’astreinte plus calmes.