Hardwarebeschleunigung

So siehst du, was du nutzt

Einstellungen → Audio & Video → Streaming-Qualität ist der schnellste Weg. Das Dropdown Video-Codec kennzeichnet jede Option als Hardware Accelerated, Software Encoding oder Unsupported und graut die aus, die dein Rechner gar nicht kann. Darunter zeigt die Karte Hardwarebeschleunigung das Encoder-Backend, das die Desktop-App beim Start erkannt hat (NVENC, AMF, QSV, VAAPI oder VideoToolbox), die Codecs, die es anbietet, und das zugehörige Decoder-Backend. Diese Prüfung läuft beim Start im Hintergrund, die Karte ist also normalerweise schon ausgefüllt, wenn du die Einstellungen öffnest.

Bei einem laufenden Call ist das Aktivitätsprotokoll des Sprachkanals besser. Wenn jemand die Kamera oder Bildschirmfreigabe startet, zeigt eine abgedunkelte Unterzeile unter diesem Eintrag den Codec, den Encoder-Namen und ob Hardware oder Software im Spiel ist, etwa AV1 · AV1 (FFmpeg-NVENC) · hardware. Encoder-Wechsel mitten im Stream bekommen einen eigenen Eintrag, so siehst du, wann ein Hardware-Weg aufgegeben hat und was ihn ersetzt hat.

Den Rest findest du in der Logdatei der Desktop-App. Sie liegt unter %LOCALAPPDATA%\GameVox\logs\ auf Windows, ~/Library/Application Support/GameVox/logs/ auf macOS und ~/.gamevox/logs/ auf Linux. Nach diesen Zeilen lohnt sich die Suche:

• [HWEnc] Detected: das Encoder-Backend und welche Codecs es angeblich kann
• [NVENC] Function table loaded successfully (API X.Y) die NVENC-API-Version, die dein NVIDIA-Treiber bereitstellt
• Selected encoder: worauf sich die Leiter für diese Freigabe festgelegt hat
• [FFmpegHW] Created der Encoder wurde geöffnet, mit Auflösung und Bitrate
• [EncSelect] ... trial failed ein Hardware-Encoder hat die Anfrage abgelehnt und die Leiter ist weitergegangen
• [ScreenShare-Win] Capture backend: WGC, DXGI oder BitBlt, die aktive Aufnahmemethode unter Windows

Wie ein Codec ausgewählt wird

GameVox handelt AV1, VP9, H.264 und VP8 aus. HEVC gehört nicht dazu, deshalb fehlt es in den Tabellen unten, obwohl die meisten dieser GPUs es kodieren können.

Der Sender geht eine Leiter von oben nach unten durch und bleibt auf der ersten Stufe stehen, die der Server angeboten hat und die die GPU tatsächlich öffnet. Der zweite Teil ist keine Vermutung: Der Client baut einen Wegwerf-Encoder mit genau der Auflösung und Bitrate, die er gleich nutzen will, denn viele Treiber schaffen 1080p und scheitern bei 4K.

Windows

1. AV1 auf der GPU: av1_nvenc, av1_amf oder av1_qsv
2. VP9 auf der GPU: nur vp9_qsv. NVIDIA und AMD haben nie VP9-Encoding in Silizium ausgeliefert, diese Systeme überspringen die Stufe also komplett
3. H.264 auf der GPU: h264_nvenc, h264_amf oder h264_qsv
4. VP9 in Software (libvpx), dann VP8, dann AV1 über libaom

Linux

1. VAAPI AV1, sobald der VAAPI-Test in einem separaten Prozess bestätigt hat, dass es funktioniert
2. NVENC AV1, für NVIDIA-Rechner ohne die nvidia-vaapi-driver-Brücke
3. VAAPI VP9
4. VAAPI H.264, nur für Kamera und DJ-Video
5. NVENC H.264
6. libaom AV1, dann libvpx VP9, dann VP8

