Décodage matériel ou logiciel : pourquoi votre ventilateur s’emballe

Deux façons de transformer un flux vidéo compressé en images. Elles produisent la même sortie, et presque rien d’autre ne leur est commun.

Ce qu’est chacun des deux#

Décodage matériel. Le flux compressé est confié à un bloc à fonction fixe de votre GPU. Ce bloc implémente un codec précis dans le silicium. Ce n’est pas une version plus rapide du décodeur logiciel ; c’est un circuit dédié qui se trouve produire les mêmes images, en n’utilisant presque pas de CPU et très peu d’énergie.

Décodage logiciel. Le décodeur tourne comme du code ordinaire sur votre CPU, réparti sur plusieurs cœurs. Il fonctionne pour tout codec que le logiciel prend en charge, c’est-à-dire presque tous, et il coûte du vrai temps CPU.

La distinction qui compte le plus : la prise en charge matérielle est binaire, codec par codec. Votre GPU a un décodeur AV1 ou il n’en a pas. Il n’y a pas d’accélération partielle, pas de mode dégradé, pas de « surtout matériel ». Si le bloc est absent, tout le travail retombe sur le logiciel.

Le réglage, et ce qu’il émet réellement#

Trois états, correspondant à trois sélections de décodeur transmises au lecteur avec chaque média :

Auto   avcodec-hw=d3d11va   ask for the Direct3D 11 video decoder
On     avcodec-hw=any       take any hardware decoder available
Off    avcodec-hw=none      software only

Auto convient à presque tout le monde. Off est un outil de débogage : si une chaîne affiche de la corruption ou refuse de s’ouvrir, forcer le décodage logiciel vous dit en un seul essai si vous avez affaire à un problème de pilote ou à un problème de flux.

Un détail structurel, parce qu’il a causé un vrai bug. Il s’agit d’une option par média, appliquée à chaque ouverture d’un média, et non d’un commutateur d’instance fixé une fois pour toutes au démarrage. C’est la bonne conception. Cela signifie aussi que chaque chemin de lecture doit penser à l’appliquer.

Le bug qui se cachait exactement dans cette faille#

Jusqu’au 2026-08-23, la TV en direct respectait le réglage d’accélération et le chemin à la demande le forçait à off en dur. Chaque film et chaque épisode était décodé en logiciel, quoi que dise le réglage, sur toutes les machines.

Nous nous sommes trompés, et rien de tout cela n’était visible depuis l’interface. Le réglage existait, il était persistant, il disait Auto, et les films étaient quand même décodés en logiciel. Le symptôme, c’était « les films font s’emballer le ventilateur et pas la TV en direct », facile à mettre sur le compte de la taille du fichier ou du débit.

Après le correctif, le même titre 4K se lisait avec les moteurs de décodage vidéo du GPU à environ 11 pour cent. Même fichier, même machine, même réglage.

La raison d’écrire ceci plutôt que de corriger en silence : c’est l’illustration la plus claire de la raison pour laquelle on vérifie que le décodage matériel est engagé au lieu de faire confiance à un réglage. Ouvrez le panneau d’informations sur le flux, et regardez le moteur de décodage vidéo de votre GPU dans le Gestionnaire des tâches pendant qu’une lecture est en cours. Un flux 4K avec le moteur de décodage vidéo proche de zéro et des cœurs CPU chargés, c’est du décodage logiciel, quoi que dise le réglage.

Les threads, et un coût que vous n’auriez pas prédit#

Quand le décodage logiciel a bel et bien lieu, le décodeur répartit les images sur des threads. Le nombre qu’il choisit compte pour des raisons qui n’ont rien à voir avec le temps CPU.

Laissé choisir seul, le décodeur a pris 6 threads sur la machine de mesure. Cela a produit un pool de sortie Direct3D 11 de 40 surfaces en 4K, soit à peu près 500 Mo d’allocation visible par le GPU. Face à un budget Xbox d’environ 1 Go, c’est la moitié de la mémoire accordée à toute l’application, dépensée en tampons de décodeur. Je ne m’attendais pas à ce qu’un nombre de threads soit une décision de mémoire.

Alors la console le plafonne à 3.

L’élégance de ce plafond tient à ce qu’il coûte, c’est-à-dire rien sur aucun chemin qui fonctionne. Le décodage matériel n’utilise pas du tout ces threads. Le plafond ne s’applique qu’au repli logiciel, qui sur la console est là où atterrit l’AV1, parce que la build du lecteur de la console n’a pas de décodeur matériel AV1.

L’autre levier, qui n’est pas un réglage de décodeur#

Si le coût de décodage est votre problème, la résolution est un levier plus puissant que le choix du décodeur.

Les tuiles de multivue sont plafonnées à 640 par 360 en sourdine et à 1280 par 720 quand elles portent l’audio, et c’est ce plafond qui rend une grille de 9 tuiles possible tout court. C’est moins un compromis de qualité que la reconnaissance qu’une tuile de 4 pouces de large ne tire aucun bénéfice du 1080p.

Le même raisonnement vaut pour une chaîne avec laquelle votre machine peine. Si votre fournisseur propose la même chaîne dans une déclinaison de moindre résolution, c’est souvent une meilleure réponse que n’importe quel réglage, parce que cela réduit le travail au lieu de le redistribuer.

Comment le vérifier réellement, en 2 minutes#

Le réglage n’est pas une preuve. Ceci en est une.

