Comparatif des encodeurs vidéo matériels : NVENC, AMF, QuickSync et Apple VideoToolbox.

Quatre fabricants. Quatre blocs de silicium à fonction fixe. Une seule mission — transformer une image de pixels en quelques kilooctets de H.265 ou d’AV1 en moins de cinq millisecondes, soixante fois par seconde, sans en perdre une seule. Voici comment NVIDIA, AMD, Intel et Apple se comparent réellement pour le streaming à faible latence, et comment Remio choisit le bon à l’exécution.

Pourquoi les encodeurs matériels comptent pour le bureau à distance

Encodez une seule image 1080p avec libx264 sur un cœur de CPU rapide. Sur une puce Apple de la série M récente ou un Ryzen 7000, vous atteignez environ 8 à 12 millisecondes avec le préréglage ultrafast, davantage pour tout ce qui cherche à préserver la qualité. Cela paraît tolérable jusqu’à ce qu’on se rappelle le budget : 16,6 millisecondes par image à 60 FPS. Ajoutez maintenant la capture, la mise en paquets, la file du pacer, la sortie réseau, le décodage et le rendu. L’encodage par CPU ne se contente pas de vous ralentir — il dévore tout le budget de latence, et au-delà du 1080p60, il perd des images.

Les encodeurs matériels résolvent le problème en consacrant du silicium à fonction fixe à cette même tâche. NVIDIA appelle son bloc NVENC. AMD appelle le sien AMF (plus précisément le moteur VCN que pilote AMF). Intel appelle le sien QuickSync (le Media Engine intégré à son iGPU). Apple appelle le sien VideoToolbox (c’est l’API ; le silicium, c’est le Media Engine des puces de la série M et de la série A). Tous les quatre existent pour une seule raison : l’encodage logiciel ne peut pas atteindre les objectifs de latence et de fréquence d’images qu’attendent désormais les écrans, les GPU et les utilisateurs modernes.

Pour Remio en particulier, chaque milliseconde gagnée à l’encodeur est une milliseconde rendue au pacer, au réseau et au moteur de rendu. Notre budget de latence publié vise environ 8 ms de traitement sur réseau local (le reste correspond à la cadence de rafraîchissement 60 Hz de votre propre écran) — le temps d’encodage est la plus grande variable. Le choix de l’encodeur, et la configuration de cet encodeur, déterminent tout ce qui suit.

Les quatre fabricants en un coup d’œil

Avant de détailler chacun, il est utile de comprendre ce que nous comparons réellement. Ce ne sont pas des bibliothèques interchangeables — ce sont des blocs physiques sur une puce, chacun avec son propre jeu d’instructions, sa propre pile de pilotes, ses propres particularités et sa propre feuille de route sur plusieurs années. Ils diffèrent par les codecs qu’ils prennent en charge, la qualité qu’ils produisent, la latence qu’ils atteignent, la puissance qu’ils consomment et les plateformes sur lesquelles ils existent.

• NVENC équipe toutes les NVIDIA GeForce, Quadro et RTX depuis 2012 (Kepler). Les générations sont liées aux familles d’architectures : 1re génération sur Kepler, 8e génération sur Ada Lovelace. Les composants Hopper pour datacenters suivent un autre rythme.
• AMF expose le moteur VCN (Video Core Next) d’AMD, qui a remplacé l’ancien VCE. Disponible sur tous les GPU Vega, RDNA, RDNA2 et RDNA3, ainsi que sur les APU récents.
• QuickSync équipe les iGPU Intel depuis Sandy Bridge en 2011 — ce qui en fait l’encodeur matériel le plus répandu sur Terre. Les GPU discrets Arc utilisent la même architecture, en plus grand.
• VideoToolbox est l’API d’Apple ; le silicium en dessous est le Media Engine, intégré à chaque Mac Apple Silicon, à chaque iPhone depuis l’A6 et à chaque iPad. Les puces de la série M embarquent un ou deux moteurs selon la référence.

NVENC — huit générations de perfectionnement chez NVIDIA

