Hardware Acceleration

Paano i-check kung ano ang gamit mo

Ang Mga Setting → Audio at Video → Kalidad ng Streaming ang pinakamabilis na paraan. Nilalagyan ng Video Codec dropdown ng label ang bawat option bilang Hardware Accelerated, Software Encoding o Unsupported, at naka-gray out ang mga hindi talaga kaya ng machine mo. Sa ilalim nito, ipinapakita ng Hardware acceleration card ang encoder backend na na-probe ng desktop client pagka-start (NVENC, AMF, QSV, VAAPI o VideoToolbox), ang mga codec na inaalok nito, at ang kapares nitong decode backend. Tumatakbo ang probe na iyon sa background pagka-launch, kaya kadalasan may laman na ang card pagbukas mo ng Settings.

Para sa call na nangyayari na, mas maganda ang activity log ng voice channel. Kapag may nag-start ng camera o screen share, may dimmed na sub-line sa ilalim ng entry na iyon na nagsasabi ng codec, pangalan ng encoder, at kung hardware o software, halimbawa AV1 · AV1 (FFmpeg-NVENC) · hardware. May sariling entry ang mga encoder swap sa gitna ng stream, kaya makikita mo kung kailan sumuko ang hardware path at ano ang pumalit.

Nasa log file ng desktop app ang iba pa. Nasa %LOCALAPPDATA%\GameVox\logs\ ito sa Windows, ~/Library/Application Support/GameVox/logs/ sa macOS at ~/.gamevox/logs/ sa Linux. Mga linyang sulit hanapin:

• [HWEnc] Detected: ang encoder backend at kung aling mga codec ang sinasabi nitong kaya
• [NVENC] Function table loaded successfully (API X.Y) ang NVENC API version na ibinibigay ng NVIDIA driver mo
• Selected encoder: kung ano ang napili ng ladder para sa share na ito
• [FFmpegHW] Created nabuksan ang encoder, kasama ang resolution at bitrate
• [EncSelect] ... trial failed tinanggihan ng hardware encoder ang request at lumipat ang ladder sa susunod
• [ScreenShare-Win] Capture backend: WGC, DXGI o BitBlt, ang capture method na gamit sa Windows

Paano pinipili ang codec

Nagne-negotiate ang GameVox ng AV1, VP9, H.264 at VP8. Wala ang HEVC sa set na iyon, kaya hindi ito nakalista sa mga table sa ibaba kahit kaya itong i-encode ng karamihan sa mga GPU na ito.

Bumababa ang sender sa isang ladder mula taas hanggang baba at humihinto sa unang rung na inalok ng server at talagang mabubuksan ng GPU. Hindi hula ang pangalawang bahagi: gumagawa ang client ng pang-test na encoder sa eksaktong resolution at bitrate na gagamitin nito, dahil maraming driver ang pumapasa sa 1080p pero bumabagsak sa 4K.

Windows

1. AV1 sa GPU: av1_nvenc, av1_amf o av1_qsv
2. VP9 sa GPU: vp9_qsv lang. Hindi kailanman naglabas ang NVIDIA at AMD ng VP9 encode silicon, kaya nilalaktawan ng mga system na iyon ang rung na ito
3. H.264 sa GPU: h264_nvenc, h264_amf o h264_qsv
4. VP9 sa software (libvpx), tapos VP8, tapos AV1 gamit ang libaom

Linux

1. VAAPI AV1, kapag nakumpirma na ng out-of-process na VAAPI probe na gumagana ito
2. NVENC AV1, para sa mga NVIDIA machine na walang nvidia-vaapi-driver bridge
3. VAAPI VP9
4. VAAPI H.264, para sa camera at DJ video lang
5. NVENC H.264
6. libaom AV1, tapos libvpx VP9, tapos VP8

