H.264, HEVC et AV1 : pourquoi le codec décide de ce qui se lit

Tous les quelques années, l’industrie vidéo livre un codec qui produit la même image à environ la moitié du débit du précédent, et le fait payer en complexité de décodage. Pour la télévision en direct, cet échange a une conséquence précise : votre fournisseur économise de la bande passante, et vous découvrez si votre matériel arrive à suivre.

Les trois générations#

H.264, normalisé en 2003, est l’universel. Tout appareil fabriqué ce siècle le décode en matériel. C’est aussi le moins efficace des trois, donc une chaîne H.264 à une qualité donnée consomme le plus de bande passante.

HEVC, normalisé en 2013, est le choix par défaut actuel pour tout ce qui est en haute résolution. Environ la moitié du débit de H.264 pour une qualité comparable. La prise en charge matérielle est large sur tout ce qui date de la dernière décennie, et c’est ce que la plupart des chaînes IPTV 4K utilisent.

AV1, publié par l’Alliance for Open Media en 2018, est le plus récent, avec l’histoire de licences qui l’a rendu attractif pour les grands distributeurs. Encore environ la moitié de HEVC. Le décodage matériel est courant sur les GPU récents et absent de tout ce qui est plus ancien.

codec    standardised   relative bitrate   hardware decode
H.264    2003           baseline           universal
HEVC     2013           about half         broad, last 10 years
AV1      2018           about half again   recent GPUs only

Le schéma se répète à chaque fois : meilleure compression, plus de travail de décodage, prise en charge matérielle plus étroite jusqu’à ce que le monde rattrape son retard. Quel codec est le meilleur n’est jamais la question intéressante. Où se situe la frontière de votre matériel, si.

Pourquoi un décodeur matériel est d’une autre nature#

Tout le reste en découle, et c’est facile à manquer parce que les deux ressemblent à « lire une vidéo ».

Un décodeur matériel est un circuit à fonction fixe sur votre GPU qui implémente un codec précis. Ce n’est pas une version rapide du décodeur logiciel ; c’est une chose différente qui se trouve produire la même sortie. Il n’utilise presque pas de CPU, consomme peu, et soit il existe pour votre codec, soit il n’existe pas.

Il n’y a pas de prise en charge partielle. Un GPU doté d’un décodeur AV1 décode l’AV1 en 4K sans effort. Un GPU qui n’en a pas ne contribue en rien à l’AV1, et le travail retombe sur le CPU qui exécute du logiciel.

Le décodage logiciel fonctionne. Il est aussi coûteux exactement comme on s’y attend : beaucoup de cœurs à forte utilisation, un portable qui chauffe, des ventilateurs, et sur un appareil sans marge, des images perdues.

Nous avons les chiffres du bon cas, et nous les avons parce que nous nous sommes nous-mêmes trompés. Avec le décodage matériel engagé, un titre 4K HEVC Main10 tournait avec les moteurs de décodage vidéo du GPU autour de 11 pour cent. Ce même chemin était en logiciel seul jusqu’au 2026-08-23. La sélection du décodeur est une option par média appliquée à chaque ouverture plutôt qu’une propriété du lecteur, et un chemin de code à la demande la forçait à off quel que soit le réglage, pendant des mois. Même fichier, même machine, même réglage à l’écran, et la seule différence visible était un ventilateur qui s’emballait. C’est toute la raison pour laquelle un mauvais décodeur passe inaperçu : l’image se lit dans les deux cas. Décodage matériel contre décodage logiciel couvre cette frontière en détail.

AV1, et la fracture qu’il crée#

Le cas réel le plus clair de tout cela dans nos propres applications.

La tête de bureau peut décoder l’AV1 sur le GPU quand celui-ci le prend en charge. La tête console ne peut pas, du tout : la version du lecteur qu’elle lie n’embarque aucun décodeur matériel AV1. Une chaîne AV1 sur une console retombe sur le décodage logiciel.