Die Bildschirmfreigabe überspringt die Stufe VAAPI H.264 absichtlich. Die Treiberqualität bei Bildschirminhalten war auf Intel und AMD so schlecht, mit starker Blockbildung bei schnellen Bewegungen, dass Software-VP9 das bessere Bild liefert. NVENC H.264 bleibt für die Bildschirmfreigabe aktiv, ein NVIDIA-Rechner unter Linux bekommt also weiterhin Hardware-H.264, statt bis auf einen Software-Encoder abzurutschen.

VAAPI AV1 ist die einzige Stufe, die nicht auf Vertrauensbasis läuft. Das Standard-Mesa-radeonsi hat die Angewohnheit, beim ersten AV1-Versuch hängen zu bleiben, deshalb überspringt der Client AV1, bis ein separater Testprozess es mindestens einmal erfolgreich geöffnet hat. Beim ersten Start kann das NVENC oder Software-AV1 für die erste Freigabe bedeuten und ab dann VAAPI AV1.

macOS

Der macOS-Build enthält die FFmpeg-Hardware-Encoder gar nicht. Encoding und Decoding laufen beide über VideoToolbox im WebRTC-Stack von WebKit. Das bringt dir beschleunigtes H.264, aber kein AV1: Apple hat noch in keinen Chip einen AV1-Encoder eingebaut.

Die Auswahl überschreiben

Das Dropdown Video-Codec setzt deine Wahl an die Spitze der Leiter, statt sie zu erzwingen. Wählst du AV1 auf einer GTX 1080, gibt es keinen AV1-Encoder zum Öffnen, also läuft die Leiter in ihrer normalen Reihenfolge weiter, statt die Freigabe scheitern zu lassen. Automatisch ist fast immer die richtige Einstellung.

Wege je Plattform

Unter Linux probiert der Decoder zuerst VAAPI und fällt dann auf NVDEC zurück, eine NVIDIA-Karte dekodiert also auch ohne installierte nvidia-vaapi-driver-Brücke in Hardware. Hardware-dekodierte Frames kommen als NV12 zurück und werden auf der CPU nach RGBA konvertiert, was ungefähr so viel kostet wie der Konvertierungsschritt des Software-Decoders selbst.

Encoding nach GPU

Video senden: Kamera und Bildschirmfreigabe.

Intel ist der einzige Hersteller, der je einen VP9-Encoder in Consumer-Chips verbaut hat, beginnend mit Kaby Lake. AV1-Encoding kam bei Intel mit Arc und den Core-Ultra-iGPUs, bei AMD mit RDNA 3 und bei NVIDIA mit Ada Lovelace. Alles Ältere kodiert H.264 in Hardware und alles andere in Software.

Decoding nach GPU

Video von allen anderen im Kanal empfangen.

Diese Spalten beschreiben das Silizium. Eine GPU, die einen Codec dekodieren kann, braucht trotzdem einen Treiber, der ihn bereitstellt, und ein Linux-Rechner ohne libva-drm dekodiert in Software, egal was die Hardware kann. GameVox versucht zuerst Hardware-Decoding und wechselt schon beim ersten Frame auf Software, wenn sich der Beschleuniger nicht initialisieren lässt.

Warum das Bild trotzdem schlecht aussehen kann

Auch ein Hardware-Encoder auf einer starken GPU kann einen unscharfen oder ruckeligen Stream liefern, denn Auflösung und Codec sind nicht die einzigen Faktoren. Die zwei häufigsten Ursachen haben nichts mit den Tabellen oben zu tun.

Deine Gruppe kann die Bitrate deckeln

Serverbesitzer können für eine Gruppe eine Bitrate-Obergrenze festlegen, getrennt für Bildschirmfreigabe, Kamera und Mikrofon. Die Grenze, mit der du tatsächlich kodierst, ist der niedrigere Wert aus Server-Stufe und Gruppenlimit, ein Diamond-Server kann eine Gruppe also trotzdem auf 2,5 Mbps Bildschirmfreigabe begrenzen. Die Grenzen reichen bei der Bildschirmfreigabe von 2,5 bis 25 Mbps, bei der Kamera von 0,8 bis 10 Mbps und beim Mikrofon von 48 bis 256 kbps.

