Aceleração de hardware

O vídeo da câmera e do compartilhamento de tela é codificado na GPU sempre que o hardware e o driver dão conta. Quando não dão, o GameVox passa para o software e segue em frente. Esta página explica como essa escolha é feita, o que a sua GPU consegue fazer e onde olhar quando a resposta não é a que você esperava.

Imagem borrada ou travando?

A codificação por hardware é só uma das coisas que definem como o seu vídeo fica. Outras duas pesam com mais frequência: o limite de bitrate definido para o seu grupo naquele servidor e a redução automática de qualidade que entra em ação quando a sua conexão não aguenta o stream. As duas estão explicadas em por que a imagem ainda pode ficar ruim.

Como ver o que você está usando

Configurações → Áudio e vídeo → Qualidade da transmissão é o caminho mais rápido. O menu Codec de vídeo marca cada opção como Hardware Accelerated, Software Encoding ou Unsupported e deixa em cinza as que a sua máquina não consegue usar de jeito nenhum. Logo abaixo, o cartão Aceleração de hardware mostra o backend de codificação que o app para desktop detectou na inicialização (NVENC, AMF, QSV, VAAPI ou VideoToolbox), os codecs que ele oferece e o backend de decodificação que vem junto. Essa detecção roda em segundo plano quando o app abre, então o cartão normalmente já está preenchido quando você abre as Configurações.

Para uma chamada em andamento, o registro de atividades do canal de voz é melhor. Quando alguém liga a câmera ou compartilha a tela, uma linha secundária esmaecida abaixo dessa entrada mostra o codec, o nome do encoder e se é hardware ou software, algo como AV1 · AV1 (FFmpeg-NVENC) · hardware. Trocas de encoder no meio do stream ganham uma entrada própria, então dá para ver quando um caminho por hardware desistiu e o que entrou no lugar.

Registro de atividades de um canal de voz do GameVox, com uma entrada de compartilhamento de tela mostrando AV1 · AV1 (FFmpeg-NVENC) · hardware logo abaixo

O arquivo de log do app para desktop tem o resto. Ele fica em %LOCALAPPDATA%\GameVox\logs\ no Windows, ~/Library/Application Support/GameVox/logs/ no macOS e ~/.gamevox/logs/ no Linux. Linhas que vale a pena procurar:

  • [HWEnc] Detected: o backend de codificação e quais codecs ele diz suportar
  • [NVENC] Function table loaded successfully (API X.Y) a versão da API NVENC que o seu driver NVIDIA oferece
  • Selected encoder: o que a escada escolheu para este compartilhamento
  • [FFmpegHW] Created o encoder foi aberto, com resolução e bitrate
  • [EncSelect] ... trial failed um encoder por hardware recusou o pedido e a escada passou para o próximo degrau
  • [ScreenShare-Win] Capture backend: WGC, DXGI ou BitBlt, o método de captura do Windows em uso

Como o codec é escolhido

O GameVox negocia AV1, VP9, H.264 e VP8. O HEVC não faz parte desse conjunto, então as tabelas abaixo não o listam, mesmo que a maioria dessas GPUs consiga codificá-lo.

Quem envia percorre uma escada de cima para baixo e para no primeiro degrau que o servidor ofereceu e que a GPU realmente consegue abrir. Essa segunda parte não é chute: o cliente cria um encoder descartável exatamente na resolução e no bitrate que vai usar, porque muitos drivers passam em 1080p e falham em 4K.

Windows

  1. AV1 na GPU: av1_nvenc, av1_amf ou av1_qsv
  2. VP9 na GPU: só vp9_qsv. NVIDIA e AMD nunca lançaram silício de codificação VP9, então esses sistemas pulam esse degrau por completo
  3. H.264 na GPU: h264_nvenc, h264_amf ou h264_qsv
  4. VP9 por software (libvpx), depois VP8, depois AV1 via libaom

Linux

  1. VAAPI AV1, depois que a verificação VAAPI em processo separado confirmar que funciona
  2. NVENC AV1, para máquinas NVIDIA sem a ponte nvidia-vaapi-driver
  3. VAAPI VP9
  4. VAAPI H.264, só para câmera e vídeo de DJ
  5. NVENC H.264
  6. libaom AV1, depois libvpx VP9, depois VP8

O compartilhamento de tela pula de propósito o degrau VAAPI H.264. A qualidade dos drivers com conteúdo de tela tem sido ruim o bastante na Intel e na AMD, com muitos blocos em cenas de muito movimento, que o VP9 por software dá uma imagem melhor. O NVENC H.264 continua ativo para o compartilhamento de tela, então uma máquina NVIDIA no Linux ainda usa H.264 por hardware em vez de cair direto para um encoder por software.

