AV1 : le codec qui compte même si vous ne diffusez jamais

octobre 19, 2025 • février 3, 2026 • Lecture : 29 min • Views: 0

Cet article vous a aidé ?

Votre facture réseau augmente, votre stockage d’objets grossit comme s’il avait des sentiments, et vos CPU brûlent des cycles sur des travaux médias « en arrière-plan »
que personne ne se rappelle avoir approuvés. Pendant ce temps, le produit demande pourquoi un clip de 20 secondes met trois minutes à « traiter », et pourquoi la lecture va bien sur le bureau mais
saccade sur un téléphone tout neuf.

C’est un problème de codec — que vous exploitiez ou non une plateforme de streaming. AV1 n’est pas seulement une manière plus agréable de regarder des vidéos ; c’est un levier qui change
les coûts d’egress, l’empreinte de stockage, l’architecture de la chaîne de traitement et les schémas d’incidents. Si vous gérez des systèmes de production, AV1 vous touchera. Probablement pendant une période de gel des déploiements.

Pourquoi AV1 compte en dehors du streaming

La plupart des organisations ne « streament » pas. Elles « ont de la vidéo ». Le support reçoit des envois d’enregistrements d’écran. Le marketing publie des démonstrations produit. Les RH diffusent des formations.
La sécurité stocke les vidéos de caméra. DevRel poste des webinaires. Les ventes envoient des clips personnalisés. Et chaque outil interne qui accepte du contenu généré par les utilisateurs
devient une plateforme vidéo dès que quelqu’un réalise que les zones de texte sont optionnelles.

Les codecs décident discrètement de la forme de ce bazar :

Croissance du stockage objet : la vidéo domine les octets. Un écart de taille de 20–40 % fait la différence entre « facture banale » et « pourquoi ce bucket coûte un prêt immobilier ? »
Coûts d’egress et factures CDN : même les applications « non-streaming » livrent des médias aux navigateurs, aux clients mobiles et aux API partenaires.
Budgets compute : temps d’encodage, extraction de miniatures, passes QA et transcodages « au cas où » pèsent sur CPU/GPU comme un loyer impayé.
Latence et expérience utilisateur : le choix du codec change le temps de démarrage, les rebufferings et la consommation batterie — et votre file de support change avec.
Sécurité et conformité : les pipelines de transcodage créent de nouvelles copies de données, de nouveaux scénarios de rétention et de nouveaux points de défaillance (surtout en environnements régulés).

Le slogan d’AV1 est « meilleure compression ». Le titre opérationnel est : AV1 déplace les coûts depuis la bande passante/le stockage vers la gestion du compute et de la compatibilité.
Si vous planifiez ce déplacement, vous gagnez. Si vous y arrivez par hasard, vous aurez un rapport d’incident où le mot « codec » apparaîtra pour la première fois.

Faits intéressants et contexte historique

Un codec, c’est de la technologie, de la politique et de l’économie déguisées. L’histoire d’AV1 importe car elle explique pourquoi il existe et pourquoi son déploiement est étrangement inégal.

AV1 a été créé par l’Alliance for Open Media (AOMedia), un consortium formé en 2015 pour promouvoir un écosystème de codecs sans redevance.
Les racines d’AV1 incluent VP9 de Google et des éléments d’autres codecs de recherche ; ce n’était pas une invention ex nihilo mais plutôt une fusion stratégique.
Les bitstreams AV1 ont été finalisés en 2018, mais le décodage matériel à grande échelle a pris des années — le logiciel peut être livré rapidement ; le silicium suit un calendrier.
Netflix et YouTube ont été des moteurs précoces d’AV1 car ils ressentent les gains de compression en argent réel : moins de données transférées, moins de cache misses, moins de liens d’accès final congestionnés.
AV1 s’utilise aussi pour la communication en temps réel (par ex. WebRTC), où l’efficacité du débit rivalise avec la latence et le CPU.
AVIF (AV1 Image File Format) utilise le codage intra d’AV1 pour les images, donc « l’adoption d’AV1 » s’infiltre souvent via les pipelines d’images en premier.
Le décodage matériel s’est accéléré avec les GPU et SoC mobiles récents ; la longue traîne des appareils plus anciens dicte encore les stratégies de repli.
HEVC (H.265) et VVC (H.266) offrent aussi une forte compression, mais la complexité des licences et l’incertitude ont façonné le narratif « AV1 par défaut pour l’avenir ».
La vitesse d’encodage s’est fortement améliorée avec des encodeurs comme SVT-AV1 et rav1e ; les critiques initiales « AV1 est inutilisable lent » ont mal vieilli, mais sans uniformité.

Ce qu’est AV1 (et ce que ce n’est pas)

AV1 en une phrase

AV1 est un codec vidéo moderne conçu pour réduire le débit nécessaire pour une qualité donnée, surtout aux débits faibles à moyens, avec une poussée forte vers une adoption sans redevance.

