Intel Quick Sync : l’arme vidéo cachée

Ce qu’est réellement Quick Sync (et ce que ce n’est pas)

Quick Sync Video est le bloc matériel média dédié d’Intel présent dans de nombreux processeurs Intel (et certains GPU discrets Intel). Il prend en charge l’encodage/décodage vidéo sans consommer de cycles CPU généraux. Le mot important est dédié. Ce n’est pas « utiliser l’iGPU pour du compute ». C’est utiliser du silicium à fonctions fixes (ou semi-fixes) spécifiquement conçu pour le décodage/encodage H.264/H.265/VP9/AV1 (selon la génération) et le traitement associé.

En termes pratiques SRE : QSV transforme « le transcodage est un job batch lié au CPU » en « le transcodage est un pipeline de type I/O avec des contraintes de périphérique ». Le goulot se déplace. C’est généralement une bonne idée, mais vous devez savoir où il est allé.

Le modèle mental qui ne vous trahira pas

• Décodage : transformer la vidéo compressée en images brutes.
• Filtrage/traitement : mise à l’échelle, conversion de couleur, désentrelacement, tone mapping (parfois sur GPU, parfois non).
• Encodage : images brutes de nouveau en format compressé.

Quick Sync peut accélérer le décodage et l’encodage. Votre pipeline peut néanmoins retomber sur le CPU pour les filtres si vous ne gardez pas explicitement les images sur le chemin GPU. C’est là que « j’ai activé l’accélération matérielle » devient « j’ai activé la moitié seulement ».

Et encore : QSV n’est pas une compression magique. Si vous demandez « qualité transparente à 2 Mbps pour du 4K », le matériel s’exécutera poliment et le résultat ressemblera poliment à une aquarelle. L’accélération matérielle change les coûts et le débit. Elle ne contredit pas la physique.

Faits et contexte historique à utiliser en réunion

Voici des points courts et concrets qui empêchent la salle de débattre en rond.

1. Quick Sync est apparu avec Sandy Bridge (2011), c’est pourquoi des guides homelab anciens mentionnent « Gen6 ». Le concept est ancien ; les capacités évoluent.
2. Le support dépend de la génération : les iGPU récents ajoutent HEVC 10 bits, VP9 et finalement AV1. « Avoir Quick Sync » n’est pas équivalent à « avoir le codec dont vous avez besoin ».
3. Intel utilise deux principaux stacks user-space sur Linux : VA-API (avec le pilote iHD) et la voie Media SDK / oneVPL. QSV de FFmpeg peut s’appuyer sur ces stacks.
4. Sur Linux moderne, iHD (intel-media-driver) est la réponse courante ; i965 (héritage) peut encore apparaître sur d’anciennes distributions et compliquer les choses.
5. Plex et Jellyfin n’« utilisent pas QSV » directement ; ils appellent FFmpeg (ou équivalent) qui appelle le stack pilote. Quand ça casse, ce n’est souvent pas « Plex est cassé », c’est vos permissions/pilotes/périphériques.
6. Le débit Quick Sync n’est pas linéaire avec le numéro de modèle CPU. Un CPU moins cher avec un iGPU moderne peut transcoder mieux qu’un CPU « plus gros » ancien parce que le bloc média a changé.
7. La conversion HDR→SDR est un piège fréquent d’accélération. Le décodage/l’encodage peuvent être matériels, mais le tone mapping peut retomber sur le CPU à moins de construire le pipeline avec soin.
8. Intel Arc et les iGPU récents peuvent encoder en AV1 (selon le modèle). Cela change les stratégies d’archivage et de streaming, mais aussi la compatibilité côté client.

Quand utiliser QSV vs CPU vs NVIDIA/AMD

Si vous gérez des charges vidéo en production, la décision ne devrait pas être « lequel est le plus rapide ». Elle doit être « lequel respecte mon SLA avec des modes de panne prévisibles et des opérations raisonnables ». Voici la version franche.

Utilisez QSV quand

• Vous voulez une forte concurrence de transcodage par watt sur un hôte unique.
• Vous construisez des nœuds sensibles au coût où un GPU discret serait sous-utilisé.
• Vous avez besoin d’une qualité suffisante à des débits pratiques pour le streaming, pas du mastering cinéma.
• Vous préférez une fiabilité intégrée (pas de carte PCIe supplémentaire, moins de ventilateurs, moins de surprises de pilotes lors des mises à jour du kernel — généralement).

Utilisez le CPU (x264/x265) quand

• La qualité par bitrate est cruciale (archives, encodages master VOD, escalades « pourquoi ça a l’air flou ? »).
• Votre pipeline nécessite des filtres exotiques et vous ne voulez pas d’un graphe mixte matériel/logiciel.
• Vous pouvez amortir des temps d’encodage longs et souhaitez de la déterminisme.

Utilisez une accélération GPU discrète quand