Du bist auf jedem Server in genau einer Gruppe, es gilt also immer nur die Grenze dieser einen Gruppe: Wechselst du in eine andere Gruppe, ersetzt deren Grenze die alte. Eine Gruppe ohne festgelegte Grenze lässt dich ungedeckelt. Serverbesitzer unterliegen ihren eigenen Limits nicht. Wurde ein Limit auf einen Stream angewendet, steht das im Aktivitätsprotokoll des Kanals in derselben abgedunkelten Unterzeile wie Codec und Encoder. Dieses Protokoll ist also der schnellste Weg, ein Gruppenlimit von einem Encoder-Problem zu unterscheiden.

Es skaliert von selbst herunter, wenn die Bandbreite knapp wird

Die gewählte Qualität ist eine Obergrenze, kein Versprechen. Wenn Zuschauer deines Streams Pakete verlieren, misst der Server das und sagt deinem Client, dass er zurückschalten soll; dein Encoder wird innerhalb von etwa einer Sekunde mit der niedrigeren Bitrate neu aufgebaut. Sobald der Stau vorbei ist, hebt der Server das Limit auf und dein gewähltes Preset kommt von selbst zurück. Du musst nichts neu starten.

Was zuerst nachgibt, hängt davon ab, was du sendest. Die Bildschirmfreigabe schützt standardmäßig die Auflösung, Text und UI bleiben also scharf und stattdessen sinkt die Framerate. Stellst du die Bildschirmfreigabe auf den Modus „Framerate zuerst“, kehrt sich das um, was besser zu Gameplay passt als zu einer Tabelle. Kameravideo schützt immer die Framerate und lässt die Auflösung sinken, weil ein flüssiges Gesicht besser rüberkommt als ein scharfes, ruckelndes.

Ausgelöst wird das durch deine tatsächliche Upload-Kapazität in diesem Moment. Ein Haushalt, der den Upload auslastet, ein überlastetes WLAN oder ein VPN können es also verursachen, während deine GPU fast nichts zu tun hat. Ein Stream, der gut startet und nach ein paar Minuten schlechter wird, hat fast immer diese Ursache und keinen Encoder-Fehler.

Wenn auf Software zurückgefallen wird

Es geht nichts kaputt, wenn keine Hardwarebeschleunigung verfügbar ist. Software-VP9 schafft 1080p30 locker auf jeder aktuellen CPU, und auf älteren Rechnern reicht es meist, die Bildschirmfreigabe auf 720p zu senken. Das sind die häufigsten Gründe dafür.

Ein zu alter NVIDIA-Treiber. NVENC hat eine versionierte API, und ein Treiber, der älter ist als der Build des Clients erwartet, wird direkt abgelehnt. In dem Fall sagt die Karte in den Einstellungen das auch und nennt den Mindest-Treiberzweig, den du brauchst, von 522.25 für NVENC API 12.0 bis 610 für 13.1, statt dich still auf Software laufen zu lassen.

Fehlende VA-API-Treiber unter Linux. Wenn gar kein Encoder auftaucht, nennt die Karte in den Einstellungen das Paket für deine CPU: intel-media-va-driver für Intel ab Broadwell, i965-va-driver für Haswell und älter und mesa-va-drivers für AMD.

Ein Codec, den das Silizium nicht hat. Die Erkennung ist bei Intel optimistisch, dort meldet jede GPU zunächst VP9 und AV1. Die echte Antwort zeigt sich erst, wenn der Test-Encoder geöffnet wird. Eine Stufe, die aus einem Grund scheitert, der sich während der Laufzeit nicht ändern kann, etwa weil der Treiber meldet, dass der Encode-Block fehlt, wird für den Rest der Sitzung gestrichen, statt bei jeder Freigabe erneut probiert zu werden. Starte GameVox nach einem Treiber-Update neu, damit neu geprüft wird.

Du nutzt den Web-Client. Browser kodieren und dekodieren über WebCodecs, und ob das auf der GPU landet, entscheiden Chrome, Edge oder Firefox. Alles oben bezieht sich auf die Desktop-App.