NVENC est l’encodeur par rapport auquel la plupart des logiciels de streaming sont évalués, en partie parce que NVIDIA a le budget marketing, et en partie parce que le silicium est réellement excellent depuis dix ans. Le bloc a connu huit générations :

• 1re à 3e génération (Kepler à Maxwell, 2012-2014) — H.264 uniquement, utilisable pour le streaming mais avec une qualité nettement en retrait de libx264.
• 4e génération (Pascal, GTX série 10) — ajout de l’encodage H.265. C’est la génération où la qualité de NVENC a rattrapé, voire dépassé, les préréglages fast de libx264 au même débit.
• 6e génération (Turing, RTX série 20, GTX série 16) — le bond souvent cité du « NVENC Turing ». La qualité à bas débit s’est assez améliorée pour que les streamers cessent de prétendre que l’encodage CPU était nettement meilleur en direct.
• 7e génération (Ampere, RTX série 30) — des améliorations, avec une qualité globalement équivalente à Turing par watt.
• 8e génération (Ada Lovelace, RTX série 40) — première génération NVIDIA avec encodage AV1 matériel, et deux moteurs d’encodage sur les références haut de gamme. Le NVENC d’Ada peut encoder en AV1 avec une qualité comparable aux préréglages medium de libaom-av1, pour une infime fraction du coût en CPU.

Pour un usage à faible latence, NVENC expose trois modes de contrôle de débit pertinents. CBR avec le réglage low-latency et le préréglage p1 (le plus rapide) est la configuration canonique : débit de sortie déterministe, anticipation d’une seule image, pas d’images B. Remio utilise exactement cela avec hevc_nvenc sur Windows. Sur Ada Lovelace, le temps d’encodage d’une image 1080p60 H.265 est constamment de 1 à 3 ms.

Un piège historique : le NVENC grand public a longtemps été limité à trois sessions d’encodage simultanées par le pilote NVIDIA. Cette limite a été portée à huit en 2023, puis effectivement supprimée. Si vous lisez un vieux fil de forum qui vous en avertit, l’avertissement ne s’applique plus.

AMF — l’outsider d’AMD qui a fini par rattraper son retard

L’AMF d’AMD (Advanced Media Framework) est l’API ; le moteur sous-jacent a connu deux architectures distinctes. L’ancien VCE (Video Coding Engine) équipait les cartes de l’ère GCN à partir de 2012 et a été le maillon faible perpétuel des comparatifs d’encodeurs — une qualité visiblement inférieure à NVENC à débit égal, surtout sur les contenus riches en mouvement. AMD le savait, la communauté du streaming le savait, et les benchmarks le confirmaient.

Cette histoire a changé avec VCN (Video Core Next), introduit sur Vega et affiné à chaque génération suivante :

• VCN 1.0 à 2.0 (Vega, RDNA1) — H.264 et H.265 avec une qualité qui est enfin passée à un cheveu de NVENC Pascal/Turing.
• VCN 3.0 (RDNA2, série RX 6000) — des améliorations de qualité significatives, notamment à bas débit. La première génération AMD que je suis à l’aise de recommander pour le streaming de jeu.
• VCN 4.0 (RDNA3, série RX 7000) — ajoute l'encodage AV1 en parallèle de NVIDIA Ada. Deux encodeurs sur les références haut de gamme pour des sessions parallèles. La qualité AV1 est comparable à celle de NVIDIA dans les benchmarks tiers.

Pour le streaming à faible latence, AMF expose un préréglage d’usage ultralowlatency, un préréglage de qualité speed et un mode de contrôle de débit cbr. Remio utilise hevc_amf avec les trois — le même triplet de préréglages documenté dans nos notes sur l'architecture de streaming. Le temps d’encodage sur RDNA3 pour du 1080p60 H.265 se situe typiquement entre 2 et 4 ms. RDNA2 tourne autour de 3 à 5 ms. Les cartes plus anciennes de l’ère VCN 1.x approchent de 5 à 7 ms — encore dans le budget, mais avec moins de marge pour les pics de keyframes.

Pendant cinq ans, l’encodeur d’AMD a été une plaisanterie. RDNA2 l’a corrigé. RDNA3 l’a rendu compétitif en AV1. Le duopole des encodeurs de streaming est désormais un triopole, et c’est une bonne chose pour tout le monde.