• Vous avez besoin de plus de sessions que l’iGPU peut fournir aux réglages ciblés.
• Vous avez des fonctionnalités mieux supportées sur cette plateforme dans votre environnement.
• Vous disposez déjà d’une flotte standardisée (ex. NVIDIA partout), et la standardisation vaut plus que l’efficacité théorique.

Mon biais opérationnel : si vous construisez une machine média ou un petit pool de transcodage et que vous avez déjà des iGPU Intel dans votre chaîne d’approvisionnement, commencez par QSV. C’est le « repas gratuit » qui est vraiment gratuit — jusqu’à ce que vous oubliez de vérifier /dev/dri permissions et passiez votre samedi à dépanner un déjeuner qui a mal tourné.

Qualité, latence, débit : le vrai espace de compromis

Disons-le clairement : QSV est souvent indiscernable des encodages CPU aux débits de streaming typiques — jusqu’au moment où ce n’est plus le cas. Le « jusqu’à ce que » survient dans les scènes sombres, le grain, les mouvements rapides et le contenu avec beaucoup de texture fine (sports, animation avec dégradés, grain de film). Quand quelqu’un se plaint de « banding », c’est votre signal d’examiner les chemins 10 bits, les réglages de l’encodeur et si vous faites des conversions d’espace colorimétrique inutiles.

Comprenez les réglages qui comptent vraiment

• Contrôle de débit : CBR/VBR/ICQ/LA_ICQ (les noms varient). Pour beaucoup de workflows QSV, les modes de type ICQ sont un bon compromis : qualité stable, débit raisonnable.
• Lookahead : améliore la qualité au prix de la latence et parfois des ressources GPU.
• B-frames : meilleure compression, mais peut augmenter la latence et poser des problèmes de compatibilité en faible latence.
• Mode basse consommation : excellent pour l’efficacité ; pas toujours optimal pour la qualité ou le support des fonctionnalités.
• Encodage 10 bits : réduit le banding ; nécessite le support client et un pipeline correct.

La latence n’est pas seulement « la vitesse de l’encodeur »

Un encodeur matériel peut être rapide et pourtant entraîner une latence bout en bout plus élevée si votre graphe de filtres envoie les images GPU → CPU puis de nouveau CPU → GPU. Chaque copie ajoute un surcoût, et à l’échelle ces copies deviennent le goulot. C’est pourquoi vous testez avec les mêmes filtres que vous utilisez en production, pas une démo mignonne « transcoder un fichier ».

Une citation à garder sur un post-it, attribuée à John Ousterhout : La simplicité est une condition préalable à la fiabilité. (idée paraphrasée) Les pipelines QSV deviennent peu fiables quand on veut être trop astucieux.

Pilotes Linux et nœuds de périphérique : où l’accélération meurt

Sur Linux, le succès de QSV dépend généralement de quatre choses :

1. Le kernel détecte l’iGPU et charge i915 (ou la pile graphique Intel la plus récente).
2. L’espace utilisateur possède le bon pilote média (intel-media-driver / iHD) et les bibliothèques de support.
3. Votre processus peut accéder à /dev/dri/renderD* (et parfois card*).
4. Votre application utilise un chemin matériel de bout en bout (décodage → filtre → encodage) sans retomber silencieusement.

Sur les serveurs, les options du BIOS aiment vous saboter. « Headless » ne signifie pas « désactiver l’iGPU ». Vous voulez l’iGPU activé même sans moniteur, et souvent l’option « iGPU multi-monitor » ou similaire pour que le périphérique reste énuméré.

Et pour les conteneurs : mapper /dev/dri est nécessaire, pas suffisant. L’utilisateur dans le conteneur a besoin des permissions, et le stack pilote du host doit être compatible avec les bibliothèques du conteneur. Si vous faites du mix-and-match comme une playlist, vous obtiendrez un remix inattendu.

Blague #1 : L’accélération matérielle, c’est comme un abonnement à la salle de sport — la posséder ne vous rend pas plus rapide ; l’utiliser oui.

Tâches pratiques : commandes, sorties, décisions

Voici des tâches réelles pour l’opérateur. Chacune inclut : commande, sortie représentative, ce que ça signifie et la décision à prendre.

Task 1: Confirm the iGPU exists and the right kernel driver is loaded

cr0x@server:~$ lspci -nnk | sed -n '/VGA compatible controller/,+6p'
00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 770 [8086:4692] (rev 0c)
	Subsystem: ASUSTeK Computer Inc. Device [1043:8882]
	Kernel driver in use: i915
	Kernel modules: i915

Signification : L’iGPU est détecté et utilise i915. Bien.

Décision : Si vous ne voyez pas de carte Intel ou si Kernel driver in use est absent, corrigez les réglages BIOS, les paramètres du kernel ou le choix matériel avant de toucher FFmpeg.

Task 2: Check that /dev/dri exists and which nodes are present

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