O VAAPI AV1 é o único degrau que não roda na base da confiança. O radeonsi padrão do Mesa tem histórico de travar na primeira tentativa de AV1, então o cliente pula o AV1 até que um processo de verificação separado tenha conseguido abri-lo pelo menos uma vez. Na primeira execução, isso pode significar NVENC ou AV1 por software no primeiro compartilhamento e VAAPI AV1 dali em diante.

macOS

A versão para macOS não inclui os encoders por hardware do FFmpeg. Codificação e decodificação passam pelo VideoToolbox dentro da pilha WebRTC do WebKit, o que dá H.264 acelerado, mas não AV1: a Apple nunca colocou um encoder AV1 em nenhum chip.

Mudando a escolha

O menu Codec de vídeo coloca a sua escolha no topo da escada em vez de forçá-la. Se você escolher AV1 numa GTX 1080, não há encoder AV1 para abrir, então a escada volta à ordem normal em vez de fazer o compartilhamento falhar. Automático é quase sempre a melhor opção.

Caminhos por plataforma

SOCodificaçãoDecodificaçãoFabricantes
Windows 10/11NVENC, AMF, Quick SyncD3D11VANVIDIA, AMD, Intel
LinuxVAAPI, NVENCVAAPI, depois NVDECAMD (Mesa), Intel (iHD), NVIDIA
macOSVideoToolbox via WebKitVideoToolbox via WebKitApple Silicon, Macs com Intel

No Linux, o decodificador tenta o VAAPI primeiro e cai para o NVDEC, então uma placa NVIDIA decodifica por hardware sem precisar da ponte nvidia-vaapi-driver instalada. Os quadros decodificados por hardware voltam como NV12 e são convertidos para RGBA na CPU, o que custa mais ou menos o mesmo que a etapa de conversão do próprio decodificador por software.

Codificação por GPU

Envio de vídeo: câmera e compartilhamento de tela.

Família de GPUH.264VP9AV1
NVIDIA, via NVENC
RTX 40 / 50 (Ada Lovelace, Blackwell)SimNãoSim
RTX 20 / 30, GTX 16 (Turing, Ampere)SimNãoNão
GTX 600 até GTX 10 (Kepler a Pascal)SimNãoNão
AMD, via AMF no Windows e VAAPI no Linux
RX 7000 / 9000, APUs Phoenix (RDNA 3, RDNA 4)SimNãoSim
RX 400 até RX 6000 (Polaris a RDNA 2)SimNãoNão
Intel, via Quick Sync no Windows e VAAPI no Linux
Arc séries A/B, Core Ultra (Alchemist, Battlemage, Meteor / Lunar / Arrow Lake)SimSimSim
Core de 7ª a 14ª geração (Kaby Lake a Raptor Lake)SimSimNão
Core de 4ª a 6ª geração (Haswell a Skylake)SimNãoNão
Apple, via VideoToolbox
Apple Silicon e Macs Intel com T2SimNãoNão

A Intel é a única fabricante que já colocou um encoder VP9 em peças de consumo, a partir do Kaby Lake. A codificação AV1 chegou com a Arc e as iGPUs Core Ultra na Intel, com a RDNA 3 na AMD e com a Ada Lovelace na NVIDIA. Qualquer coisa mais antiga codifica H.264 por hardware e todo o resto por software.

Decodificação por GPU

Recebimento de vídeo de todo mundo no canal.

Família de GPUH.264VP9AV1
NVIDIA, via NVDEC (D3D11VA no Windows, CUDA no Linux)
RTX 30 e mais novas (Ampere em diante)SimSimSim
GTX 10 / RTX 20 (Pascal, Turing)SimSimNão
GTX 900 (Maxwell 2)SimSó 8 bitsNão
GTX 600 / 700 (Kepler)SimNãoNão
AMD, via VCN (D3D11VA no Windows, VAAPI no Linux)
RX 6000 e mais novas (RDNA 2 em diante)SimSimSim
RX Vega, RX 5000 (RDNA 1)SimSimNão
RX 400 / 500 (Polaris)SimNãoNão
Intel, via Quick Sync (D3D11VA no Windows, VAAPI no Linux)
Arc, Core Ultra, 11ª geração e mais novas (Tiger Lake em diante)SimSimSim
Core de 7ª a 10ª geração (Kaby Lake a Comet Lake)SimSimNão
Core de 6ª geração (Skylake)SimSó 8 bitsNão
Core de 4ª / 5ª geração (Haswell, Broadwell)SimNãoNão
Apple, via VideoToolbox
Apple Silicon, M3 e mais novosSimSimSim
Apple Silicon, M1 e M2SimSimNão
Macs Intel com chip T2 (2018 em diante)SimNãoNão