Ouvrez le Gestionnaire des tâches, allez dans Performance, sélectionnez votre GPU et passez l’un des graphiques sur Décodage vidéo. Puis lancez une chaîne.

Video Decode busy, CPU cores quiet     hardware decoding
Video Decode flat, several cores busy  software decoding

C’est tout le test, et il est définitif d’une manière que l’écran des réglages n’est pas. Sur la machine de notre propre passe de vérification, un titre 4K a fait monter ce graphique à environ 11 pour cent là où il restait auparavant à zéro, le CPU portant le travail.

Deux fausses lectures à connaître. Une machine avec 2 GPU peut décoder sur celui que vous ne regardez pas, ce qui est courant sur les portables à graphismes commutables. Et une très petite fenêtre peut être assez peu coûteuse pour se décoder en logiciel sans charge CPU évidente, donc testez à une taille à laquelle vous regarderiez vraiment.

Le panneau d’informations sur le flux est l’autre moitié de la vérification, parce qu’il vous dit quel codec vous demandez à la machine de décoder. Ses champs protocole et conteneur sont dérivés de l’URL plutôt que du démultiplexeur ; le champ codec vidéo est celui qui répond à cette question.

Le coût mémoire, qui est la partie surprenante#

On parle généralement du décodage comme d’un arbitrage entre CPU et GPU. Sur un appareil contraint en mémoire, c’est autant une décision de mémoire que de calcul, et les chiffres ne sont pas intuitifs.

Le threading des images alloue des tampons d’image. Plus de threads, c’est plus de tampons en vol, et en 4K chaque tampon est gros. C’est toute l’histoire derrière le pool de 500 Mo ci-dessus, et c’est pourquoi le plafond est de 3 plutôt qu’un nombre choisi pour des raisons de CPU. C’est aussi pourquoi le plafond ne coûte rien là où le décodage matériel fonctionne : le chemin matériel n’alloue pas du tout ces tampons.

Le contexte plus large rend la chose plus nette. Notre propre profilage d’une session de navigation de 12 minutes sur le bureau s’est terminé à 918 Mo de working set avec un pic à 1 080 Mo, face à un budget interne de 400 Mo, le tas managé restant plat à environ 62 Mo sur les mêmes cycles. La croissance est native, et les tampons de décodeur sont natifs. Sur une console avec à peu près 1 Go utilisable, un chemin de décodage logiciel qui veut 500 Mo de pools n’est pas un problème de performance. C’est une mise à mort.

Pourquoi « il suffit de se replier » n’est pas une conception#

Une suggestion qui semble raisonnable : essayer le matériel, et s’il échoue, basculer automatiquement et silencieusement sur le logiciel.

Ce qui rend cela plus dur qu’il n’y paraît, c’est le mode de défaillance de la couche du dessous. Passer au lecteur un commutateur appartenant à un module que sa build n’embarque pas ne produit pas une erreur récupérable. Cela fait échouer toute l’instance du lecteur, et l’échec ne nomme pas l’option qui l’a causé. Le flux ne s’ouvre pas.

Le jeu de commutateurs émis est donc calculé en amont, par tête, à partir d’une liste d’autorisation, avec des tests qui garantissent que chaque combinaison de tête, de rôle, de réglage et de profondeur de surface n’émet que des commutateurs permis. L’alternative, découvrir la prise en charge en essayant, signifie qu’une tentative ratée coûte une instance entière et produit une erreur qui ne pointe nulle part.

C’est aussi pourquoi les capacités que la console ne peut pas prendre en charge sont masquées plutôt qu’affichées et désactivées. Il n’y a pas de version partielle vers laquelle dégrader, et un contrôle qui ferait échouer le lecteur si on l’utilisait est pire que pas de contrôle du tout.

Il existe une vraie échelle de repli, et elle montre à quoi ressemble une échelle bien faite. La surface vidéo essaie 3 configurations dans l’ordre :

1  R10G10B10A2 + Ignore        preferred, 10-bit
2  R10G10B10A2 + Unspecified   10-bit, different alpha handling
3  B8G8R8A8 + Unspecified      8-bit, identical to the previous behaviour

Ce qui rend cette échelle sûre, c’est le dernier échelon : il est identique octet pour octet à la configuration livrée avant que tout cela n’existe, donc une machine qui ne peut pas composer en 10 bits se comporte exactement comme elle l’a toujours fait au lieu d’entrer dans un état non testé. Un échec total est journalisé et laisse la surface non chargée au lieu de lever une exception depuis un rappel de mise en page, ce qui ferait tomber l’application.

Un repli n’est un repli que si l’échelon du bas est connu pour être fiable.

Que vérifier, dans l’ordre#

Le décodage matériel est-il réellement engagé ? Regardez le moteur de décodage vidéo du GPU, pas le réglage.

S’il ne l’est pas, existe-t-il un décodeur matériel pour ce codec sur cette machine ? H.264, HEVC et AV1 explique où se situent les frontières, et l’AV1 est là où se trouvent la plupart d’entre elles.

S’il en existe un, vos pilotes GPU sont-ils à jour ? Conseil terne, et parfois toute la réponse, parce que la prise en charge des décodeurs arrive avec les pilotes.

Et si cette machine ne décodera jamais ce codec en matériel, les options sont une déclinaison inférieure, un autre codec chez le fournisseur, ou un autre matériel. Aucun réglage ne remplace un circuit qui n’est pas là.