QuickSync — le champion discret de l’ubiquité

QuickSync est l’encodeur que vous possédez presque certainement déjà. Il équipe tous les processeurs Intel à graphique intégré depuis Sandy Bridge en 2011 — soit plus d’une décennie d’ordinateurs portables, de NUC et de PC de bureau dotés d’un encodage vidéo matériel resté inutilisé parce que l’utilisateur pensait qu’il lui fallait un GPU discret. Ce n’était pas le cas.

L’architecture a progressé au rythme de la lignée d’iGPU d’Intel :

• Sandy Bridge à Skylake (2011-2015) — H.264 uniquement, qualité moyenne, mais latence et consommation exemplaires pour un portable.
• Kaby Lake à Coffee Lake (2016-2018) — ajout du H.265, du 10 bits et de l’encodage 4K.
• À partir d’Ice Lake (2019+) — l’iGPU Xe Gen11/Gen12 a nettement amélioré la qualité. De nombreux benchmarks classent le QuickSync Gen12 à quelques points de NVENC Turing.
• Arc discret (2022+) — la première gamme de GPU discrets d’Intel. La même architecture Xe-HPG en plus grand, avec encodage AV1. Arc a été le premier GPU grand public à proposer un AV1 matériel — devançant NVIDIA Ada et AMD RDNA3 sur le marché — et la qualité est étonnamment excellente. Une Intel Arc A380 reste une affaire absurde pour le débit AV1 pur par dollar.

Le profil thermique est le superpouvoir discret de QuickSync. Comme il vit dans un iGPU déjà présent sur le SoC, le coût marginal de son utilisation se limite au bloc d’encodage — pas de GPU discret à réveiller, pas de contrôleurs mémoire GDDR6 à démarrer. Sur un ThinkPad ou un NUC, QuickSync offre une qualité comparable à NVENC pour environ le quart de la consommation au niveau du système. Pour l’hôte Windows de Remio, QuickSync est le troisième choix de repli après NVENC et AMF — non parce qu’il est moins bon, mais parce que les utilisateurs dotés d’un GPU discret préfèrent généralement garder leur iGPU libre pour d’autres charges.

VideoToolbox — le Media Engine unifié d’Apple Silicon

Apple ne met pas en avant une marque pour son encodeur matériel comme le fait NVIDIA. L’API est VideoToolbox ; le silicium est le Media Engine, un bloc conçu par Apple qui vit dans chaque Mac de la série M et dans chaque SoC d’iPhone/iPad depuis l’A6.

Le Media Engine est présent en nombre variable selon la référence :

• M1, M2, M3 — un Media Engine.
• M1 Pro/Max, M2 Pro/Max, M3 Pro/Max — deux Media Engines.
• M1 Ultra, M2 Ultra — quatre Media Engines (deux par puce fusionnée).
• M3 Max (CPU 16 cœurs) — deux Media Engines.
• Famille M4 — Media Engine remanié, avec un débit H.265 amélioré.

Chaque Media Engine gère l’encodage et le décodage H.264, H.265 et ProRes en matériel. L’encodage ProRes est la fonction phare pour les monteurs vidéo — aucune autre puce grand public ne le propose — mais pour le streaming, les capacités pertinentes sont un encodage H.265 main10 efficace et une latence d’encodage étonnamment basse.

La seule lacune notable : pas d’encodage AV1 sur aucun Apple Silicon en vente. Les puces de la série M décodent l’AV1 depuis le M3, mais ne peuvent pas l’encoder. Pour diffuser depuis un Mac, le H.265 reste le choix pratique par défaut dans un avenir prévisible.

Là où Apple gagne vraiment, c’est l’efficacité énergétique. Sur un M2 Pro qui encode du 4K60 H.265 à 30 Mbps, l’ensemble du Media Engine consomme environ 3 à 5 watts. La même charge NVENC sur une RTX 4070 consomme plutôt 35 watts au niveau du système — dont l’essentiel est le plancher de repos du GPU discret, pas le bloc d’encodage. Pour un Mac mini hôte allumé 24 h/24 en attendant un client, c’est la différence entre « à peine visible sur la facture d’électricité » et « bien visible ».