Ce qui intéresse les ingénieurs

Efficacité du débit : vous pouvez souvent délivrer une qualité subjective similaire avec un débit inférieur par rapport à AVC (H.264), parfois face à HEVC selon le contenu et les réglages.
Espace CPU/GPU : le décodage AV1 en logiciel peut être coûteux ; l’encodage AV1 peut être très coûteux à moins de choisir des presets raisonnables ou une accélération matérielle.
Compatibilité : « joue partout » reste majoritairement H.264, surtout pour le matériel ancien et les plateformes embarquées.
Conteneurs : AV1 circule couramment dans MP4 (ISO BMFF) ou Matroska/WebM. Vous rencontrerez tous ces formats en production.

Ce qu’AV1 n’est pas

Ce n’est pas un coupon magique pour la bande passante : les économies varient selon le contenu. Les plans rapprochés d’un intervenant compressent différemment des confettis.
Ce n’est pas « gratuit » opérationnellement : si vous activez AV1 sans mesurer le CPU, vous vous inscrivez pour un incident de capacité.
Ce n’est pas un remplacement de l’ingénierie de diffusion : les ladders, le packaging, le caching et le comportement du player restent essentiels.

Paraphrase d’une idée de Werner Vogels (CTO d’Amazon) : « Tout échoue, tout le temps. » Les codecs n’y échappent pas ; ils échouent juste de façons plus créatives.

Où AV1 gagne en production

1) Pression egress et CDN : le tueur de budget discret

Si vous payez pour la sortie de données, l’efficacité du débit devient une ligne budgétaire, pas une métrique théorique. Même une modeste économie par titre se cumule à travers un catalogue,
une base d’utilisateurs et le temps. AV1 aide parce qu’il peut fournir une qualité comparable à des débits plus faibles que H.264, particulièrement là où H.264 commence à ressembler à une aquarelle.

Le gain opérationnel n’est pas que la facture. Un débit plus bas peut réduire les rebufferings sur des réseaux marginaux et atténuer les pics de trafic. Vos graphes réseau sont moins piquants.
Votre ingénieur on-call dort mieux.

2) Empreinte de stockage : moins d’octets, moins de soucis

Stocker moins d’octets n’est pas seulement moins cher ; c’est mécaniquement plus simple. Les objets plus petits se répliquent plus vite. Les backfills se terminent plus tôt. Les transitions de cycle de vie
coûtent moins. Les temps de restauration s’améliorent. Si vous gérez votre propre stockage, des jeux de travail plus petits signifient un meilleur comportement de cache et moins de mystères « pourquoi le cluster est chaud ? ».

3) Meilleure qualité à débits contraints pour la « vidéo d’entreprise »

La vidéo d’entreprise est souvent regardée sur un mauvais Wi‑Fi d’hôtel via VPN pendant qu’on partage un écran et que le chien décide d’aboyer.
L’efficacité d’AV1 à bas débit peut rendre ces conditions moins punitives. Le business appelle ça « expérience employé ».
SRE appelle ça « moins de tickets ».

4) AVIF tire parti de l’écosystème

Même si vous ne déployez jamais de vidéo AV1, AVIF peut apparaître dans votre pipeline d’optimisation d’images car il peut surpasser JPEG/PNG/WebP pour certains contenus.
Cela amène le décodage AV1 dans les navigateurs et appareils, et votre équipe plateforme aura soudainement une opinion sur le support des codecs.

5) Pression de standardisation à long terme

En pratique, l’écosystème converge : les navigateurs modernes supportent AV1, les CDN majeurs le comprennent, et le décodage matériel devient courant sur les appareils récents.
Cela ne veut pas dire « activez-le ». Cela signifie que la question par défaut passe de « pourquoi AV1 ? » à « où ne pas utiliser AV1 ? »

Blague 1 : Si vous pensez que « les décisions de codec » ne sont pas votre boulot, attendez que la vidéo du keynote du CEO mette en tampon. Félicitations, c’est votre boulot maintenant.

Où AV1 pose problème (modes de défaillance réels)

Coût d’encodage : la facture arrive en temps CPU

L’encodage AV1 peut être coûteux. Pas toujours, pas pour toujours, mais suffisamment pour que vous le traitiez comme toute autre charge batch lourde :
mettez-la en file d’attente, plafonnez-la, mesurez-la, et supposez qu’elle sera exploitée par quelqu’un qui télécharge un « clip rapide » en 4K 60fps.

La décision opérationnelle clé est où vous dépensez le compute :

Hors ligne / batch : meilleur pour les catalogues, VOD, archives et « traiter une fois, servir plusieurs fois ».
Just-in-time : tentant, mais dangereux. Vous ferez fondre votre flotte au pire moment possible.
Assistance matérielle : excellente quand disponible, mais introduit ordonnancement et hétérogénéité.

Coût de décodage : batterie et vieux matériels

