Accélération matérielle

Vérifier ce que vous utilisez

Paramètres → Audio et vidéo → Qualité de streaming est le moyen le plus rapide. Le menu Codec vidéo indique pour chaque option Hardware Accelerated, Software Encoding ou Unsupported, et grise celles que votre machine ne peut pas utiliser du tout. Juste en dessous, la carte Accélération matérielle affiche le backend d'encodage détecté par l'application de bureau au démarrage (NVENC, AMF, QSV, VAAPI ou VideoToolbox), les codecs qu'il propose et le backend de décodage associé. Cette détection tourne en arrière-plan au lancement, la carte est donc normalement remplie quand vous ouvrez les Paramètres.

Pour un appel en cours, le journal d'activité du salon vocal est plus utile. Quand quelqu'un lance sa caméra ou un partage d'écran, une sous-ligne grisée sous cette entrée indique le codec, le nom de l'encodeur et s'il s'agit de matériel ou de logiciel, par exemple AV1 · AV1 (FFmpeg-NVENC) · hardware. Les changements d'encodeur en cours de stream ont leur propre entrée, vous voyez donc quand un chemin matériel a abandonné et ce qui l'a remplacé.

Le fichier de log de l'application de bureau contient le reste. Il se trouve dans %LOCALAPPDATA%\GameVox\logs\ sous Windows, ~/Library/Application Support/GameVox/logs/ sous macOS et ~/.gamevox/logs/ sous Linux. Les lignes à chercher :

• [HWEnc] Detected: le backend d'encodage et les codecs qu'il annonce
• [NVENC] Function table loaded successfully (API X.Y) la version de l'API NVENC exposée par votre pilote NVIDIA
• Selected encoder: ce que l'échelle a retenu pour ce partage
• [FFmpegHW] Created l'encodeur s'est ouvert, avec la résolution et le débit
• [EncSelect] ... trial failed un encodeur matériel a refusé la demande et l'échelle est passée au suivant
• [ScreenShare-Win] Capture backend: WGC, DXGI ou BitBlt, la méthode de capture Windows utilisée

Comment un codec est choisi

GameVox négocie AV1, VP9, H.264 et VP8. HEVC ne fait pas partie de cette liste, les tableaux ci-dessous ne l'indiquent donc pas, même si la plupart de ces GPU savent l'encoder.

L'émetteur parcourt une échelle de haut en bas et s'arrête au premier échelon que le serveur a proposé et que le GPU accepte réellement d'ouvrir. Cette deuxième partie n'est pas une supposition : le client crée un encodeur jetable à la résolution et au débit exacts qu'il s'apprête à utiliser, car beaucoup de pilotes passent en 1080p et échouent en 4K.

Windows

1. AV1 sur le GPU : av1_nvenc, av1_amf ou av1_qsv
2. VP9 sur le GPU : vp9_qsv uniquement. NVIDIA et AMD n'ont jamais livré d'encodage VP9 en silicium, ces systèmes sautent donc complètement cet échelon
3. H.264 sur le GPU : h264_nvenc, h264_amf ou h264_qsv
4. VP9 en logiciel (libvpx), puis VP8, puis AV1 via libaom

Linux

1. VAAPI AV1, une fois que le test VAAPI hors processus a confirmé qu'il fonctionne
2. NVENC AV1, pour les machines NVIDIA sans la passerelle nvidia-vaapi-driver
3. VAAPI VP9
4. VAAPI H.264, uniquement pour la caméra et la vidéo du DJ
5. NVENC H.264
6. libaom AV1, puis libvpx VP9, puis VP8

Le partage d'écran saute volontairement l'échelon VAAPI H.264. La qualité des pilotes sur du contenu d'écran a été assez mauvaise chez Intel et AMD, avec de gros blocs dans les scènes rapides, pour que VP9 en logiciel donne une meilleure image. NVENC H.264 reste actif pour le partage d'écran, une machine NVIDIA sous Linux profite donc toujours du H.264 matériel au lieu de tomber jusqu'à un encodeur logiciel.

VAAPI AV1 est le seul échelon qui ne fonctionne pas sur la confiance. Le radeonsi de Mesa d'origine a tendance à se bloquer à la première tentative d'AV1, le client saute donc AV1 tant qu'un processus de test séparé ne l'a pas ouvert avec succès au moins une fois. Au premier lancement, cela peut vouloir dire NVENC ou AV1 logiciel pour le premier partage, puis VAAPI AV1 ensuite.

macOS

La version macOS n'embarque pas du tout les encodeurs matériels FFmpeg. L'encodage et le décodage passent tous deux par VideoToolbox dans la pile WebRTC de WebKit, ce qui vous donne du H.264 accéléré mais pas d'AV1 : Apple n'a jamais mis d'encodeur AV1 dans aucune puce.

Forcer un autre choix

Le menu Codec vidéo place votre choix en tête de l'échelle au lieu de l'imposer. Choisissez AV1 sur une GTX 1080 : il n'y a aucun encodeur AV1 à ouvrir, l'échelle reprend donc son ordre normal au lieu de faire échouer le partage. Auto est presque toujours le bon réglage.

Chemins par plateforme

Sous Linux, le décodeur essaie d'abord VAAPI puis se rabat sur NVDEC, une carte NVIDIA décode donc en matériel sans que la passerelle nvidia-vaapi-driver soit installée. Les images décodées en matériel reviennent en NV12 et sont converties en RGBA sur le CPU, ce qui coûte à peu près autant que l'étape de conversion du décodeur logiciel lui-même.