Estas colunas descrevem o silício. Uma GPU que consegue decodificar um codec ainda precisa de um driver que o exponha, e uma máquina Linux sem o libva-drm decodifica por software, não importa o que o hardware suporte. O GameVox tenta primeiro a decodificação por hardware e troca para software já no primeiro quadro se o acelerador não inicializar.

Por que a imagem ainda pode ficar ruim

Um encoder por hardware numa GPU capaz ainda pode gerar um stream borrado ou travando, porque resolução e codec não são as únicas coisas em jogo. As duas causas mais comuns não têm nada a ver com as tabelas acima.

O seu grupo pode limitar o bitrate

Donos de servidor podem definir um limite de bitrate para um grupo, separado para compartilhamento de tela, câmera e microfone. O limite que vale na sua codificação é o menor entre o do nível do servidor e o do seu grupo, então um servidor Diamond ainda pode segurar um grupo em 2,5 Mbps de compartilhamento de tela. Os limites de compartilhamento de tela vão de 2,5 a 25 Mbps, os de câmera de 0,8 a 10 Mbps e os de microfone de 48 a 256 kbps.

Você está em exatamente um grupo por servidor, então só vale o limite desse grupo: se você mudar de grupo, o limite dele substitui o antigo. Um grupo sem limite definido deixa você sem teto. Donos de servidor não estão sujeitos aos próprios limites. Se um limite foi aplicado a um stream, o registro de atividades do canal avisa na mesma linha esmaecida que mostra o codec e o encoder, então esse registro é o jeito mais rápido de diferenciar um limite de grupo de um problema de encoder.

A qualidade cai sozinha quando falta banda

A qualidade que você escolhe é um teto, não uma promessa. Quando quem assiste ao seu stream começa a perder pacotes, o servidor mede isso e manda o seu cliente aliviar; o seu encoder é recriado com o bitrate menor em mais ou menos um segundo. Quando o congestionamento passa, o servidor tira o limite e o preset que você escolheu volta sozinho. Não precisa reiniciar nada.

O que cede primeiro depende do que você está enviando. Por padrão, o compartilhamento de tela protege a resolução, então texto e interface continuam nítidos e quem cai é a taxa de quadros. Mudar o compartilhamento de tela para o modo que prioriza a taxa de quadros inverte isso, o que combina mais com gameplay do que com planilha. O vídeo da câmera sempre protege a taxa de quadros e deixa a resolução cair, porque um rosto fluido fica melhor do que um rosto nítido e travando.

Isso é disparado pela sua capacidade real de upload naquele momento, então uma casa saturando o uplink, um Wi-Fi congestionado ou uma VPN podem causar isso enquanto a sua GPU fica quase parada. Um stream que começa bem e piora depois de alguns minutos quase sempre é isso, e não uma falha do encoder.

Quando ele volta para o software

Nada quebra quando a aceleração de hardware não está disponível. O VP9 por software aguenta 1080p30 tranquilo em qualquer CPU recente e, em máquinas mais antigas, baixar o compartilhamento de tela para 720p costuma bastar. Estes são os motivos mais comuns para isso acontecer.

Driver NVIDIA antigo demais. O NVENC tem uma API versionada, e um driver mais antigo do que a versão do cliente espera é recusado na hora. Quando isso acontece, o cartão nas Configurações avisa e diz qual a versão mínima do driver, de 522.25 para a API NVENC 12.0 até 610 para a 13.1, em vez de deixar você no software sem dizer nada.

Drivers VA-API faltando no Linux. Se nenhum encoder aparecer, o cartão nas Configurações indica o pacote para a sua CPU: intel-media-va-driver em Intel Broadwell ou mais nova, i965-va-driver em Haswell ou mais antiga e mesa-va-drivers em AMD.

Um codec que o silício não tem. A detecção é otimista na Intel, onde toda GPU diz de início que suporta VP9 e AV1, então a resposta real só aparece quando o encoder de teste é aberto. Um degrau que falha por um motivo que não muda com o app aberto, como o driver informar que o bloco de codificação não existe, é descartado pelo resto da sessão em vez de ser tentado de novo a cada compartilhamento. Reinicie o GameVox para detectar de novo depois de atualizar o driver.

Você está no cliente web. Os navegadores codificam e decodificam via WebCodecs, e se isso vai para a GPU ou não depende do Chrome, do Edge ou do Firefox. Tudo acima se refere ao app para desktop.