Signification : Vous avez un nœud render (renderD128) qui est ce dont la plupart des transcodages ont besoin ; les permissions sont basées sur des groupes (render).

Décision : Assurez-vous que l’utilisateur de service appartient au groupe render (et parfois video). Préférez les nœuds render aux nœuds card pour le compute non-affiché.

Task 3: Verify the service user has device permissions

cr0x@server:~$ id plex
uid=998(plex) gid=998(plex) groups=998(plex),44(video),109(render)

Signification : L’utilisateur plex peut accéder aux périphériques video et render.

Décision : Si render manque, ajoutez-le et redémarrez le service. Ne cobblez pas ça avec chmod 777 sauf si vous aimez les rapports d’incident auto-infligés.

Task 4: Confirm VA-API sees the Intel media driver and profiles

cr0x@server:~$ vainfo --display drm --device /dev/dri/renderD128 | head -n 25
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_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: Intel iHD driver for Intel(R) Gen Graphics - 23.4.3 ()
vainfo: Supported profile and entrypoints
      VAProfileH264Main            : VAEntrypointVLD
      VAProfileH264Main            : VAEntrypointEncSlice
      VAProfileHEVCMain            : VAEntrypointVLD
      VAProfileHEVCMain            : VAEntrypointEncSlice
      VAProfileVP9Profile0         : VAEntrypointVLD

Signification : Le pilote iHD se charge et expose des points d’entrée de décodage (VLD) et d’encodage. C’est votre liste de capacités de base.

Décision : Si i965 se charge de façon inattendue ou si l’ouverture du pilote échoue, vous êtes en territoire de mismatch librairie/pilote. Corrigez cela avant d’accuser QSV.

Task 5: Check FFmpeg sees QSV encoders/decoders

cr0x@server:~$ ffmpeg -hide_banner -encoders | grep -E 'qsv|vaapi' | head
 V..... h264_qsv             H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration)
 V..... hevc_qsv             HEVC (Intel Quick Sync Video acceleration)
 V..... h264_vaapi           H.264/AVC (VAAPI) (codec h264)
 V..... hevc_vaapi           H.265/HEVC (VAAPI) (codec hevc)

Signification : FFmpeg est compilé avec le support QSV et VAAPI.

Décision : Si les encodeurs QSV manquent, votre build FFmpeg n’est pas adapté à votre objectif. Corrigez le packaging/la compilation ; ne continuez pas à tweaker des options qui ne fonctionneront pas.

Task 6: Run a minimal QSV transcode and confirm it’s not silently on CPU

cr0x@server:~$ ffmpeg -hide_banner -y \
  -init_hw_device qsv=hw:/dev/dri/renderD128 -filter_hw_device hw \
  -hwaccel qsv -c:v h264_qsv -i input.mp4 \
  -c:v h264_qsv -global_quality 23 -look_ahead 1 \
  -c:a aac -b:a 160k output.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4':
  Stream #0:0: Video: h264 (High), yuv420p, 1920x1080, 30 fps
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (h264_qsv) -> h264 (h264_qsv))
Press [q] to stop, [?] for help
frame=  900 fps=240 q=-0.0 Lsize=   28000kB time=00:00:30.00 bitrate=7648.0kbits/s speed=8.00x

Signification : Le décodage et l’encodage sont tous deux QSV, et la vitesse suggère une accélération matérielle.

Décision : Si vous voyez h264 (logiciel) au lieu de h264_qsv, vous n’utilisez pas QSV malgré vos intentions. Corrigez la commande, la configuration de l’application ou l’environnement.

Task 7: Spot CPU fallback by watching per-thread CPU use during a “hardware” job

cr0x@server:~$ pidof ffmpeg
24718
cr0x@server:~$ top -H -p 24718 -b -n 1 | head -n 15
top - 09:41:12 up 12 days,  3:18,  1 user,  load average: 0.88, 0.71, 0.62
Threads:  18 total,   0 running,  18 sleeping
%Cpu(s):  8.3 us,  1.2 sy,  0.0 ni, 90.1 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
24718 cr0x      20   0 1522480 212340  60240 S  24.0   1.3   0:03.20 ffmpeg
24731 cr0x      20   0 1522480 212340  60240 S   1.0   1.3   0:00.05 ffmpeg

Signification : L’usage CPU est modeste. Si un transcodage « matériel » mange 600 % CPU, les filtres sont probablement sur le CPU ou il y a eu un fallback total.

Décision : Un CPU élevé implique d’auditer le graphe de filtres et les surfaces matérielles, pas votre échelle de bitrates.

Task 8: Check Intel GPU engine utilization (real confirmation)

cr0x@server:~$ sudo intel_gpu_top -J -s 1000 -o - | head -n 20
{
  "period": 1000,
  "engines": {
    "Render/3D/0": { "busy": 3.21 },
    "Video/0": { "busy": 64.18 },
    "VideoEnhance/0": { "busy": 22.07 },
    "Blitter/0": { "busy": 0.00 }
  }
}

