Akceleracja sprzętowa

Obraz z kamery i udostępniania ekranu jest kodowany na karcie graficznej zawsze, gdy sprzęt i sterownik na to pozwalają. Gdy nie pozwalają, GameVox przełącza się na kodowanie programowe i działa dalej. Na tej stronie wyjaśniamy, jak zapada ta decyzja, co potrafi twoja karta graficzna i gdzie szukać, gdy wynik nie jest taki, jak się spodziewasz.

Obraz jest rozmyty albo się tnie?

Kodowanie sprzętowe to tylko jeden z czynników, od których zależy wygląd twojego wideo. Dwa inne dają o sobie znać częściej: limit bitrate ustawiony dla twojej grupy na tym serwerze i automatyczne obniżanie jakości, które włącza się, gdy twoje łącze nie wyrabia ze streamem. Oba opisujemy w sekcji dlaczego obraz nadal może wyglądać źle.

Jak sprawdzić, czego używasz

Ustawienia → Dźwięk i wideo → Jakość streamu to najszybsza odpowiedź. Lista Kodek wideo oznacza każdą opcję jako Hardware Accelerated, Software Encoding albo Unsupported i wyszarza te, których twój komputer w ogóle nie obsłuży. Pod nią karta Akceleracja sprzętowa pokazuje backend kodowania wykryty przez aplikację desktopową przy starcie (NVENC, AMF, QSV, VAAPI albo VideoToolbox), udostępniane przez niego kodeki i powiązany backend dekodowania. To sprawdzenie działa w tle przy uruchomieniu, więc zanim otworzysz Ustawienia, karta jest zwykle już wypełniona.

W trakcie trwającej rozmowy lepszy jest dziennik aktywności kanału głosowego. Gdy ktoś włącza kamerę albo udostępnia ekran, przyciemniona linia pod tym wpisem podaje kodek, nazwę enkodera i informację, czy to sprzęt, czy oprogramowanie, na przykład AV1 · AV1 (FFmpeg-NVENC) · hardware. Zmiany enkodera w trakcie streamu dostają własny wpis, więc widać, kiedy ścieżka sprzętowa się poddała i co ją zastąpiło.

Dziennik aktywności kanału głosowego GameVox z wpisem o udostępnianiu ekranu, pod którym widać AV1 · AV1 (FFmpeg-NVENC) · hardware

Resztę znajdziesz w pliku logu aplikacji desktopowej. Leży w %LOCALAPPDATA%\GameVox\logs\ na Windowsie, ~/Library/Application Support/GameVox/logs/ na macOS i ~/.gamevox/logs/ na Linuksie. Warto szukać tych linii:

  • [HWEnc] Detected: backend kodowania i kodeki, które deklaruje
  • [NVENC] Function table loaded successfully (API X.Y) wersja API NVENC udostępniana przez twój sterownik NVIDIA
  • Selected encoder: na czym zatrzymała się drabinka dla tego udostępniania
  • [FFmpegHW] Created enkoder się otworzył, z rozdzielczością i bitrate
  • [EncSelect] ... trial failed enkoder sprzętowy odrzucił żądanie i drabinka poszła dalej
  • [ScreenShare-Win] Capture backend: WGC, DXGI albo BitBlt, używana metoda przechwytywania w Windowsie

Jak wybierany jest kodek

GameVox negocjuje AV1, VP9, H.264 i VP8. HEVC nie należy do tego zestawu, więc nie ma go w tabelach poniżej, choć większość tych kart graficznych potrafi go kodować.

Nadawca schodzi po drabince od góry i zatrzymuje się na pierwszym szczeblu, który zaproponował serwer i który karta graficzna faktycznie otworzy. Ta druga część to nie zgadywanie: klient tworzy jednorazowy enkoder w dokładnie tej rozdzielczości i z tym bitrate, których zaraz użyje, bo sporo sterowników radzi sobie w 1080p i wykłada się na 4K.