Et ce repli a son propre plafond. Les threads de trames du décodeur y sont plafonnés à 3, pour une raison mesurée : laissé choisir seul, le décodeur en avait pris 6, ce qui produisait un pool de sortie de 40 surfaces en 4K, environ 500 MB de mémoire visible par le GPU contre à peu près 1 GB utilisable sur la console. Le décodage matériel ne touche jamais à ces threads, donc le plafond est gratuit sur chaque chemin qui fonctionne. Il mord précisément là où l’AV1 atterrit.

Ce qu’un spectateur voit : une chaîne qui se lit proprement sur une machine Windows et qui saccade ou échoue sur la console, avec le même compte, le même réseau et la même source. Pourquoi une chaîne fonctionne sur Windows mais pas sur Xbox en est la version diagnostique.

Comment savoir ce qu’une chaîne utilise#

Plus difficile que ça ne devrait l’être.

Le catalogue ne le sait pas. L’enregistrement d’une chaîne en direct ne porte aucun champ codec, aucun champ conteneur et aucun champ transport, parce que ni une ligne M3U ni l’API du panel n’en fournissent. Cette information n’a nulle part d’où venir avant que vous n’ouvriez le flux.

Le panneau d’informations sur le flux vous le dira une fois la lecture commencée, mais lisez-le en sachant ce qu’il fait. Le protocole vient du schéma de l’URI et le conteneur de l’extension de fichier sur le chemin, avec un littéral non disponible quand le chemin n’en a pas. Il les déduit de l’URL au lieu d’interroger le démultiplexeur, donc un portail qui sert du HLS depuis un chemin se terminant par .ts est décrit par son adresse plutôt que par son contenu.

Le champ codec vidéo est celui qui répond à la question de cet article. Lisez celui-là.

Deux choses que l’on attribue aux codecs et qui ne sont pas des codecs#

Le HDR n’est pas une propriété du codec. Il voyage avec HEVC et AV1 en pratique parce que c’est ce que le contenu moderne en haute résolution utilise, mais l’exigence est une surface 10 bits et un espace colorimétrique que l’écran accepte. Dans notre cas, cela a demandé une swapchain gérée par l’application, parce que le contrôle vidéo d’origine construit un tampon 8 bits et que DXGI n’accepte pas un espace colorimétrique HDR10 dessus, si bien que la négociation ne pouvait jamais aboutir qu’au sRGB quel que soit le flux.

Le débit n’est pas la qualité. Une chaîne encodée en HEVC à 8 Mbit/s et une autre en H.264 à 8 Mbit/s n’ont pas le même rendu, et celle en HEVC n’est pas automatiquement meilleure non plus : un encodeur mal configuré gaspille l’avantage de n’importe quel codec. Ce que le codec achète, c’est une meilleure position sur la courbe de qualité par bit. Que votre fournisseur dépense cela en bande passante réduite ou en meilleure image, c’est sa décision, pas celle du format.

Profils et niveaux, et pourquoi « prend en charge HEVC » n’est pas une réponse complète#

Un nom de codec ouvre la question de compatibilité plutôt que de la clore. Chaque norme définit des profils, qui disent quels outils de codage sont autorisés, et des niveaux, qui bornent la résolution et le débit.

Profondeur de bits, d’abord : c’est ce qui compte le plus pour la télévision en direct. HEVC Main gère la vidéo 8 bits ; HEVC Main10 gère le 10 bits. Un décodeur peut prendre en charge l’un et pas l’autre, et le 10 bits est ce que le contenu HDR utilise, donc « mon GPU prend en charge HEVC » et « mon GPU décode cette chaîne HDR » sont deux affirmations différentes.

Le titre 4K de notre propre passe de vérification était précisément en HEVC Main10, et ce profil est le cas intéressant justement parce que c’est là que beaucoup de matériel ancien s’arrête.

Les niveaux bornent l’autre axe. Un décodeur certifié pour un niveau qui couvre le 1080p60 n’acceptera pas nécessairement du 4K60 dans le même codec. C’est l’explication habituelle d’un flux HD d’un fournisseur qui se lit alors que son flux 4K de la même chaîne ne se lit pas, sur du matériel qui « prend en charge » indéniablement le codec.

Ce qu’un fournisseur décide réellement#

Le codec sur votre écran est le résultat du calcul de coûts de quelqu’un d’autre.