Signification : Le moteur Video est occupé. C’est Quick Sync qui travaille. Une activité VideoEnhance indique souvent de la mise à l’échelle ou du post-traitement.

Décision : Si Video est proche de 0 % pendant un transcodage « matériel », vous n’encodez/décodez pas matériellement. Arrêtez les débats et corrigez le chemin.

Task 9: Validate codec support quickly with vainfo grep

cr0x@server:~$ vainfo --display drm --device /dev/dri/renderD128 | grep -E 'AV1|HEVC|H264' | head -n 12
VAProfileH264Main            : VAEntrypointVLD
VAProfileH264Main            : VAEntrypointEncSlice
VAProfileHEVCMain            : VAEntrypointVLD
VAProfileHEVCMain            : VAEntrypointEncSlice

Signification : Vous avez décodage+encodage H.264/HEVC. Aucun AV1 affiché ici, donc ne promettez pas d’encodage AV1 sur cette machine.

Décision : Alignez votre stratégie client/appareil sur ce que le matériel supporte. Si vous avez besoin d’AV1, choisissez un autre silicium.

Task 10: Catch driver/library mismatch in logs when apps are containerized

cr0x@server:~$ docker logs jellyfin 2>&1 | tail -n 20
[AVHWDeviceContext @ 0x55a2c7c8c700] Failed to initialise VAAPI connection: -1 (unknown libva error).
Device creation failed: -5.
Failed to set value 'vaapi=va:/dev/dri/renderD128' for option 'init_hw_device': Input/output error
Error parsing global options: Input/output error

Signification : Le conteneur peut voir le chemin de périphérique (ou croit le voir) mais l’initialisation VAAPI échoue — souvent pilotes user-space manquants/incorrects dans le conteneur, ou permissions.

Décision : Assurez-vous que l’image conteneur inclut la bonne libva + intel-media-driver, et mappez /dev/dri plus les groupes correctement.

Task 11: Confirm the container actually has /dev/dri and group mapping

cr0x@server:~$ docker exec -it jellyfin bash -lc 'ls -l /dev/dri && id'
total 0
crw-rw---- 1 root render 226, 128 Jan 10 09:20 renderD128
uid=0(root) gid=0(root) groups=0(root)

Signification : Le périphérique est présent ; le conteneur tourne en root, donc les permissions sont probablement pas le problème. Cela renvoie vers des pilotes/libs manquants.

Décision : Installez les paquets intel media driver dans l’image ou passez à une image qui les inclut ; gardez les attentes libva host/conteneur compatibles.

Task 12: Inspect FFmpeg filter graph for accidental CPU downloads/uploads

cr0x@server:~$ ffmpeg -hide_banner -loglevel verbose \
  -init_hw_device qsv=hw:/dev/dri/renderD128 -filter_hw_device hw \
  -hwaccel qsv -c:v hevc_qsv -i hdr10_input.mkv \
  -vf 'scale=1280:720' -c:v h264_qsv -global_quality 24 -an -f null - 2>&1 | grep -E 'hwupload|hwdownload|qsv|format' | head -n 30
[graph 0 input from stream 0:0 @ 0x55b0be5f9f00] w:3840 h:2160 pixfmt:p010le tb:1/1000 fr:24/1 sar:1/1
[Parsed_scale_0 @ 0x55b0be6a8440] w:3840 h:2160 fmt:p010le -> w:1280 h:720 fmt:yuv420p
[Parsed_scale_0 @ 0x55b0be6a8440] using software scaling

Signification : Le filtre de mise à l’échelle est logiciel. Ça peut aller pour un flux, mais c’est souvent le goulet CPU caché dans les pipelines « matériels », surtout avec du 4K HDR.

Décision : Si le CPU devient le goulot, utilisez une mise à l’échelle matérielle compatible (filtres QSV/VAAPI) et conservez les images sur le GPU autant que possible.

Task 13: Verify the iGPU stays awake on a headless server (dmesg sanity)

cr0x@server:~$ dmesg | grep -E 'i915|drm' | tail -n 12
[    2.114321] i915 0000:00:02.0: [drm] VT-d active for gfx access
[    2.118220] i915 0000:00:02.0: [drm] GuC firmware load skipped
[    2.145881] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[    2.146201] i915 0000:00:02.0: [drm] Using Transparent Hugepages

Signification : i915 s’est initialisé proprement. Des erreurs ici (échecs de firmware, GPU bloqué) se corrèlent avec l’instabilité des transcodages.

Décision : Si vous voyez des hangs ou resets GPU répétés, traitez cela comme un périphérique capricieux : versionnage de pilotes, mises à jour du kernel, paquets firmware, et potentiellement matériel différent.

Task 14: Check session saturation signs (when QSV is “working” but capacity is gone)