Windows

  1. AV1 na GPU: av1_nvenc, av1_amf albo av1_qsv
  2. VP9 na GPU: tylko vp9_qsv. NVIDIA i AMD nigdy nie wypuściły sprzętowego kodowania VP9, więc te systemy całkowicie pomijają ten szczebel
  3. H.264 na GPU: h264_nvenc, h264_amf albo h264_qsv
  4. VP9 programowo (libvpx), potem VP8, potem AV1 przez libaom

Linux

  1. VAAPI AV1, gdy test VAAPI w osobnym procesie potwierdzi, że działa
  2. NVENC AV1, dla komputerów z NVIDIA bez mostka nvidia-vaapi-driver
  3. VAAPI VP9
  4. VAAPI H.264, tylko dla kamery i wideo DJ-a
  5. NVENC H.264
  6. libaom AV1, potem libvpx VP9, potem VP8

Udostępnianie ekranu celowo pomija szczebel VAAPI H.264. Jakość sterowników przy treściach z ekranu była na Intelu i AMD na tyle zła, z mocnymi artefaktami blokowymi przy szybkim ruchu, że programowe VP9 daje lepszy obraz. NVENC H.264 pozostaje włączone dla udostępniania ekranu, więc komputer z NVIDIA na Linuksie nadal dostaje sprzętowe H.264, zamiast spaść aż do enkodera programowego.

VAAPI AV1 to jedyny szczebel, który nie działa na słowo honoru. Standardowy radeonsi z Mesy ma w zwyczaju zawieszać się przy pierwszej próbie AV1, więc klient pomija AV1, dopóki osobny proces testowy choć raz nie otworzy go z powodzeniem. Przy pierwszym uruchomieniu może to oznaczać NVENC albo programowe AV1 przy pierwszym udostępnianiu i VAAPI AV1 od tego momentu.

macOS

Wersja na macOS w ogóle nie zawiera sprzętowych enkoderów FFmpeg. Kodowanie i dekodowanie idą przez VideoToolbox wewnątrz stosu WebRTC w WebKit, co daje przyspieszone H.264, ale nie AV1: Apple nigdy nie umieściło enkodera AV1 w żadnym chipie.

Ręczna zmiana wyboru

Lista Kodek wideo przesuwa twój wybór na szczyt drabinki, zamiast go wymuszać. Wybierz AV1 na GTX 1080, a nie będzie czego otworzyć, więc drabinka wróci do normalnej kolejności, zamiast wywalić udostępnianie. Automatycznie to prawie zawsze najlepsze ustawienie.

Ścieżki na poszczególnych platformach

SystemKodowanieDekodowanieProducenci
Windows 10/11NVENC, AMF, Quick SyncD3D11VANVIDIA, AMD, Intel
LinuxVAAPI, NVENCVAAPI, potem NVDECAMD (Mesa), Intel (iHD), NVIDIA
macOSVideoToolbox przez WebKitVideoToolbox przez WebKitApple Silicon, Maki z Intelem

Na Linuksie dekoder najpierw próbuje VAAPI, a potem przechodzi na NVDEC, więc karta NVIDIA dekoduje sprzętowo nawet bez zainstalowanego mostka nvidia-vaapi-driver. Klatki zdekodowane sprzętowo wracają jako NV12 i są konwertowane do RGBA na procesorze, co kosztuje mniej więcej tyle, co własny krok konwersji dekodera programowego.

Kodowanie według GPU

Wysyłanie wideo: kamera i udostępnianie ekranu.