Le décodage AV1 est largement supporté dans les navigateurs modernes et de nombreux appareils récents, mais « largement » n’est pas « universel », et le décodage logiciel peut être gourmand en énergie.
Le symptôme opérationnel est sournois : pas une panne, mais un taux de churn augmenté, des avis négatifs sur l’application, ou des retours « la vidéo chauffe mon téléphone ».

Packaging et compatibilité : les zones pointues

Livrer AV1 implique souvent une ladder : AV1 pour les clients capables, H.264 (et parfois HEVC) en fallback. Cela signifie plus de renditions, plus de manifests,
et plus d’endroits où une mauvaise configuration peut créer une défaillance de lecture. Le bug le plus courant n’est pas le codec lui-même ; c’est la logique de négociation.

Maturité des outils variable selon la voie

FFmpeg est solide. Mais tous les « produits de workflow médias d’entreprise » ne gèrent pas AV1 aussi proprement que H.264.
Vous trouverez des coins où les métadonnées se perdent, les espaces colorimétriques sont mal traités, ou la chaîne suppose « vidéo = AVC ».

Blague 2 : Rien ne vous fait apprécier H.264 comme un job d’encodage AV1 qui se termine juste après la réunion pour laquelle il était destiné.

Trois mini-récits d’entreprise issus du terrain

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

Une entreprise SaaS de taille moyenne a ajouté des « réponses vidéo » dans les tickets de support client. La fonctionnalité était simple : enregistrer un clip dans le navigateur, le téléverser,
le transcoder et le lire en ligne. L’équipe a choisi AV1 pour économiser du stockage et anticiper l’avenir. L’hypothèse était propre et rassurante :
« Les navigateurs supportent AV1 maintenant, donc la lecture sera OK. »

Le déploiement semblait fluide en tests internes. La plupart des employés utilisaient des portables modernes avec Chrome à jour. Puis la fonctionnalité a rencontré le monde réel :
des clients d’entreprise avec des builds Windows verrouillés, du matériel ancien, et des sessions Citrix déjà allergiques à la vidéo.
La lecture ne tombait pas en échec gracieusement ; elle basculait sur du décodage logiciel et saccadait comme un modem dial-up essayant de siffler.

Les escalades support ont explosé. La fonctionnalité de « réponse vidéo » a été blâmée pour la « lenteur » de toute l’application car elle épinglait le CPU côté client.
Pendant ce temps, les graphes backend restaient normaux. L’ingénieur SRE de garde a appris une leçon classique : on ne peut pas déboguer un incendie CPU client avec des métriques serveur.

La correction n’a pas été héroïque. Ils ont mis en place un vrai test de capacité (pas une estimation par user-agent), livré un fallback H.264, et arrêté la lecture automatique des clips AV1
sur les clients contraints. Le postmortem a eu une ligne actionnable : ne jamais supposer le support de décodage d’après les « statistiques de navigateurs » ; mesurez-le dans votre population.

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

Une plateforme interne de traitement média exécutait des jobs nocturnes pour transcoder des formations enregistrées. Quelqu’un a remarqué que le cluster CPU restait inactif pendant la journée.
L’idée : déplacer le transcodage en « just-in-time » quand un utilisateur clique sur play, pour n’encoder que ce qui est regardé. Moins de compute gaspillé, usage plus « efficace ».
Sur papier, c’était un gain.

En pratique, la première semaine du nouveau trimestre comprenait une intégration massive. Des milliers d’employés ont cliqué sur « play » à peu près en même temps.
Le pipeline JIT a mis en file des encodages AV1 exactement au moment où le système avait besoin de faible latence. Les CPU ont grimpé, les files ont gonflé,
et le player a attendu les encodages. Les utilisateurs ont raffraîchi la page. Cela a généré plus de requêtes. Le classique effet de foule, maintenant en version vidéo.

Pour empirer les choses, les presets d’encodeur avaient été réglés pour la compression, pas pour la vitesse, parce que « ça tournait la nuit de toute façon ».
L’encodage AV1 a consommé tous les cœurs disponibles et en a redemandé. L’autoscaler a répondu comme prévu,
mais la capacité a traîné derrière la demande. Le résultat n’a pas été une panne totale ; c’était une défaillance au ralenti : timeouts, lecture partielle, retours négatifs pendant l’onboarding.

Le rollback a été de pré-encoder le contenu populaire et de garder le JIT seulement pour les cas rares, avec des limites strictes et des presets plus rapides.
La leçon : déplacer du travail sur le chemin de la requête n’est pas une optimisation ; c’est un pari. Si vous voulez prendre ce pari, tarifez-le comme tel :
tests de charge, contrôle d’admission et isolation par file.

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