cr0x@server:~$ sudo intel_gpu_top -s 1000 | head -n 12
intel-gpu-top: Intel Alderlake_s (Gen12)
      IMC reads:  312 MiB/s  IMC writes:  148 MiB/s

      Render/3D     6.12% |      Blitter   0.00% |      Video  96.88% | VideoEnhance  54.22%

      RC6       0.00% |       Power   18.40 W | GPU freq  1550 MHz

Signification : Video est presque à 100 %. Vous êtes au limite du moteur QSV.

Décision : Réduisez la complexité par flux (mettre à l’échelle en amont, baisser le framerate, éviter le tone mapping coûteux), ou ajoutez des nœuds. N’augmentez pas sans cesse les limites CPU ; le CPU n’est plus le goulot.

Task 15: Validate Plex is actually using hardware transcoding

cr0x@server:~$ sudo tail -n 30 "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Logs/Plex Media Server.log" | grep -i -E 'qsv|vaapi|hardware'
Jan 10, 09:48:01.112 [0x7f2b2c0b6700] INFO - [Transcode] Using hardware transcoding: Intel Quick Sync Video
Jan 10, 09:48:01.115 [0x7f2b2c0b6700] INFO - [Transcode] Selected video encoder: h264_qsv

Signification : Plex croit utiliser QSV et a sélectionné un encodeur QSV.

Décision : Considérez cela comme nécessaire mais pas suffisant. Croisez avec intel_gpu_top. Les logs peuvent indiquer « hardware » même si une étape ultérieure retombe.

Task 16: Validate Jellyfin/FFmpeg picks QSV (and not VAAPI accidentally)

cr0x@server:~$ grep -R "h264_qsv\|hevc_qsv\|init_hw_device" -n /var/log/jellyfin/ffmpeg*.log | tail -n 10
/var/log/jellyfin/ffmpeg-transcode-6b4c2.log:12:ffmpeg -init_hw_device qsv=hw:/dev/dri/renderD128 -filter_hw_device hw -c:v h264_qsv -i ...
/var/log/jellyfin/ffmpeg-transcode-6b4c2.log:34:Stream #0:0 -> #0:0 (h264 (h264_qsv) -> h264 (h264_qsv))

Signification : La ligne de commande réelle utilise l’initialisation du device QSV et le codec QSV. C’est une preuve plus solide qu’un toggle UI.

Décision : Si les logs montrent libx264 ou aucune initialisation hardware, corrigez les paramètres d’accélération matérielle Jellyfin et le mapping des périphériques du conteneur.

Feuille de route de diagnostic rapide

Ceci s’adresse à ceux qui ont des plaintes de mise en mémoire tampon et quinze minutes avant la prochaine réunion. L’objectif est d’identifier le goulot, pas d’atteindre l’illumination.

Première étape : prouver si QSV est engagé

1. Vérifiez l’occupation du moteur Video avec intel_gpu_top. Si Video reste proche de 0 % pendant un transcodage, vous n’utilisez pas QSV.
2. Vérifiez la commande FFmpeg effective / les logs de l’application (logs Plex, logs ffmpeg de Jellyfin). Cherchez h264_qsv, hevc_qsv et -init_hw_device qsv=....
3. Confirmez l’accès au périphérique : ls -l /dev/dri et groupes d’utilisateurs. Les problèmes de permissions sont la première cause de « ça marchait hier » après des mises à jour ou changements de conteneur.

Deuxième étape : identifier si vous êtes limité par le GPU ou le CPU

1. Si le moteur Video ~90–100 % et le CPU est modeste : vous êtes QSV-bound. Réduisez la charge par flux ou scalez horizontalement.
2. Si le CPU est élevé tandis que le moteur Video est faible/modéré : vous êtes lié aux filtres sur le CPU (mise à l’échelle, burn-in de sous-titres, tone mapping), ou le pipeline est retombé.
3. Si les deux sont faibles mais que la lecture bufferise : regardez le disque / réseau, pas le transcodage.

Troisième étape : trouver l’étape spécifique qui pose problème

1. Tone mapping HDR ? Supposons que c’est la cause jusqu’à preuve du contraire. Vérifiez si le tone mapping est accéléré GPU dans votre stack.
2. Burn-in de sous-titres ? Les sous-titres image (PGS) forcent souvent le rendu CPU et peuvent anéantir le débit.
3. Mise à l’échelle 4K ? Une mise à l’échelle logicielle de 4K à 1080p est une façon efficace de transformer votre CPU en ventilateur.

Blague #2 : Le transcodage le plus rapide est celui que vous n’avez pas fait — le direct play est l’optimisation qui ne plante jamais.

Trois mini-récits d’entreprise depuis le terrain

1) L’incident causé par une mauvaise hypothèse : « C’est un CPU Intel, donc QSV est disponible. »

Une équipe avec laquelle j’ai travaillé a construit une nouvelle couche d’appliances de streaming pour des vidéos de formation internes. Le choix matériel était « sûr » : CPU Intel modernes, beaucoup de RAM, NVMe rapide. L’hypothèse était que Quick Sync gérerait les transcodages pour les employés distants sur Wi‑Fi douteux.