Encodage par GPU

Envoi de vidéo : caméra et partage d'écran.

Intel est le seul fabricant à avoir jamais intégré un encodeur VP9 dans des puces grand public, à partir de Kaby Lake. L'encodage AV1 est arrivé avec Arc et les iGPU Core Ultra chez Intel, RDNA 3 chez AMD et Ada Lovelace chez NVIDIA. Tout ce qui est plus ancien encode le H.264 en matériel et tout le reste en logiciel.

Décodage par GPU

Réception de la vidéo de tous les autres membres du salon.

Ces colonnes décrivent le silicium. Un GPU capable de décoder un codec a quand même besoin d'un pilote qui l'expose, et une machine Linux sans libva-drm décode en logiciel quoi que le matériel prenne en charge. GameVox tente d'abord le décodage matériel et passe en logiciel dès la première image si l'accélérateur refuse de s'initialiser.

Pourquoi l'image peut quand même être mauvaise

Un encodeur matériel sur un GPU performant peut quand même produire un stream flou ou saccadé, car la résolution et le codec ne sont pas les seuls facteurs. Les deux causes les plus fréquentes n'ont rien à voir avec les tableaux ci-dessus.

Votre groupe peut plafonner le débit

Les propriétaires de serveur peuvent fixer un plafond de débit pour un groupe, séparément pour le partage d'écran, la caméra et le micro. Le plafond réellement appliqué à votre encodage est le plus bas entre celui du niveau du serveur et celui de votre groupe, un serveur Diamond peut donc quand même limiter un groupe à 2,5 Mbps en partage d'écran. Les plafonds vont de 2,5 à 25 Mbps pour le partage d'écran, de 0,8 à 10 Mbps pour la caméra et de 48 à 256 kbps pour le micro.

Vous êtes dans un seul groupe par serveur, c'est donc toujours le plafond de ce groupe qui s'applique : si vous changez de groupe, son plafond remplace l'ancien. Un groupe sans plafond défini vous laisse sans limite. Les propriétaires de serveur ne sont pas soumis à leurs propres limites. Si un plafond a été appliqué à un stream, le journal d'activité du salon l'indique sur la même sous-ligne grisée que le codec et l'encodeur. Ce journal est donc le moyen le plus rapide de distinguer une limite de groupe d'un problème d'encodeur.

La qualité baisse toute seule quand la bande passante manque

La qualité que vous choisissez est un plafond, pas une promesse. Quand les spectateurs de votre stream commencent à perdre des paquets, le serveur le mesure et demande à votre client de lever le pied ; votre encodeur est recréé au débit inférieur en une seconde environ. Une fois la congestion résorbée, le serveur lève la limite et le préréglage que vous avez choisi revient tout seul. Rien à redémarrer.

Ce qui cède en premier dépend de ce que vous envoyez. Par défaut, le partage d'écran protège la résolution : le texte et l'interface restent nets et c'est la fréquence d'images qui baisse. Passer le partage d'écran en mode priorité à la fréquence d'images inverse cela, ce qui convient mieux au gameplay qu'à un tableur. La vidéo de la caméra protège toujours la fréquence d'images et laisse baisser la résolution, car un visage fluide passe mieux qu'un visage net mais saccadé.

Tout cela est déclenché par votre capacité d'envoi réelle à ce moment-là : un foyer qui sature la connexion montante, un Wi-Fi encombré ou un VPN peuvent le provoquer alors que votre GPU ne fait presque rien. Un stream qui démarre bien puis se dégrade au bout de quelques minutes, c'est presque toujours ça, et pas un défaut de l'encodeur.

Quand ça repasse en logiciel

Rien ne casse quand l'accélération matérielle n'est pas disponible. VP9 en logiciel gère le 1080p30 sans peine sur n'importe quel CPU récent, et sur les machines plus anciennes, passer le partage d'écran en 720p suffit généralement. Voici les raisons les plus courantes.

Un pilote NVIDIA trop ancien. NVENC a une API versionnée, et un pilote plus ancien que ce qu'attend la version du client est refusé d'emblée. Dans ce cas, la carte des Paramètres le signale et indique la branche de pilote minimale nécessaire, de 522.25 pour l'API NVENC 12.0 jusqu'à 610 pour la 13.1, au lieu de vous laisser en logiciel sans rien dire.

Pilotes VA-API manquants sous Linux. Si aucun encodeur n'apparaît, la carte des Paramètres indique le paquet adapté à votre CPU : intel-media-va-driver pour les Intel Broadwell et plus récents, i965-va-driver pour Haswell et plus anciens, et mesa-va-drivers pour AMD.

Un codec que le silicium n'a pas. La détection est optimiste chez Intel, où chaque GPU annonce d'abord VP9 et AV1, la vraie réponse n'apparaît donc qu'à l'ouverture de l'encodeur de test. Un échelon qui échoue pour une raison qui ne peut pas changer tant que l'application tourne, comme un pilote qui signale l'absence du bloc d'encodage, est écarté pour le reste de la session au lieu d'être retenté à chaque partage. Redémarrez GameVox pour relancer la détection après une mise à jour de pilote.

Vous êtes sur le client web. Les navigateurs encodent et décodent via WebCodecs, et c'est Chrome, Edge ou Firefox qui décide si cela passe par le GPU. Tout ce qui précède concerne l'application de bureau.