Une équipe sécurité stockait des images de surveillance et avait occasionnellement besoin de « clips d’incident » pour les enquêtes. Ils migraient des niveaux de stockage et
cherchaient une meilleure compression. AV1 semblait attractif. Le manager engineering a fait la chose la moins excitante possible : insisté sur un petit pilote,
une matrice de compatibilité et une étape de validation stricte après transcodage (durée, tolérance du nombre d’images, présence audio et un test de décodage).

Pendant le pilote, un sous-ensemble de flux de caméras a produit des vidéos avec un comportement bizarre de timestamp. Les fichiers AV1 étaient valides, mais leurs métadonnées de conteneur
déclenchaient un bug de player dans l’outil d’investigation. Sans validation, cela serait arrivé en production sous forme de « clips aléatoires qui ne jouent pas », le pire type de bug :
intermittent, non reproductible, et imputé aux utilisateurs.

Comme la validation était obligatoire, la pipeline a signalé immédiatement les sorties défectueuses et les a mises en quarantaine. L’équipe a conservé l’original H.264 comme fallback
et a joint des artefacts de diagnostic. Quand le fournisseur a demandé des échantillons, ils les avaient. Quand les auditeurs ont demandé des preuves, ils avaient une traçabilité.

La correction finale a été un changement au niveau du conteneur et une mise à jour du player, pas l’abandon d’AV1. La pratique ennuyeuse — valider, quarantaine, garder un fallback —
a transformé un cauchemar potentiel de conformité en un ticket d’ingénierie de routine.

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

Voici les tâches que je lancerais réellement en diagnostiquant ou en déployant AV1 dans une chaîne de production. Chaque tâche inclut une commande, une sortie réaliste, ce que cela signifie,
et la décision que vous en tirez.

Tâche 1 : Identifier rapidement le codec et le conteneur

cr0x@server:~$ ffprobe -hide_banner -i sample.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'sample.mp4':
  Metadata:
    major_brand     : isom
  Duration: 00:00:20.04, start: 0.000000, bitrate: 1850 kb/s
  Stream #0:0(und): Video: av1 (av01 / 0x31307661), yuv420p10le, 1920x1080, 29.97 fps, 1720 kb/s
  Stream #0:1(und): Audio: opus (Opus / 0x7375704F), 48000 Hz, stereo, 96 kb/s

Ce que cela signifie : Il s’agit d’une vidéo AV1 dans un MP4 avec audio Opus. Notez le 10 bits (yuv420p10le).

Décision : Vérifiez que vos cibles de lecture peuvent décoder AV1 et gérer le 10 bits. Sinon, encodez une alternative 8 bits (yuv420p) ou fournissez H.264.

Tâche 2 : Vérifier si le décodage est accéléré matériellement sur Linux

cr0x@server:~$ vainfo
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
vainfo: VA-API version: 1.20 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver 23.4.1
vainfo: Supported profile and entrypoints
      VAProfileAV1Profile0            : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointVLD

Ce que cela signifie : Le GPU supporte le décodage AV1 (VLD) via VA-API.

Décision : Sur cet hôte, la lecture AV1/les étapes de décodage pour transcodage peuvent être déléguées au GPU. Envisagez une planification GPU pour les services intensifs en décodage.

Tâche 3 : Confirmer les capacités NVIDIA (NVDEC/NVENC)

cr0x@server:~$ nvidia-smi --query-gpu=name,driver_version --format=csv
name, driver_version
NVIDIA L4, 550.54.14

Ce que cela signifie : Un GPU NVIDIA est présent ; le modèle importe pour le support d’encodage AV1.

Décision : Si vous envisagez l’encodage matériel AV1, confirmez que NVENC supporte AV1 sur ce SKU avant d’engager de la capacité.

Tâche 4 : Mesurer si un client décode en logiciel (symptôme CPU élevé)

cr0x@server:~$ mpv --hwdec=auto --vo=gpu sample.mp4
 (+) Video --vid=1 (*) (av1 1920x1080 29.970fps)
 (+) Audio --aid=1 (*) (opus 48000Hz stereo)
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p10le
Using hardware decoding (vaapi).

Ce que cela signifie : mpv indique un décodage matériel via VA-API. S’il avait indiqué « Using software decoding », le coût CPU augmenterait fortement.

Décision : Si le décodage logiciel est utilisé sur les machines cibles, fournissez un fallback ou une version AV1 de complexité réduite (8 bits, résolution inférieure) pour ces clients.

Tâche 5 : Encoder AV1 avec SVT-AV1 (baseline vitesse/qualité)

cr0x@server:~$ ffmpeg -y -i input.mp4 -c:v libsvtav1 -preset 8 -crf 34 -g 240 -pix_fmt yuv420p -c:a copy output_av1.mkv
... 
frame=  600 fps= 52 q=34.0 Lsize=    10.8MiB time=00:00:20.01 bitrate=4422.3kbits/s speed=1.74x
video:10.1MiB audio:0.6MiB subtitle:0.0MiB other streams:0.0MiB global headers:0.0MiB muxing overhead: 1.6%