La semaine de lancement arriva. La surveillance montrait quelque chose d’affreux : CPU à 95 % sur la piscine, latence en hausse et files de transcodage qui se formaient comme à un parc d’attractions. Pourtant le tableau de bord de l’appli clamait « accélération matérielle activée ». L’ingénieur on-call fit ce que nous faisons tous sous pression : redémarrer et regarder plus fort le tableau de bord.

Le vrai problème était douloureusement simple. Il s’agissait de CPU série F — pas d’iGPU. Pas d’iGPU, pas de QSV. Les serveurs faisaient des encodages logiciels parce que c’était tout ce qu’ils pouvaient faire. Personne n’avait vérifié lspci avant de valider le BOM.

La correction n’a pas été héroïque. Ils ont revu la spécification des nœuds pour inclure des pièces compatibles iGPU (ou ajouté des GPU discrets sur certains nœuds), mis à jour les règles d’approvisionnement et ajouté un script de préflight qui échoue si /dev/dri/renderD128 n’est pas présent.

Leçon opérationnelle : « Intel » n’est pas une fonctionnalité. QSV exige du silicium, des pilotes et des permissions. Traitez-le comme toute autre dépendance. Vérifiez-le, ne faites pas de vibe-check.

2) L’optimisation qui a mal tourné : « Forçons tout en HEVC pour économiser la bande passante. »

Une plateforme de communications d’entreprise a voulu réduire la dépense CDN et a décidé de standardiser sur HEVC pour la plupart des transcodages. Sur le papier c’était rationnel : meilleure compression que H.264 à qualité équivalente, et les appareils clients récents étaient « majoritairement compatibles ». Ils ont changé la ladder par défaut en HEVC et ont vu les graphiques de bande passante s’améliorer.

Puis les tickets support sont arrivés. Certains appareils clients sont passés en décodage logiciel, l’autonomie a chuté et des portables bas de gamme ont commencé à perdre des images pendant la lecture. Pire : un sous-ensemble de navigateurs gérés en entreprise ne lisait pas fiablement le format selon la politique et la build OS. Le côté transcodage semblait sain ; l’expérience client ne l’était pas.

Ils ont essayé de « corriger » en augmentant le bitrate. Cela a réduit les artefacts mais a remonté la bande passante. Ils ont essayé de « corriger » en poussant plus de sessions HEVC via QSV à des réglages de qualité supérieurs, ce qui a saturé le moteur vidéo. Maintenant le buffering venait aussi du serveur.

La solution finale fut ennuyeuse mais efficace : garder H.264 comme baseline la plus compatible, utiliser HEVC de façon sélective et investir dans de meilleures décisions de direct play. Ils ont aussi traité le contenu HDR comme un chemin à cas spécial car le tone mapping et la gestion 10 bits avaient des contraintes différentes.

Leçon opérationnelle : les décisions de codec sont des décisions systèmes de bout en bout. Optimiser une ligne budgétaire peut en exploser une autre — généralement le budget support.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : tests de capacité avec un mélange réel de filtres

Une autre organisation gérait un service de traitement média qui générait des proxies pour montage et révision. Ils avaient QSV sur la plupart des nœuds, et ça fonctionnait. Ce qui a permis que ça continue de fonctionner fut une pratique dont personne ne se vantait : chaque release candidate passait un test de capacité incluant sous-titres, mise à l’échelle et exactement les étapes de désentrelacement/tone-map utilisées en production.

Un trimestre, une mise à jour d’image de base a apporté une build FFmpeg différente. Rien ne paraissait incorrect dans les tests unitaires. « ffmpeg -encoders » affichait toujours QSV. Mais le test de capacité a immédiatement détecté une régression : le débit a chuté de 40 % sous la charge « réelle », et le CPU a grimpé. Les logs montraient l’apparition d’une mise à l’échelle logicielle car un chemin de filtre matériel n’était plus disponible dans cette configuration de build.

Parce que le test existait, l’équipe n’a pas débattu des plaintes utilisateurs. Ils ont épinglé l’image, rollbacké, puis corrigé la build pour inclure les composants manquants. L’incident n’a jamais atteint les clients.

Leçon opérationnelle : les tests synthétiques mentent. Les tests réalistes mentent moins. Si vous tenez à la fiabilité, testez le pipeline que vous exécutez réellement, pas celui que vous souhaiteriez exécuter.

Erreurs courantes : symptôme → cause racine → correction

1) « Accélération matérielle activée » mais le CPU est saturé

Symptôme : L’UI indique accélération matérielle ; le CPU atteint 400–1200 % pendant un seul flux.

Cause racine : L’étape de filtre est sur le CPU (mise à l’échelle logicielle, burn-in de sous-titres, tone mapping), ou FFmpeg est retombé à cause d’un profile/level non supporté.