Rodzina GPUH.264VP9AV1
NVIDIA, przez NVENC
RTX 40 / 50 (Ada Lovelace, Blackwell)TakNieTak
RTX 20 / 30, GTX 16 (Turing, Ampere)TakNieNie
Od GTX 600 do GTX 10 (od Keplera do Pascala)TakNieNie
AMD, przez AMF na Windowsie i VAAPI na Linuksie
RX 7000 / 9000, APU Phoenix (RDNA 3, RDNA 4)TakNieTak
Od RX 400 do RX 6000 (od Polarisa do RDNA 2)TakNieNie
Intel, przez Quick Sync na Windowsie i VAAPI na Linuksie
Arc serii A/B, Core Ultra (Alchemist, Battlemage, Meteor / Lunar / Arrow Lake)TakTakTak
Core od 7. do 14. generacji (od Kaby Lake do Raptor Lake)TakTakNie
Core od 4. do 6. generacji (od Haswella do Skylake)TakNieNie
Apple, przez VideoToolbox
Apple Silicon i Maki z Intelem i chipem T2TakNieNie

Intel to jedyny producent, który kiedykolwiek wbudował enkoder VP9 w konsumenckie układy, zaczynając od Kaby Lake. Kodowanie AV1 pojawiło się u Intela z Arc i zintegrowanymi GPU Core Ultra, u AMD z RDNA 3, a u NVIDII z Ada Lovelace. Wszystko starsze koduje sprzętowo H.264, a całą resztę programowo.

Dekodowanie według GPU

Odbieranie wideo od wszystkich pozostałych osób na kanale.

Rodzina GPUH.264VP9AV1
NVIDIA, przez NVDEC (D3D11VA na Windowsie, CUDA na Linuksie)
RTX 30 i nowsze (od Ampere wzwyż)TakTakTak
GTX 10 / RTX 20 (Pascal, Turing)TakTakNie
GTX 900 (Maxwell 2)TakTylko 8 bitówNie
GTX 600 / 700 (Kepler)TakNieNie
AMD, przez VCN (D3D11VA na Windowsie, VAAPI na Linuksie)
RX 6000 i nowsze (od RDNA 2 wzwyż)TakTakTak
RX Vega, RX 5000 (RDNA 1)TakTakNie
RX 400 / 500 (Polaris)TakNieNie
Intel, przez Quick Sync (D3D11VA na Windowsie, VAAPI na Linuksie)
Arc, Core Ultra, 11. generacja i nowsze (od Tiger Lake wzwyż)TakTakTak
Core od 7. do 10. generacji (od Kaby Lake do Comet Lake)TakTakNie
Core 6. generacji (Skylake)TakTylko 8 bitówNie
Core 4. / 5. generacji (Haswell, Broadwell)TakNieNie
Apple, przez VideoToolbox
Apple Silicon, M3 i nowszeTakTakTak
Apple Silicon, M1 i M2TakTakNie
Maki z Intelem i chipem T2 (od 2018 roku)TakNieNie

Te kolumny opisują sam krzem. Karta graficzna, która potrafi dekodować dany kodek, nadal potrzebuje sterownika, który go udostępnia, a linuksowy komputer bez libva-drm dekoduje programowo bez względu na to, co obsługuje sprzęt. GameVox najpierw próbuje dekodowania sprzętowego i przełącza się na programowe już przy pierwszej klatce, jeśli akcelerator się nie zainicjuje.

Dlaczego obraz nadal może wyglądać źle

Enkoder sprzętowy na mocnej karcie graficznej nadal może dawać rozmyty albo przycinający się stream, bo rozdzielczość i kodek to nie jedyne, co ma znaczenie. Dwie najczęstsze przyczyny nie mają nic wspólnego z tabelami powyżej.

Twoja grupa może mieć limit bitrate

Właściciele serwerów mogą ustawić dla grupy górny limit bitrate, osobno dla udostępniania ekranu, kamery i mikrofonu. Limit, z jakim faktycznie kodujesz, to niższa z dwóch wartości: limitu poziomu serwera i limitu twojej grupy, więc nawet serwer Diamond może ograniczyć daną grupę do 2,5 Mb/s przy udostępnianiu ekranu. Limity udostępniania ekranu wynoszą od 2,5 do 25 Mb/s, kamery od 0,8 do 10 Mb/s, a mikrofonu od 48 do 256 kb/s.