Ce que cela signifie : L’encodage est plus rapide que le temps réel (1.74x) avec un preset modéré. La sortie est MKV, vidéo AV1, audio copié.

Décision : Si la vitesse est sous 1.0x sur du contenu de production, augmentez le numéro de preset (plus rapide) ou baissez les objectifs de complexité. Si le débit est trop élevé, ajustez le CRF ou appliquez un réglage film grain avec précaution.

Tâche 6 : Encoder un fallback H.264 avec compatibilité prévisible

cr0x@server:~$ ffmpeg -y -i input.mp4 -c:v libx264 -preset veryfast -crf 23 -pix_fmt yuv420p -movflags +faststart -c:a aac -b:a 128k output_h264.mp4
...
frame=  600 fps=220 q=-1.0 Lsize=    17.2MiB time=00:00:20.01 bitrate=7040.4kbits/s speed=7.33x

Ce que cela signifie : Le fallback H.264 encode rapidement et joue quasiment partout.

Décision : Gardez ceci comme rendu « plancher » pour la compatibilité, en particulier pour les postes d’entreprise, navigateurs embarqués et appareils mobiles anciens.

Tâche 7 : Comparer la qualité objective (PSNR/SSIM) pour une vérification

cr0x@server:~$ ffmpeg -i input.mp4 -i output_av1.mkv -lavfi "[0:v][1:v]ssim;[0:v][1:v]psnr" -f null -
...
[Parsed_ssim_0 @ 0x55c1c2c8d700] SSIM Y:0.963421 (14.35) U:0.987210 (18.92) V:0.989003 (19.59) All:0.971085 (15.41)
[Parsed_psnr_1 @ 0x55c1c2c8f100] PSNR y:39.12 u:43.88 v:44.01 average:40.24 min:35.66 max:44.90

Ce que cela signifie : Les métriques objectives indiquent que l’encodage AV1 est proche de la source. Pas parfait, mais respectable.

Décision : Utilisez les métriques pour détecter des régressions grossières entre presets, pas pour déclarer la victoire. Si le SSIM s’effondre sur du contenu à mouvement, ajustez preset/CRF ou ajoutez un palier supérieur.

Tâche 8 : Détecter l’intervalle d’images clés et la structure GOP (stabilité du streaming)

cr0x@server:~$ ffprobe -select_streams v:0 -show_frames -show_entries frame=pict_type,key_frame,best_effort_timestamp_time -of csv=p=0 output_av1.mkv | head
1,I,0.000000
0,P,0.033367
0,P,0.066733
0,P,0.100100
0,P,0.133467

Ce que cela signifie : La première image est une keyframe (I). Les suivantes sont des images prédites. Vous pouvez scanner les I-frames pour confirmer l’espacement.

Décision : Si vous ciblez HLS/DASH, gardez l’espacement des keyframes aligné sur la durée des segments (par ex. 2s ou 4s). Le désalignement provoque un segmentage inefficace et une mauvaise recherche.

Tâche 9 : Vérifier l’espace colorimétrique et la profondeur de bits pour éviter « pourquoi c’est délavé ? »

cr0x@server:~$ ffprobe -v error -select_streams v:0 -show_entries stream=pix_fmt,color_space,color_transfer,color_primaries -of default=nw=1 output_av1.mkv
pix_fmt=yuv420p
color_space=bt709
color_transfer=bt709
color_primaries=bt709

Ce que cela signifie : SDR standard BT.709. Si vous voyez bt2020/pq/hlg, vous êtes en territoire HDR.

Décision : Ne convertissez pas silencieusement le HDR en SDR sans tone mapping ; ça rend mal et les utilisateurs blâment « votre player ». Si nécessaire, faites-le explicitement et testez.

Tâche 10 : Inspecter la marque du conteneur/compatibilité (bugs de lecture MP4)

cr0x@server:~$ mp4info output_h264.mp4 | head
Track # 1 Info - Track ID 1 - Time Scale 90000
Media Duration: 20.020 secs
Track Duration: 20.020 secs
Media Info: Language "und" - Type "vide" - Codec "avc1"
Track # 2 Info - Track ID 2 - Time Scale 48000
Media Info: Language "und" - Type "soun" - Codec "mp4a"

Ce que cela signifie : MP4 indique avc1/mp4a, un jumelage sûr.

Décision : Lors de l’envoi d’AV1 dans MP4, validez les players dans votre environnement. Certains stacks restent plus fiables avec AV1 dans WebM/MKV selon les contraintes client.

Tâche 11 : Benchmark du débit d’encode pour dimensionner votre pool de workers

cr0x@server:~$ /usr/bin/time -v ffmpeg -y -i input.mp4 -c:v libsvtav1 -preset 10 -crf 36 -an /tmp/out.mkv
...
	Command being timed: "ffmpeg -y -i input.mp4 -c:v libsvtav1 -preset 10 -crf 36 -an /tmp/out.mkv"
	User time (seconds): 82.13
	System time (seconds): 3.44
	Percent of CPU this job got: 1580%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:05.41
	Maximum resident set size (kbytes): 4128440