Un fournisseur qui diffuse des centaines de chaînes paie de la bande passante pour chacune d’elles, en continu. Faire passer une chaîne de H.264 à HEVC divise cette facture par deux pour la même image. La faire passer encore vers AV1 divise par deux ce qui reste.

Ce qu’ils font de l’économie est une décision distincte, et les deux choix sont courants. Certains la dépensent en bande passante et livrent la même image pour moins cher. D’autres la dépensent en qualité et livrent une meilleure image pour le même débit. C’est pourquoi comparer deux fournisseurs sur le seul débit vous apprend très peu : 6 Mbit/s de HEVC bien configuré peuvent rendre mieux que 12 Mbit/s de H.264 mal configuré.

Le coût retombe sur vous sous forme de travail de décodage, et le plus durement sur celui qui a le matériel le plus ancien. C’est pourquoi une chaîne que vous regardez depuis un an peut soudain se mettre à saccader sans que rien n’ait changé de votre côté. Le fournisseur l’a réencodée.

Cela inverse le diagnostic habituel. Quand une chaîne se dégrade et que tout le reste va bien, vérifiez son codec avant votre réseau.

Comment cela interagit avec la détection des pannes#

Le détecteur de lecture classifie 9 pannes distinctes, et un décodeur qui ne suit pas n’a pas sa propre classe. Il apparaît comme l’une des classes existantes, ce qu’il vaut la peine de comprendre pour ne pas mal lire le diagnostic.

Un décodage logiciel qui prend du retard se présente comme une image bloquée ou un gel total pendant que les octets continuent d’arriver. Le réseau va bien, le démultiplexeur va bien, et les trames n’atteignent pas l’écran assez vite. Du point de vue du détecteur, c’est indiscernable d’une source qui a cessé de produire des trames, parce que les compteurs ont la même allure.

Le détecteur fait donc ce qu’il fait pour n’importe quel gel : attendre la fenêtre de verdict, déclarer, et tenter une récupération. La récupération sur une chaîne limitée par le décodage n’aide pas, parce que redémarrer le flux ne rend pas le décodeur plus rapide. Vous obtenez une chaîne qui se lit quelques secondes, gèle, redémarre, et recommence.

Cette boucle est la signature. Un problème de flux tend à se rétablir ou à échouer ; un problème de décodage tourne en boucle. Quand vous voyez ce cycle, vérifiez le codec. Corriger la mise en mémoire tampon et les saccades couvre les classes de pannes, et la vidéo se fige alors que le son continue explique pourquoi une image figée ne lève jamais d’erreur.

Le levier qui n’est pas un choix de codec#

Vous ne contrôlez pas le codec que votre fournisseur livre. Vous contrôlez la quantité que vous demandez à la machine de décoder à la fois.

La multivue est le cas le plus clair. Les tuiles sont plafonnées à 640 par 360 en sourdine et 1280 par 720 pour celle qui porte le son, et ce plafond est ce qui rend une grille de 9 tuiles possible sur du matériel ordinaire. Neuf décodages en 640 par 360, c’est une autre affaire que neuf décodages 1080p à pleine cadence, quel que soit le codec. Le même raisonnement s’applique à une seule chaîne : si votre fournisseur propose une rendition inférieure, la prendre réduit le travail au lieu de le déplacer entre le CPU et le GPU.

Que faire de tout cela#

Si une chaîne précise échoue sur un appareil et fonctionne sur un autre, vérifiez d’abord son codec vidéo. Cela prend 30 secondes et cela résout la majorité de ces cas.

Si vous achetez du matériel pour cela, le décodage matériel AV1 est la chose à vérifier sur la fiche technique. H.264 et HEVC sont des questions réglées sur tout ce qui est actuel.

Et si une chaîne est en AV1 et que votre appareil ne peut pas la décoder en matériel, demandez à votre fournisseur si la même chaîne est disponible en HEVC. Beaucoup proposent les deux, et c’est une solution plus rapide que n’importe quel réglage.

Pour la classification des pannes quand un flux ne se lit pas du tout, corriger la mise en mémoire tampon et les saccades commence par distinguer 9 pannes distinctes.