Skip to content

Vcall 3.23.0

Choose a tag to compare

@github-actions github-actions released this 07 Nov 23:06
c5f35e6

Vcall

Vcall 3.23.0: transmitir pela placa de vídeo, e a imagem que volta em segundos depois de uma queda de internet.

Transmitir pela placa de vídeo

Em Configurações › Transmissão dá para escolher por onde a tela e a câmera são codificadas:

Opção Para quê
Automático O Vcall escolhe: a placa de vídeo quando ela codifica, senão o processador.
Placa de vídeo Para jogar e transmitir ao mesmo tempo. O jogo pode ocupar o processador e a transmissão não engasga.
Processador Tudo pelo processador, em VP9.
Leve (VP8) Para PC fraco: o codec mais leve que o WebRTC tem, em até 720p. Também no navegador.

Com um jogo aberto, o codificador por software disputa o processador com ele. Medido em 1080p a 60 quadros por segundo, com 10 threads ocupadas fazendo o papel do jogo:

Codificador Com o processador ocupado
VP9 pelo processador 7,7 quadros por segundo
H.264 pelo processador (OpenH264) 22 quadros por segundo, em 360p
VP9 pela placa de vídeo 60 quadros por segundo, em 1080p

Em alguns Windows, o codificador da placa só aparece para o Vcall com o sandbox da GPU desligado. O sandbox é uma proteção do Chromium, o motor do Vcall. Quando é o caso, o Vcall avisa do risco e só desliga a proteção se você confirmar. Voltar para Automático ou Processador liga de novo, ao reabrir o app.

O Vcall usa o codificador que o Windows oferecer (Quick Sync, NVENC ou AMF). Num notebook com duas placas, costuma ser o da integrada: é um circuito separado, que não toca no processador nem na placa onde o jogo roda.

A imagem volta logo depois de uma queda

Depois de uma queda de internet, a resolução só crescia com 18 s seguidos de folga, sempre. Agora ela espera 4 s, e só espera mais (até 30 s) quando a internet está indo e voltando.

Com o processador apertado, o Vcall cortava quadros e banda a cada 2 s, até 15 quadros por segundo e 600 kbps. Ele não voltava mais, porque o Chrome continua marcando "processador" enquanto ele mesmo está segurando a imagem. Agora isso só conta como aperto quando os quadros realmente caem. Na Fluidez, quem reduz a imagem é o próprio Chrome, mantendo os quadros, e a banda nunca é cortada por causa do processador.

Medido pela internet de verdade. Quem transmitia estava em Teresina, com o processador ocupado; quem assistia estava nos EUA e teve a internet cortada para 2 Mbps por 15 s. Foram 4 rodadas de cada versão:

3.22 3.23
A imagem volta ao tamanho de antes da queda 26 s (numa rodada, nem em 40 s) 4,5 s
Só com o processador apertado 27 quadros por segundo, 328 engasgos por minuto 40 quadros por segundo, 42 engasgos por minuto

Acima de 60 quadros por segundo

A tela pode ir a 120 quadros por segundo na Fluidez, quando o monitor de quem transmite é de 120 Hz ou mais. A regra quase nunca liberava isso: ela media a banda pelo tamanho da janela capturada, e numa janela de 1440p nunca sobrava. Agora ela mede o que de fato sai, e só tenta os 120 com o codificador da placa: pelo processador não dá conta.

Num monitor de 60 Hz, a tela não passa de 60 quadros por segundo em app nenhum: o Windows só captura um quadro novo a cada atualização da tela.