Ce que cela signifie : L’encodage AV1 a utilisé ~16 cœurs (1580% CPU) et ~4GB de RAM au pic, finissant en 5.4s pour un court clip.

Décision : Plafonnez la concurrence selon CPU et mémoire. Si vous laissez l’ordonnanceur lancer « autant que possible », vous créerez des voisins bruyants et de la latence tail ailleurs.

Tâche 12 : Détecter quand votre pipeline est lié à l’I/O (pas au codec)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 	01/13/2026 	_x86_64_	(32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          78.12    0.00    5.10    9.40    0.00    7.38

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz aqu-sz  %util
nvme0n1         520.0  68480.0     0.0   0.00    4.10   131.7    310.0  50240.0     0.0   0.00    6.90   162.1   4.20  98.0

Ce que cela signifie : Fort iowait et ~98% d’utilisation NVMe. Votre encodeur peut attendre des lectures/écritures disque.

Décision : Déplacez les intermédiaires vers du stockage local plus rapide, streammez via des pipes, ou réduisez les jobs concurrents. N’« optimisez pas le codec » pendant que votre SSD crie famine.

Tâche 13 : Vérifier que manifests/renditions incluent réellement AV1 comme attendu

cr0x@server:~$ grep -E "CODECS|av01|avc1" -n master.m3u8 | head
12:#EXT-X-STREAM-INF:BANDWIDTH=900000,RESOLUTION=854x480,CODECS="avc1.4d401f,mp4a.40.2"
18:#EXT-X-STREAM-INF:BANDWIDTH=650000,RESOLUTION=854x480,CODECS="av01.0.05M.08,mp4a.40.2"

Ce que cela signifie : Il existe des variantes H.264 et AV1 dans le playlist master.

Décision : Si les lignes AV1 manquent, votre packager ou un stade du pipeline ne les a pas produites. Ne déboguez pas les players avant de confirmer que le packaging est correct.

Tâche 14 : Confirmer que vos nœuds workers ont les bibliothèques AV1 attendues

cr0x@server:~$ ffmpeg -hide_banner -encoders | grep -E "svtav1|libaom-av1|rav1e"
 V....D libaom-av1           libaom AV1 (codec av1)
 V....D librav1e             librav1e AV1 (codec av1)
 V....D libsvtav1            SVT-AV1(Scalable Video Technology for AV1) encoder (codec av1)

Ce que cela signifie : L’hôte peut encoder AV1 avec plusieurs encodeurs.

Décision : Standardisez un encodeur par couche (par ex. SVT-AV1 pour l’usage général) pour éviter la dérive « marche sur un worker » et des sorties incohérentes.

Feuille de route pour diagnostic rapide

Quand « AV1 est lent » ou « AV1 ne joue pas » déclenche le pager, vous n’avez pas le temps pour la philosophie du codec. Vous avez besoin d’une séquence serrée qui trouve rapidement le goulot d’étranglement.

Première étape : Est-ce l’encodage, le décodage ou le packaging ?

Problème d’encodage : files qui montent, CPU worker saturé, durées de job qui s’allongent, utilisateurs qui attendent un « traitement ».
Problème de décodage : CPU client élevé, consommation batterie, images sautées, saccades sur des dispositifs spécifiques.
Problème de packaging/manifest : échec de lecture immédiat, « format non supporté », vidéo noire, audio seul, ou seulement certains clients échouent.

Deuxième étape : Prouvez le codec et le profil dans l’artefact

Lancez ffprobe sur l’artefact effectivement délivré, pas sur la source ou le fichier de staging.
Confirmez la profondeur de bits, la transfert colorimétrique et le conteneur.

Troisième étape : Vérifiez la disponibilité de l’accélération matérielle là où ça compte

Sur les serveurs : présence VA-API/NVDEC, santé des drivers, permissions de conteneur.
Sur les clients : le décodage est-il matériel ou logiciel ? (les images sautées se corrèlent au décodage logiciel.)

Quatrième étape : Décidez si le goulot est CPU, mémoire ou I/O

CPU-bound : fort %user CPU, faible iowait, ralentissement linéaire prévisible avec la concurrence.
Mémoire-bound : RSS qui augmente, swapping, OOM kills de conteneurs, longues pauses GC dans les services adjacents.
I/O-bound : fort iowait, disques saturés, lectures d’objets lentes, retries.

Cinquième étape : Réduisez la portée, puis la complexité

Testez un seul fichier. Un worker. Un preset. Source connue bonne.
Passez le preset en plus rapide, limitez la résolution, forcez le 8-bit SDR, désactivez les filtres non essentiels.
Si ça échoue encore : suspectez l’environnement (drivers, bibliothèques, permissions) plutôt que « AV1 est cassé ».

Erreurs courantes (symptômes → cause → correctif)

1) Symptom : La lecture fonctionne sur votre portable, saccade pour les clients