Comparaison côte à côte

Voici les quatre moteurs sur les mêmes axes. Les chiffres de latence correspondent à des préréglages H.265 ultra faible latence en 1080p60, images B désactivées, VBV d’une seule image — la configuration de Remio. La qualité est un classement perceptuel approximatif à 8 Mbps en CBR ; les écarts absolus sont faibles.

Le résumé honnête : avec les réglages que le streaming de bureau à distance utilise réellement (CBR, faible latence, pas d’images B), les quatre sont suffisamment bons avec une marge confortable. Ce qui les distingue, c’est la prise en charge de l’AV1 (NVIDIA / AMD / Intel — pas Apple), l’efficacité énergétique (Apple, puis l’iGPU Intel, puis tous les autres) et la disponibilité selon la plateforme (vous ne choisissez pas VideoToolbox sur un hôte Windows ni NVENC sur un Mac).

Ce que Remio choisit à l’exécution

Remio sonde les capacités de l’hôte au démarrage et choisit un encodeur selon une priorité déterministe. L’hôte Windows et l’hôte Mac suivent la même logique de sélection.

Sur les hôtes Windows :

1. NVENC (hevc_nvenc / h264_nvenc) — choisi en premier lorsqu’un GPU NVIDIA est présent et que le pilote répond. Préféré parce que c’est l’encodeur le plus régulièrement faible en latence sur la plus large gamme de générations matérielles.
2. AMF (hevc_amf / h264_amf) — choisi en deuxième lorsqu’un GPU discret AMD ou un APU doté de VCN est présent. Configuré avec usage=ultralowlatency, quality=speed, rc=cbr.
3. QuickSync (hevc_qsv / h264_qsv) — choisi en troisième lorsqu’un iGPU Intel est présent. Fonctionnellement équivalent dans notre pipeline ; nous préférons laisser l’iGPU libre si un GPU discret est disponible.
4. Repli CPU libx264 — choisi seulement si aucun encodeur matériel ne répond. Plafonné à 720p60 ou 1080p30 pour rester dans le budget de latence.

Sur les hôtes Apple : VideoToolbox est la seule option, et la seule que nous voulons. Le Media Engine de chaque Mac pris en charge (macOS 15+) gère le H.265 main10 d’emblée. Aucun chemin de repli nécessaire.

La préférence de codec va au H.265 matériel d’abord, avec le H.264 comme repli universel — de bout en bout, sur chaque plateforme. Remio n’utilise pas l’AV1 aujourd’hui (l’encodage côté hôte, le décodage côté client et la négociation du codec ne figurent pas dans le pipeline) ; il s’en tient au H.265 même sur du matériel qui pourrait techniquement faire de l’AV1, parce que sur réseau local le goulot d’étranglement est la latence d’encodage, pas le débit.

Compromis entre qualité et latence

Chaque encodeur matériel expose le même petit nombre de réglages, et chaque réglage échange de la qualité contre de la latence dans le même sens. La configuration de Remio se situe à l’extrémité la plus agressive du curseur de latence, parce que le bureau à distance est, par définition, une application en temps réel où une image vieille de plus de 20 ms est pire qu’une image un peu plus floue que l’idéal.