Sadyang nilalaktawan ng screen share ang VAAPI H.264 rung. Sobrang pangit ng driver quality sa screen content sa Intel at AMD, grabe ang blocking kapag mabilis ang galaw, kaya mas maganda ang picture ng software VP9. Naka-enable pa rin ang NVENC H.264 para sa screen share, kaya may hardware H.264 pa rin ang NVIDIA machine sa Linux imbes na bumagsak hanggang software encoder.

Ang VAAPI AV1 lang ang rung na hindi basta pinagkakatiwalaan. May history ang stock Mesa radeonsi na mag-hang sa unang subok ng AV1, kaya nilalaktawan ng client ang AV1 hangga't hindi pa ito nabubuksan nang matagumpay ng hiwalay na probe process kahit isang beses. Sa unang launch, puwedeng NVENC o software AV1 ang gamit sa unang share at VAAPI AV1 na pagkatapos noon.

macOS

Walang kasamang FFmpeg hardware encoder ang macOS build. Dumadaan ang encode at decode sa VideoToolbox sa loob ng WebRTC stack ng WebKit, kaya may accelerated H.264 ka pero walang AV1: hindi kailanman naglagay ang Apple ng AV1 encoder sa kahit anong chip.

Pag-override sa pinili

Inilalagay ng Video Codec dropdown ang pinili mo sa pinakataas ng ladder imbes na pilitin ito. Kapag pinili mo ang AV1 sa GTX 1080, walang AV1 encoder na mabubuksan, kaya babalik ang ladder sa normal na order imbes na mag-fail ang share. Auto ang halos laging tamang setting.

Mga path bawat platform

Sa Linux, VAAPI muna ang sinusubukan ng decoder bago lumipat sa NVDEC, kaya nagde-decode sa hardware ang NVIDIA card kahit walang naka-install na nvidia-vaapi-driver bridge. Bumabalik bilang NV12 ang mga hardware-decoded frame at kino-convert sa RGBA sa CPU, na halos kasing-bigat lang ng sariling conversion step ng software decoder.

Encoding bawat GPU

Pagpapadala ng video: camera at screen share.

Intel lang ang vendor na naglagay ng VP9 encoder sa consumer parts, simula sa Kaby Lake. Dumating ang AV1 encode kasama ng Arc at Core Ultra iGPUs sa Intel, RDNA 3 sa AMD at Ada Lovelace sa NVIDIA. Lahat ng mas luma ay nag-e-encode ng H.264 sa hardware at lahat ng iba pa sa software.

Decoding bawat GPU

Pagtanggap ng video mula sa lahat ng iba sa channel.

Silicon ang inilalarawan ng mga column na ito. Kahit kayang mag-decode ng GPU ng isang codec, kailangan pa rin nito ng driver na nagbibigay nito, at ang Linux box na walang libva-drm ay nagde-decode sa software kahit ano pa ang suportado ng hardware. Hardware decode muna ang sinusubukan ng GameVox at lumilipat ito sa software sa unang frame pa lang kapag ayaw mag-initialize ng accelerator.

Bakit puwede pa ring pangit ang picture

Kahit hardware encoder sa malakas na GPU ay puwede pa ring maglabas ng malabo o putol-putol na stream, dahil hindi lang resolution at codec ang may epekto. Walang kinalaman sa mga table sa itaas ang dalawang pinakakaraniwang dahilan.

Puwedeng i-cap ng group mo ang bitrate

Puwedeng maglagay ang mga server owner ng bitrate ceiling sa isang group, hiwalay para sa screen share, camera at microphone. Ang ceiling na talagang gamit mo sa pag-encode ay kung alin ang mas mababa sa tier ng server at sa limit ng group mo, kaya kahit Diamond server ay puwedeng limitahan ang isang group sa 2.5 Mbps na screen share. Nasa 2.5 hanggang 25 Mbps ang ceiling ng screen share, 0.8 hanggang 10 Mbps ang camera, at 48 hanggang 256 kbps ang microphone.