Correction : Inspectez la commande FFmpeg effective / les logs et lancez en verbose pour repérer « using software scaling » ou un fallback codec. Déplacez la mise à l’échelle vers le matériel quand c’est possible ; évitez le burn-in de sous-titres ou pré-rendezlez ; traitez explicitement le tone mapping HDR.

2) QSV fonctionne sur l’hôte mais pas dans Docker

Symptôme : Les tests sur l’hôte réussissent ; les logs du conteneur montrent des erreurs d’initialisation VAAPI/QSV.

Cause racine : Stack user-space absent dans le conteneur ou mismatch de groupes/permissions ; parfois des versions libva incompatibles.

Correction : Mappez /dev/dri dans le conteneur, assurez-vous que l’utilisateur conteneur a accès à render, et installez intel-media-driver + libva dans l’image en conformité avec la distribution ciblée.

3) Échecs de transcodage aléatoires après des mises à jour du kernel

Symptôme : Ça marchait pendant des mois ; après des mises à jour OS, certains jobs échouent ou le GPU reset.

Cause racine : Changement de comportement du driver i915, modifications du firmware, ou libs user-space non alignées ; parfois une mise à jour BIOS change l’énumération iGPU.

Correction : Traitez cela comme une pile de pilotes : épinglez les versions si nécessaire, validez sur un nœud canari, capturez dmesg autour des pannes. Si la stabilité est critique, standardisez les combos kernel+pilote par flotte.

4) « Pourquoi la qualité est pire que x264 CPU ? »

Symptôme : Banding dans les dégradés, blocage dans les scènes sombres, plaintes sur le rendu des mouvements rapides.

Cause racine : Objectif bitrate trop agressif, mauvais mode de contrôle de débit, absence de chemin 10 bits, ou conversions d’espace colorimétrique inutiles.

Correction : Utilisez des modes de type ICQ quand disponibles, envisagez HEVC 10 bits pour les clients compatibles, et évitez le double-scaling ou les transferts CPU↔GPU. Aussi : ne comparez pas un x264 lent et optimisé à des réglages matériels par défaut puis ne soyez pas surpris.

5) Le moteur QSV se sature rapidement : « Ça allait jusqu’à trois utilisateurs. »

Symptôme : Les premiers flux sont rapides ; puis tout le monde bufferise ; intel_gpu_top montre Video ~100 %.

Cause racine : Vous atteignez la limite de débit du moteur matériel, aggravée par du 4K, des framerates élevés ou des traitements coûteux comme le tone mapping.

Correction : Réduisez le travail par flux (générez en amont des versions basse résolution, limitez le framerate, évitez le tone mapping HDR en temps réel), ou scalez horizontalement. N’ajoutez pas de cœurs CPU ; vous n’êtes pas CPU-bound.

6) Le direct play devient mystérieusement transcode

Symptôme : Le même fichier est en direct-play sur un client mais transcodé pour un autre, ou après une petite mise à jour.

Cause racine : Mismatch de conteneur (codec, profile, level), incompatibilité codec audio, format de sous-titres, ou restrictions côté client.

Correction : Inspectez le media info et les capacités du client ; préférez des containers/codecs standards pour votre public. Quand c’est possible, ajustez votre bibliothèque pour éviter des combinaisons pathologiques qui déclenchent des transcodages.

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

Étape par étape : construire un hôte Linux compatible QSV (version opérateur)

1. Choisissez du matériel qui a réellement un iGPU. Vérifiez avant l’achat. Les modèles « F » sont un piège courant.
2. Activez l’iGPU dans le BIOS même pour les serveurs headless. Confirmez son énumération dans lspci.
3. Installez la pile de pilotes média Intel adaptée à votre distro (libva + intel-media-driver/iHD).
4. Confirmez les profils VA-API avec vainfo.
5. Confirmez que FFmpeg a QSV activé (ffmpeg -encoders | grep qsv).
6. Accordez les permissions des périphériques : ajoutez les utilisateurs de service au groupe render (et parfois video).
7. Exécutez un transcodage réel et vérifiez avec intel_gpu_top.
8. Testez la charge avec votre mélange réel de filtres (sous-titres, scale, tone mapping). Capturez métriques CPU/GPU/disque.
9. Codifiez des vérifications de préflight dans le provisioning pour que les nœuds mal configurés ne rejoignent pas la piscine.

Checklist : déploiement conteneur qui ne vous ridiculisera pas

• Mappez /dev/dri dans le conteneur.
• Exécutez le conteneur avec un utilisateur qui a accès à renderD*, ou mappez des groupes supplémentaires.
• Assurez-vous que le conteneur inclut des libva et les paquets Intel media driver compatibles.
• Épinglez l’image et faites passer les mises à jour via un nœud canari avec un test de capacité.
• Logguez les lignes de commande FFmpeg effectives (et conservez-les).

Checklist : tuning de performance sans s’auto-blesser

