Repository navigation
Vcall 3.23.0
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.