Iisang group lang ang kinabibilangan mo bawat server, kaya ceiling lang ng group na iyon ang nag-a-apply: lumipat ka sa ibang group at ang ceiling nito ang papalit sa dati. Kapag walang naka-set na ceiling ang group, walang cap sa iyo. Hindi saklaw ng sarili nilang limits ang mga server owner. Kapag may cap na nag-apply sa isang stream, sinasabi ito ng activity log ng channel sa parehong dimmed na sub-line na nagpapakita ng codec at encoder, kaya iyon ang pinakamabilis na paraan para malaman kung group limit ba o problema sa encoder.

Kusa itong nagda-downscale kapag kulang ang bandwidth

Ceiling ang quality na pinili mo, hindi pangako. Kapag nagsimulang mawalan ng packets ang mga nanonood ng stream mo, sinusukat ito ng server at sinasabihan ang client mo na magbawas; nire-rebuild ang encoder mo sa mas mababang bitrate sa loob ng mga isang segundo. Kapag nawala na ang congestion, tinatanggal ng server ang limit at kusang babalik ang preset na pinili mo. Walang kailangang i-restart.

Kung ano ang unang bibigay ay depende sa pinapadala mo. By default, pinoprotektahan ng screen share ang resolution, kaya nananatiling malinaw ang text at UI at frame rate ang bumababa. Kapag inilipat mo ang screen share sa framerate-first mode, baligtad iyon, na mas bagay sa gameplay kaysa sa spreadsheet. Laging pinoprotektahan ng camera video ang frame rate at hinahayaang bumaba ang resolution, dahil mas maganda tingnan ang smooth na mukha kaysa sa malinaw pero putol-putol.

Ang nagti-trigger nito ay ang totoong upload capacity mo sa sandaling iyon, kaya puwede itong mangyari dahil sa bahay na puno ang uplink, siksikang Wi-Fi, o VPN habang halos idle ang GPU mo. Ang stream na maayos sa simula tapos pumapangit pagkalipas ng ilang minuto ay halos laging ito, hindi sira sa encoder.

Kapag bumabalik ito sa software

Walang masisira kapag walang hardware acceleration. Kayang-kaya ng software VP9 ang 1080p30 sa kahit anong bagong CPU, at sa mas lumang machine, kadalasan sapat na ang ibaba ang screen share sa 720p. Ito ang mga karaniwang dahilan kung bakit ito nangyayari.

Masyadong lumang NVIDIA driver. May versioned API ang NVENC, at tinatanggihan agad ang driver na mas luma kaysa inaasahan ng build ng client. Kapag nangyari iyon, sinasabi ito ng Settings card at binabanggit ang minimum na driver branch na kailangan mo, mula 522.25 para sa NVENC API 12.0 hanggang 610 para sa 13.1, imbes na tahimik kang iwan sa software.

Kulang na VA-API drivers sa Linux. Kung walang lumalabas na encoder, binabanggit ng Settings card ang package para sa CPU mo: intel-media-va-driver sa Broadwell at mas bagong Intel, i965-va-driver sa Haswell at mas luma, at mesa-va-drivers sa AMD.

Codec na wala sa silicon. Optimistic ang detection sa Intel, kung saan sinasabi ng bawat GPU sa simula na kaya nito ang VP9 at AV1, kaya lalabas lang ang totoong sagot kapag binuksan na ang test encoder. Ang rung na nagfe-fail dahil sa bagay na hindi magbabago habang tumatakbo ang app, gaya ng driver na nagsasabing wala ang encode block, ay tinatanggal para sa natitirang session imbes na subukan ulit sa bawat share. I-restart ang GameVox para mag-probe ulit pagkatapos mag-update ng driver.

Nasa web client ka. Nag-e-encode at nagde-decode ang mga browser gamit ang WebCodecs, at nasa Chrome, Edge o Firefox na kung sa GPU ito tatakbo. Tungkol sa desktop app ang lahat ng nasa itaas.