Na każdym serwerze należysz do dokładnie jednej grupy, więc zawsze obowiązuje limit tylko tej jednej grupy: przejdź do innej grupy, a jej limit zastąpi poprzedni. Grupa bez ustawionego limitu nie ogranicza cię wcale. Właścicieli serwerów nie obowiązują ich własne limity. Jeśli limit został zastosowany do streamu, dziennik aktywności kanału informuje o tym w tej samej przyciemnionej linii, w której jest kodek i enkoder, więc ten dziennik najszybciej pozwala odróżnić limit grupy od problemu z enkoderem.

Jakość sama spada, gdy brakuje przepustowości

Wybrana jakość to górna granica, a nie obietnica. Gdy widzowie twojego streamu zaczynają gubić pakiety, serwer to mierzy i każe twojemu klientowi zwolnić; enkoder jest odbudowywany z niższym bitrate w mniej więcej sekundę. Gdy przeciążenie minie, serwer znosi limit, a wybrany przez ciebie preset wraca sam. Nic nie trzeba restartować.

To, co ustępuje najpierw, zależy od tego, co wysyłasz. Udostępnianie ekranu domyślnie chroni rozdzielczość, więc tekst i interfejs zostają ostre, a spada liczba klatek. Przełączenie udostępniania ekranu w tryb z priorytetem płynności odwraca to, co lepiej pasuje do rozgrywki niż do arkusza kalkulacyjnego. Obraz z kamery zawsze chroni liczbę klatek i pozwala spaść rozdzielczości, bo płynna twarz wygląda lepiej niż ostra, ale przycinająca się.

Wyzwala to twoja rzeczywista przepustowość wysyłania w danej chwili, więc może to spowodować domownik zapychający łącze, zatłoczone Wi-Fi albo VPN, podczas gdy twoja karta graficzna prawie nic nie robi. Stream, który wygląda dobrze, a po kilku minutach się pogarsza, to prawie zawsze ten przypadek, a nie awaria enkodera.

Kiedy następuje powrót do kodowania programowego

Nic się nie psuje, gdy akceleracja sprzętowa jest niedostępna. Programowe VP9 spokojnie radzi sobie z 1080p30 na każdym współczesnym procesorze, a na starszych komputerach zwykle wystarczy zejść z udostępnianiem ekranu do 720p. Oto najczęstsze powody.

Zbyt stary sterownik NVIDIA. NVENC ma wersjonowane API, a sterownik starszy, niż oczekuje wersja klienta, jest od razu odrzucany. Wtedy karta w Ustawieniach wprost o tym informuje i podaje minimalną gałąź sterownika, jakiej potrzebujesz, od 522.25 dla NVENC API 12.0 do 610 dla 13.1, zamiast po cichu zostawić cię na kodowaniu programowym.

Brak sterowników VA-API na Linuksie. Jeśli nie pojawia się żaden enkoder, karta w Ustawieniach podaje pakiet dla twojego procesora: intel-media-va-driver dla Intela od Broadwella wzwyż, i965-va-driver dla Haswella i starszych oraz mesa-va-drivers dla AMD.

Kodek, którego nie ma w krzemie. Wykrywanie na Intelu jest optymistyczne, bo każda karta najpierw deklaruje VP9 i AV1, więc prawdziwa odpowiedź pojawia się dopiero przy otwarciu enkodera testowego. Szczebel, który zawodzi z powodu, który nie może się zmienić w trakcie działania aplikacji, na przykład gdy sterownik zgłasza brak bloku kodowania, zostaje pominięty do końca sesji, zamiast być ponawiany przy każdym udostępnianiu. Po aktualizacji sterownika uruchom GameVox ponownie, żeby wykrywanie przeszło od nowa.

Korzystasz z klienta webowego. Przeglądarki kodują i dekodują przez WebCodecs, a to, czy trafi to na kartę graficzną, zależy od Chrome, Edge albo Firefoksa. Wszystko powyżej dotyczy aplikacji desktopowej.