• Commencez par optimiser le direct play : stratégie codec/container, compatibilité audio, formats de sous-titres.
• Puis assurez-vous que le décodage + encodage matériel sont engagés.
• Ensuite, migrez la mise à l’échelle / le désentrelacement vers des chemins matériels si le CPU est élevé.
• Ce n’est qu’après que vous ajustez les paramètres d’encodeur (mode qualité, lookahead, B-frames).
• Mesurez la concurrence sous des charges réalistes ; ne faites pas d’extrapolation à partir d’un seul fichier.

FAQ

1) Quick Sync, c’est la même chose que « utiliser l’iGPU » ?

Non. Quick Sync est le moteur média. L’iGPU est le dispositif qui le contient. Vous pouvez avoir un iGPU graphique sans utiliser QSV, et vous pouvez retomber sur le CPU malgré la présence de QSV.

2) Comment savoir que je transcode vraiment matériellement ?

Deux preuves valent mieux que tout : (1) Les logs FFmpeg montrent h264_qsv/hevc_qsv à la fois en décodage et en encodage, et (2) intel_gpu_top montre le moteur Video occupé pendant le job.

3) Pourquoi le burn-in de sous-titres détruit-il mon débit ?

Parce que le rendu des sous-titres est souvent une composition d’image côté CPU, surtout pour les formats image (comme PGS). Cela force des downloads/uploads d’images ou un pipeline entièrement CPU.

4) Dois-je utiliser VAAPI ou QSV dans FFmpeg ?

Les deux peuvent fonctionner. QSV est un chemin spécifique optimisé pour Intel. VAAPI est une API plus générique. En production, choisissez-en un par environnement, testez à fond et standardisez — les setups mixtes « ça dépend » sont des incubateurs de tickets.

5) Quick Sync supporte AV1 ?

Ça dépend de la génération. Certains iGPU Intel récents supportent le décodage et/ou l’encodage AV1. Vérifiez avec vainfo et la liste d’encodeurs FFmpeg sur la machine précise que vous déployez.

6) Quel est le limiteur de capacité typique avec QSV ?

Généralement le moteur Video (débit encodage/décodage) ou le chemin « VideoEnhance » si vous faites beaucoup de mise à l’échelle/tone mapping. Parfois la bande passante mémoire devient pertinente sous de nombreuses sessions 4K concurrentes.

7) Pourquoi la transcoding HDR→SDR fait-il si mal ?

Le tone mapping est coûteux en calcul et retombe fréquemment sur le CPU à moins d’avoir un pipeline entièrement accéléré. Il est aussi facile de convertir les formats de pixels d’une manière qui force des filtres logiciels.

8) L’encodage matériel est-il toujours de moins bonne qualité que x264/x265 ?

Pas toujours. Pour le streaming typique, QSV peut être excellent. Mais à bitrate égal, un encodage CPU lent gagne souvent sur du contenu difficile. La bonne question est de savoir si la qualité est acceptable pour votre SLA et vos spectateurs.

9) Puis-je fonctionner headless sans moniteur et utiliser QSV ?

Oui, si le BIOS maintient l’iGPU activé et que l’OS charge le pilote. Le headless est normal pour des serveurs médias ; désactiver l’iGPU est l’erreur, pas l’absence de HDMI.

10) Quelle est la façon la plus rapide de réduire la charge de transcodage sans toucher aux réglages QSV ?

Faites que plus de contenus soient en direct play : privilégiez H.264 + AAC dans un conteneur largement supporté, évitez le burn-in forcé des sous-titres et conservez plusieurs versions pour les résolutions courantes.

Prochaines étapes pratiques

1. Exécutez la boucle de preuve sur un hôte : lspci → vainfo → test FFmpeg QSV → intel_gpu_top. N’allez pas plus loin tant que le moteur Video n’affiche pas de charge réelle.
2. Auditez vos pipelines réels : effectuez-vous des mises à l’échelle, du tone mapping ou du burn-in de sous-titres ? Identifiez quelles étapes sont liées au CPU et décidez si c’est acceptable.
3. Standardisez votre déploiement : épinglez pilotes/libs, codifiez les permissions des périphériques et ajoutez un préflight qui échoue les nœuds sans /dev/dri/renderD*.
4. Testez la capacité avec vos cas difficiles : 4K, HDR, sous-titres et vos cibles clients courantes. Les fichiers faciles ne paient pas votre salaire.
5. Notez vos règles de décision : quand faire du direct play, quand transcoder matériellement, quand refuser (ou pré-générer) le tone mapping HDR. Le vous du futur remerciera le vous du présent.

Quick Sync n’est pas caché parce qu’il est obscur. Il est caché parce qu’on oublie facilement que le matériel le plus rapide de la machine est celui que vous n’avez pas instrumenté. Instrumentez-le, vérifiez-le et laissez le CPU revenir à ses tâches — comme faire semblant de ne pas être chaud.