• CBR ou VBR. Le débit variable produit une meilleure qualité au même débit moyen en dépensant les bits là où ils servent. Mais il produit aussi une taille d’image imprévisible, donc une file de pacer imprévisible, donc une latence imprévisible. Remio utilise le CBR partout. Le coût en qualité est faible ; la régularité de la latence est énorme.
• Images B. Les images B référencent à la fois des images passées et futures : le décodeur doit donc attendre l’arrivée de l’image future avant de décoder l’image B. C’est acceptable pour la vidéo à la demande et fatal pour le temps réel. Remio désactive les images B sur chaque codec et chaque plateforme.
• GOP / intervalle de keyframes. Des GOP plus longs (plus d’images entre les keyframes) compressent mieux. Des GOP plus courts se rétablissent plus vite après une perte de paquets. Remio utilise des GOP effectivement infinis et demande à l’hôte une nouvelle keyframe quand le décodeur signale une perte. Un paquet perdu est renvoyé aussitôt s’il peut encore arriver à temps ; sinon, Remio l’ignore et demande une image fraîche plutôt que d’attendre. Cela correspond à notre philosophie du streaming : n’afficher que l’image la plus récente.
• Anticipation. NVENC, AMF et QuickSync prennent tous en charge l’anticipation multi-images pour la quantification adaptative. Chaque image d’anticipation ajoute une image complète de retard. Remio utilise zéro ou une image d’anticipation — le réglage le plus bas de chaque encodeur.
• Tampon VBV. La fenêtre du Video Buffering Verifier correspond au nombre de bits que l’encodeur est autorisé à « emprunter par anticipation » avant de revenir au débit cible. Un VBV plus grand donne une qualité plus lisse. Un VBV plus petit donne un contrôle de débit plus serré et une latence plus basse. Remio utilise 1 image de VBV — le débit divisé par la fréquence d’images — qui est la plus petite valeur autorisée.

Le schéma est constant chez les quatre fabricants. Le temps réel à faible latence est une optimisation sous contrainte : vous renoncez aux quelques pourcents de qualité qu’achètent l’anticipation et les images B dans l’encodage hors ligne, en échange de la latence prévisible qu’exige l’interaction en temps réel. Tous les produits de streaming en service — Remio, Parsec, NVIDIA GeForce NOW, Xbox Cloud Gaming — font le même compromis dans le même sens.

Ce dont vous (l’utilisateur) devez vraiment vous soucier

Si vous avez sauté à la fin : l’encodeur matériel de n’importe quel GPU récent convient pour le bureau à distance.

Les différences, dans les configurations temps réel, sont plus petites que le bruit de fond de n’importe quel benchmark raisonnable. Un utilisateur de GTX 1060 Pascal obtient la même expérience Remio qu’un utilisateur de RTX 4090 — les deux saturent le pipeline à 120 FPS avec environ 8 ms de latence de traitement (le reste correspond à la cadence de rafraîchissement 60 Hz de votre propre écran), et les deux produisent un résultat indiscernable aux débits d’un réseau local.

Les exceptions, dans l’ordre de leur fréquence d’importance :

• Le matériel compatible AV1 aide sur les réseaux lents, en général. Wi‑Fi d’hôtel ou partage de connexion mobile : un hôte Ada / RDNA3 / Arc avec un client M3+ ou RTX série 40 offre environ 25 % de marge en plus à qualité égale dans les outils qui l’utilisent. Sur réseau local, rien. Remio n’exécute pas encore l’AV1 — le H.265 de bout en bout fait tout le pipeline — donc aujourd’hui c’est un avantage du fabricant, pas de Remio.
• Les Mac Apple Silicon sont de remarquables hôtes. La faible latence du Media Engine, son excellent H.265 et sa consommation de 3 à 5 W font d’un Mac mini ou d’un Mac Studio l’une des meilleures sources de streaming toujours allumées que l’on puisse acheter. L’absence d’encodage AV1 est la seule lacune, sans importance sur réseau local.
• Une Intel Arc A380 est une affaire déraisonnable pour l’AV1. Environ 120 $ achètent un bloc d’encodage qui bat tout le reste sous 400 $.
• Le repli CPU libx264 est bien réel. Sans encodeur matériel — vieux portable, serveur sans iGPU — Remio fonctionne quand même. Simplement pas en 4K 60, et pas sans brûler un cœur de CPU.

Au-delà de ces cas limites, la bonne réponse est la plus simple : utilisez le GPU que vous achèteriez de toute façon. Tous les fabricants modernes ont convergé vers les mêmes capacités, les mêmes préréglages à faible latence, la même enveloppe de qualité. Remio choisit le bon à l’exécution pour que vous n’ayez pas à y penser. Occupez-vous de ce pour quoi vous avez ouvert une session de bureau à distance — coder, monter une vidéo, réparer un serveur, pousser un correctif depuis un café.

C’est tout l’intérêt du silicium à fonction fixe. Cela fonctionne, tout simplement, et on cesse de le remarquer.