Cause : Les clients décodent AV1 en logiciel (ou AV1 10 bits) sur du matériel contraint/VDI.

Correctif : Livrez un fallback H.264, évitez la lecture automatique sur clients faibles, et préférez 8 bits pour une compatibilité large sauf si le HDR est requis.

2) Symptom : La file d’encodage grossit sans fin en période de pointe

Cause : Encodage AV1 placé sur le chemin de la requête ou pool de workers sous-dimensionné ; presets optimisés pour la compression pas le débit.

Correctif : Passez en batch, pré-encodez le contenu populaire, imposez un contrôle d’admission, et choisissez des presets plus rapides pour les workflows interactifs.

3) Symptom : « Codec non supporté » seulement sur certains navigateurs/appareils

Cause : Le support AV1 existe mais pas pour ce profil/niveau/profondeur de bits, ou le jumelage conteneur est incompatible.

Correctif : Contraignez les sorties (Profile 0 8-bit pour la compatibilité AV1 la plus large), validez le conteneur/marque, et implémentez une sélection basée sur les capacités.

4) Symptom : Les couleurs paraissent délavées ou trop sombres

Cause : Métadonnées colorimétriques perdues ou mal interprétées ; contenu HDR livré dans une chaîne SDR sans tone mapping.

Correctif : Préservez les tags colorimétriques, appliquez explicitement le tone mapping HDR→SDR, et testez sur des écrans/players représentatifs.

5) Symptom : Les fichiers AV1 sont plus petits, mais le « time to first frame » est pire

Cause : Intervalles GOP/keyframe trop longs, mauvais alignement des segments, ou player qui galère avec la complexité de décodage au démarrage.

Correctif : Alignez les keyframes sur les limites de segment (HLS/DASH), ajustez les rungs de démarrage, et envisagez un débit légèrement supérieur pour le premier segment.

6) Symptom : Les workers se font OOM-kill sous charge

Cause : Usage mémoire de l’encodeur + concurrence dépassent les limites ; grandes images intermédiaires ; filtres (scale, denoise) amplifient la mémoire.

Correctif : Fixez des plafonds de concurrence, augmentez la mémoire quand justifié, réduisez la complexité des filtres, et évitez les fichiers intermédiaires inutiles.

7) Symptom : « C’est lent » mais le CPU n’est pas élevé

Cause : Pipeline I/O-bound : lectures depuis stockage objet, throttling réseau, saturation disque, overhead de petits fichiers.

Correctif : Stagez les entrées localement, batch les téléchargements, utilisez des paramètres multipart plus larges quand applicable, et surveillez iowait/%util.

8) Symptom : Le manifest montre AV1, mais les clients choisissent toujours H.264

Cause : Chaînes CODECS incorrectes, segments init manquants, ou détection de capacité du player rejetant la voie AV1.

Correctif : Validez les manifests, confirmez les chaînes codec, testez avec un player AV1 connu capable, et loggez les décisions de capacité côté client.

Checklists / plan étape par étape

Plan de déploiement étape par étape (ce que je ferais dans une vraie org)

Définir les métriques de succès : réduction d’egress, réduction de stockage, taux de lecture réussi, coût d’encodage par minute, et latence de traitement p95.
Choisir le périmètre AV1 : catalogue VOD seulement ? Uploads utilisateurs ? Enregistrements d’écran ? Appels temps réel ? Ne commencez pas par « tout ».
Sélectionner une voie d’encodeur : SVT-AV1 pour l’encodage CPU général, ou encodage matériel si vous pouvez garantir disponibilité et qualité.
Fixer des contraintes de sortie conservatrices : 8-bit SDR (yuv420p), GOP raisonnable (ex. keyframes 2–4s pour le streaming), et conteneur connu fiable.
Conserver un fallback : H.264 baseline/high, audio AAC, MP4 faststart. Non négociable tant que vous n’avez pas mesuré votre population client.
Construire des portes de validation : contrôles ffprobe, test de décodage, sanity durée/frames, présence audio, et quarantaine en cas d’échec.
Instrumenter : temps d’encodage, profondeur de file, CPU par job, pic mémoire, taille de sortie, et taux d’erreur de lecture par codec.
Déployer par cohortes : utilisateurs internes → petit pourcentage externe → montée progressive. Surveillez les classes d’appareils, pas seulement le taux global.
Préparer les contrôles opérationnels : feature flags, politique codec par client/tenant, limites de débit, et un kill switch qui force H.264.
Documenter le « pourquoi » et le « comment » : pour que l’équipe suivante ne supprime pas « par optimisation » le fallback.

Checklist de politique d’encodage (ennuyeuse, répétable, efficace)

Avons-nous une ladder définie (renditions, débits, résolutions) et l’alignement des keyframes ?
Plafonnons-nous la concurrence d’encodage AV1 par hôte et par cluster ?
Validons-nous les sorties et mettons-nous automatiquement en quarantaine les échecs ?
Logguons-nous les décisions de sélection de codec côté client (vérifications de capacité) ?
Conservons-nous les uploads originaux suffisamment longtemps pour retraiter ?
Avons-nous un chemin de fallback documenté et un kill switch testé ?

Checklist opérationnelle pour une passation on-call

Dashboards : profondeur de file d’encodage, durée de job p95, CPU/mémoire workers, attente I/O, comptage d’erreurs par étape (download/encode/package/upload).
Runbooks : « forcer H.264 », « désactiver l’échelon AV1 », « vider les workers AV1 », « passer les presets en mode rapide ».
Échantillonnage : gardez un petit corpus de vidéos « casse-pieds » (mouvement élevé, capture d’écran, HDR) pour reproduire rapidement les problèmes.

FAQ

1) Si je ne fais jamais de streaming, pourquoi devrais-je m’intéresser à AV1 ?

Parce que vous stockez et livrez quand même de la vidéo. AV1 change la croissance du stockage, l’egress et le compute. Ce sont des préoccupations de production, pas des passe‑temps multimédia.

2) AV1 est-il toujours plus petit que H.264 ?

Souvent, mais pas universellement. Les gains dépendent du type de contenu, des réglages d’encodeur et des cibles de qualité. Mesurez sur votre propre corpus avant de réécrire toute votre chaîne.

3) Dois‑je remplacer H.264 par AV1 partout ?

Non. Utilisez AV1 là où vous avez des vues répétées et où le coût de bande passante compte, et gardez H.264 pour la compatibilité maximale. « Partout » est la façon dont vous vous retrouvez à supporter un musée d’appareils.

4) Quelle est la stratégie de déploiement la plus simple et sûre ?

Ajoutez AV1 comme une rendition additionnelle, pas comme un remplacement. Bloquez-le derrière une détection de capacité et gardez H.264 par défaut jusqu’à ce que les données de lecture prouvent le contraire.

5) Quel encodeur AV1 devrais-je utiliser ?

Pour l’encodage CPU à l’échelle, SVT-AV1 est un choix pratique courant en raison du compromis débit/qualité. libaom peut être excellent mais plus lent selon certains réglages.
Choisissez-en un, standardisez et benchmarquez.

6) Qu’en est‑il de l’encodage AV1 matériel ?

Ça peut être excellent pour le débit et le coût par minute encodée, mais vous devez valider la qualité de sortie, imposer de l’ordonnancement (le GPU est une ressource partagée) et gérer des nœuds hétérogènes.
L’accélération matérielle résout une classe de problèmes et en introduit une autre.

7) AV1 est‑il « sans redevance » et donc sans risque ?

« Sans redevance » est l’intention et une motivation majeure, mais le risque business ne se réduit pas aux licences. Le risque opérationnel — compatibilité, performance, outils — est ce qui vous réveillera la nuit.

8) AV1 aide‑t‑il pour les appels temps réel (WebRTC) ?

Ça peut, surtout à débits contraints, mais le temps réel exige faibles latences et contraintes CPU strictes. Si vous déployez AV1 pour les appels, vous avez besoin d’hypothèses matérielles serrées et d’un réglage fin.

9) Pourquoi certains fichiers AV1 jouent mais la recherche est terrible ?

Le plus souvent l’espacement GOP/keyframe, l’alignement des segments ou des problèmes de packaging. AV1 n’est pas intrinsèquement mauvais pour la recherche ; vos choix d’encodage et de segmentation décident.

10) Quelle est la chose qu’on oublie en adoptant AV1 ?

L’observabilité côté client. Si vous ne pouvez pas voir quel codec a été servi et si le décodage est matériel, vous déboguez à l’aveugle.

Conclusion : que faire ensuite

AV1 compte parce qu’il déplace la pression dans votre système. Moins de bande passante et moins de stockage, c’est de l’argent réel. Plus de compute et de gestion de compatibilité, c’est aussi de l’argent réel — juste facturé autrement.
Les équipes qui gagnent considèrent les codecs comme de l’infrastructure : mesurée, progressive, observable et réversible.

Étapes pratiques suivantes :

Benchmarquez vos 20 types de vidéo principaux (enregistrements d’écran, intervenants, haute-mouvement) avec un preset AV1 et un preset H.264. Enregistrez taille, temps d’encodage et qualité subjective.
Ajoutez AV1 comme rendition optionnelle avec sélection basée sur les capacités et conservez le fallback H.264.
Instrumentez les chemins d’encodage et de lecture pour pouvoir répondre : quel codec a été servi, lequel a été décodé, et le décodage était-il accéléré matériellement ?
Construisez un kill switch qui force le fallback sans redéploiement. Vous l’utiliserez un jour. Ce jour-là sera gênant.