Vcall 3.24.0

Vcall 3.24.0: assistir uma transmissão só se quiser, como no Discord, e a tela compartilhada em tela cheia no celular.

Assistir só se quiser

Quando alguém compartilha a tela, os outros não recebem a transmissão na hora. Aparece um ladrilho "Fulano está transmitindo" com o botão Assistir, e um aviso com o mesmo botão. A tela só chega depois do clique. Quem está assistindo tem o botão Parar de assistir (o olho cortado, no canto do ladrilho) e volta ao convite quando quiser.

Quem não assiste não recebe nada da tela, nem o som dela:

Caminho da tela	Para quem não assiste
Direto, de pessoa para pessoa	Quem transmite desliga o envio da tela e do som da tela para essa pessoa. É uma cópia a menos para codificar.
Pelo relé (um terceiro repassando)	Quem repassa não manda a tela para essa pessoa.
Pelo servidor de mídia (sala de 3 ou mais pelo app de mesa)	A pessoa nem entra no servidor de mídia daquela transmissão.

Assim, quem não está assistindo economiza internet e processador, e quem transmite gasta menos subida. Quando a pessoa para de transmitir, todo mundo volta ao convite na próxima transmissão.

Tela cheia no celular

Ao assistir pelo celular (navegador ou app Android), a tela compartilhada mostra dois botões: tela cheia e parar de assistir. A tela cheia gira o celular para deitado quando a imagem é deitada e devolve o giro ao sair. No iPhone, a tela cheia é a do próprio player do sistema.

No app Android, a tela cheia precisa do app novo, que se atualiza sozinho. O botão voltar sai só da tela cheia: a chamada continua.

App Android: entrar sem câmera e sem microfone

Quem recusava a câmera e o microfone e entrava na chamada via o app fechar sozinho. O serviço "Chamada em andamento" era iniciado sem ter o que manter, e o Android encerrava o app. Agora ele só começa com a câmera ou o microfone liberados, inclusive quando a permissão é dada no meio da chamada.

Vcall 3.23.1

Vcall 3.23.1: a transmissão de jogo para de perder quadros com a placa de vídeo ligada.

O que travava

Mesmo com Configurações › Transmissão › Placa de vídeo, a tela de um jogo saía a 30–50 quadros por segundo, às vezes menos, com "Limitado por: processador" no painel. Medimos no app de mesa, capturando uma janela de verdade a 60 quadros por segundo, com o processador ocupado como num jogo. Havia duas causas:

• A placa de vídeo caía para o processador sem avisar. O codificador da placa recusa imagens com largura ou altura ímpar. A Fluidez captura no tamanho da janela (uma janela de 1541×875, por exemplo), e a imagem enviada saía ímpar. Aí o WebRTC passava para o codificador por software, que disputa o processador com o jogo: de 27 a 192 ms por quadro, contra 13 a 17 na placa.
• O jogo tirava a vez da captura. Com o jogo em primeiro plano, o Windows deixava a captura do Vcall esperando, e ela caía para 19 quadros por segundo.

O que mudou

• A imagem enviada sai sempre com largura e altura pares. A escala cresce uma fração de pixel quando precisa, e a placa não cai mais. As resoluções comuns (1920×1080, 1280×720) ficam como estão.
• Prioridade de transmissão no Windows. Ao começar a compartilhar, o Vcall sobe a própria prioridade, como o OBS recomenda para transmitir jogo: alta para a captura e para a placa de vídeo, acima do normal para o resto.
• Se a placa cair mesmo assim, ela volta. O Vcall recria o codificador, que tenta a placa primeiro. A espera entre as tentativas vai crescendo (10 s, 20 s… até 2 min), para não ficar em laço.

Medido

Mesma janela de 1541×875 a 60 quadros por segundo, com 6 threads ocupando o processador, como um jogo:

	3.23.0	3.23.1
Quadros enviados por segundo	9 a 32	53 a 59
Codificador	caía para o processador	a placa o tempo todo
Imagem congelada	0,6 a 2,7 s	0 s

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.

Vcall 3.22.0

Vcall 3.22.0: a tela compartilhada chega mais fluida e mais nítida pela internet, mesmo em computador sem codificador de vídeo na placa.

Medido pela internet de verdade

Desta vez quem assistiu não estava na mesma casa nem numa rede simulada. Quem transmitia era um notebook em Teresina, numa fibra comum por Wi-Fi. Quem assistia eram máquinas na Virgínia (EUA), em Windows e Linux, pelo link público da sala e pelo navegador, com 170 ms de ida e volta.

O conteúdo foi um vídeo 1080p a 60 quadros por segundo, com muito movimento, e o número de cada quadro gravado num código de barras. Assim quem assiste sabe quais quadros chegaram, quais se perderam e quão fiel cada um ficou ao original (PSNR). Foram 4 rodadas de 60 s por versão e por modo.

Vídeo compartilhado na Nitidez (o modo padrão)	3.21	3.22
Segundos que passaram fluidos	63%	92%
Quadros que nunca chegaram	9,6%	1,6%
Quadros novos por segundo	53,9	58,7
Nitidez (PSNR)	30,9 dB	32,0 dB

Vídeo compartilhado na Fluidez	3.21	3.22
Segundos que passaram fluidos	85%	92%
Quadros que nunca chegaram	4,6%	1,6%
Resolução	720p	1080p
Nitidez (PSNR)	31,0 dB	31,9 dB
Quadros-chave sem ninguém pedir, em 52 s	36	1

"Fluido" quer dizer um segundo com 54 quadros novos ou mais e nenhum buraco acima de 50 ms. A internet não era o gargalo: a subida da casa era de ~75 Mbps.

O que travava

• Jogo no modo padrão. O painel começa na Nitidez, que segura a resolução e joga quadros fora quando aperta. Ele só passava sozinho para a Fluidez quando a janela tinha nome de player (YouTube, Twitch…), e o nome de um jogo não diz nada.
• H.264 por software. Na Fluidez, sem codificador na placa de vídeo, saía o OpenH264, que roda numa thread só. Ele punha um quadro-chave a cada troca de cena: 36 em 52 s de vídeo, cada um uma rajada na rede. Além disso, o Chrome não usa correção de perda (ULPFEC) no H.264 junto com a retransmissão.
• Começo pequeno. Toda transmissão começa com a conexão estimando ~1,5 Mbps, e a imagem encolhia na primeira leitura. A regra de só crescer com 18 s de folga, feita para evitar vaivém, deixava a tela em 360p–540p por 21–24 s, com a banda já sobrando.

O que mudou

• Fluidez automática. Se a imagem anda (24 quadros por segundo ou mais) e a Nitidez não acompanha, perdendo quadros ou gastando a banda toda, por 6 s seguidos, a tela passa para a Fluidez e avisa. Se você escolheu o modo à mão, nada muda, e dá para voltar à Nitidez no menu da tela.
• VP9 quando o H.264 sai por software. A Fluidez tenta o H.264, contando com a placa de vídeo. Se ele sai pelo processador, a tela troca para o VP9 sem renegociar a chamada. O VP9 usa várias threads, não põe quadro-chave a cada cena e tem correção de perda no navegador. O aparelho lembra disso por 7 dias.
• 1080p por software quando a máquina aguenta. Com 8 threads ou mais, a Fluidez por software tenta 1080p e desce para 720p se o processador ficar para trás. Antes era sempre 720p. Num i5 de 12ª geração, o VP9 sai em 1080p a 59–60 quadros por segundo, 9 ms por quadro.
• A imagem cresce junto com a banda no começo. Até o primeiro aperto de verdade (e por no máximo 30 s), a resolução sobe assim que a conexão deixa. Medido: 720p aos 6 s e 1080p aos 15 s, em vez de 360p–540p até os 24 s. Depois do primeiro aperto, vale de novo a espera de 18 s para crescer.

Para quem desenvolve

• O banco de medição pela internet ficou fora do repositório. Quem assiste roda no GitHub Actions e entra pelo túnel, e o medidor é baixado do banco a cada rodada.
• Uma armadilha: calcular o PSNR na mesma thread que anota a chegada dos quadros cria engasgos falsos. Numa máquina de 3–4 núcleos virtuais, confie nas estatísticas do próprio Chrome (totalInterFrameDelay, freezeCount).

Vcall 3.21.0

Vcall 3.21.0: a câmera chega mais nítida e congela menos em internet ruim.

O que travava

Medimos a câmera numa chamada a dois passando por uma internet de mentira, com banda, atraso e perda controlados, e comparamos cada quadro recebido com o original. Três coisas pesavam:

• Nenhuma correção de perda no vídeo. Cada pacote perdido fazia a imagem esperar a retransmissão, uma volta inteira pela rede. Na 4G isso dava ~3 s de imagem parada a cada 35 s; numa internet ruim, mais da metade do tempo.
• Codec que gasta banda. A câmera saía em VP8, o padrão do navegador. Na 4G a imagem caía para 480p.
• 60 quadros por segundo dividindo a banda. Com a mesma banda, 60 quadros dão metade dos bits a cada um. Na 4G a imagem a 60 caía para 535p e ficava borrada.

O que mudou

• Correção de perda (FlexFEC) entre apps de mesa. O aplicativo manda pacotes de correção junto com o vídeo, e quem recebe refaz o que se perdeu sem esperar a retransmissão. Vale quando as duas pessoas usam o app de mesa; com quem entra pelo navegador, nada muda.
• VP9 na câmera. A mesma imagem com uns 30 a 40% menos bits. Ele entra pela placa de vídeo quando ela tem, ou pelo processador com 4 núcleos ou mais, fora do celular, até 2 pessoas recebendo. Em salas maiores, sem VP9 na placa, a câmera continua em VP8, que pesa menos no processador.
• Câmera a 30 quadros por segundo, e 60 quando sobra banda. Numa chamada a dois, sem tela compartilhada e com câmera que capture a 60, ela sobe para 60 quando a conexão aguenta e volta para 30 na hora em que aperta. Se o processador não der conta dos 60, ela volta a 30 e só tenta de novo depois de 2 minutos.

Medido

Câmera em 720p, 2 pessoas, tempo com a imagem parada em 35 s (média de 2 a 5 rodadas), altura média da imagem e nitidez (PSNR, quanto maior, mais fiel ao original).

Internet de cada pessoa	3.20	3.21, entre apps de mesa	3.21, pelo navegador
Fibra (50 Mbps)	0,2 s · 674p · 37,5 dB	0 s · 720p · 38,9 dB	0 s · 720p · 38,7 dB
Casa (6 Mbps, 1% de perda)	0,4 s · 656p · 36,8 dB	0 s · 720p · 38,7 dB	0,5 s · 720p · 38,6 dB
4G (2,5 Mbps, 2% de perda)	2,7 s · 487p · 33,6 dB	1,0 s · 720p · 36,7 dB	2,3 s · 702p · 36,3 dB
Ruim (1 Mbps, 4% de perda)	18,5 s · 360p · 32,5 dB	13,1 s · 433p · 32,6 dB	21,1 s · 495p · 32,9 dB

Pelo navegador, a imagem fica mais nítida, mas a internet ruim continua travando tanto quanto antes: ali o que segura a imagem é a correção de perda, que só o app de mesa liga. Numa internet tão ruim quanto essa (8% de perda somando as duas pontas e ~400 ms de ida e volta), o vídeo ainda para por alguns segundos.

Para quem desenvolve

• npm run bench:video mede a câmera numa internet de mentira (--rede fibra|casa|4g|ruim, --pessoas, --trials para simular o app de mesa). Toda a mídia passa por um TURN e por um proxy que limita banda, fila, atraso e perda, e o PSNR é calculado quadro a quadro contra o vídeo original.

Vcall 3.20.0

Vcall 3.20.0: no Planning Poker, as subtarefas de cada US também recebem nota, e uma US grande demais vira subtarefas novas no GitHub sem sair da chamada.

Antes

As US vinham do GitHub Projects com as subtarefas, mas as subtarefas eram só para ler. Quando o time via que uma US estava grande demais, alguém abria o GitHub em outra janela, criava as sub-issues uma por uma e depois as importava de novo.

O que mudou

Subtarefas na mesa

• Na lista: cada sub-issue aberta da US entra logo abaixo dela, recuada, com o número da issue. As fechadas continuam só na aba Subtarefas.
• Na hora de votar: a subtarefa tem a própria votação, com descrição e critérios de aceite. Em cima aparece de qual US ela é.
• Depois de salvar: a mesa segue para o próximo item sem nota da lista. Ao salvar a US, a próxima é a primeira subtarefa dela.
• Na aba Subtarefas da US: cada subtarefa mostra a nota que recebeu, ou o botão Votar. Embaixo aparece a soma das subtarefas, para comparar com a estimativa da US.
• No GitHub: a nota vai para o campo de estimativa do quadro. Se a subtarefa ainda não estava no quadro, ela entra na mesma coluna da US.
• Opcional: a opção Votar também as subtarefas, na hora de importar, desliga isso para quem estima só as US.

Uma sub-issue que já é card no quadro não aparece solta na lista de importação: ela vem junto com a US.

Dividir no GitHub

Na US em votação (ou numa subtarefa), o botão Dividir abre a criação de sub-issues, com o que o GitHub pede ao criar uma issue:

• Título e descrição, com um atalho que insere a seção Critérios de aceite.
• Responsáveis e etiquetas, com busca e a cor de cada etiqueta.
• Tipo, nos repositórios de organização que usam tipos de issue.
• Marco, que já vem com o mesmo marco da US.
• Coluna e estimativa no quadro: se você não escolher uma nota, a subtarefa espera a votação.

Para dividir em várias de uma vez, marque Criar outra depois desta: o formulário limpa o título e a descrição e mantém o resto. Cada subtarefa criada entra na mesa logo abaixo da US.

O GitHub com a cara do GitHub

• Ícones: o símbolo do GitHub está no botão de importar, nos links das issues e no Dividir, e a etiqueta, o marco, os responsáveis e o projeto usam os ícones do próprio GitHub (Octicons).
• Na US em votação: aparecem o tipo, as etiquetas e os responsáveis da issue.

Segurança

• Só quem importou divide e grava. O computador que trouxe as US guarda quais issues são dele, e só nelas cria subtarefas e grava notas. Ninguém da chamada consegue apontar outra issue, nem trocando o card no estado do jogo.
• Só operações fechadas. O processo principal ganhou duas operações, ler as opções do repositório e criar uma sub-issue, e continua sem aceitar GraphQL livre.
• Nada se perde no meio. Se a issue for criada e o quadro falhar logo depois, o aviso mostra o número da issue criada, para ela não ser criada de novo.

Testado

Testado contra o GitHub de verdade, no quadro de teste:

• Criação: uma sub-issue nasceu embaixo da US certa, com etiqueta, responsável e descrição, na coluna escolhida e com a estimativa.
• Gravação: uma subtarefa que estava fora do quadro entrou nele na coluna da US, com a nota.

Tudo foi desfeito depois do teste.

Há uma limitação conhecida:

• Só no aplicativo de mesa, como a importação: no navegador, os botões não aparecem.

Vcall 3.19.0

Vcall 3.19.0: o Planning Poker traz as US do quadro de um GitHub Project, com descrição, critérios de aceite e subtarefas, e grava a estimativa de volta no card.

Antes

As histórias do Planning Poker eram digitadas ou coladas uma por linha. Durante a votação, o time abria o GitHub em outra janela para ler a US, e no fim alguém copiava cada estimativa para o card, uma por uma.

O que mudou

No aplicativo de mesa, o botão GitHub embaixo da lista de histórias abre três passos:

• Conectar. Você gera um token clássico no GitHub (o botão já abre a página com os escopos project, repo e read:org marcados) e cola no Vcall. O token fica cifrado pelo sistema no seu computador. Sair apaga o token.
• Projeto. Aparecem os seus projetos e os das suas organizações, com o último usado primeiro. Dá também para colar o endereço do projeto.
• US. Cada coluna do quadro aparece com a quantidade de cards. Você marca as US que vão para a mesa. Já vêm marcadas as que ainda não têm estimativa, e as que já estão na mesa não entram de novo. Cada linha mostra quantas subtarefas já foram fechadas.

Na mesa, a US em votação mostra o link do card e três abas, com a contagem à vista:

• Subtarefas: as sub-issues, com o que já foi fechado e o link de cada uma.
• Critérios de aceite: a checklist do corpo da issue. A aba leva o nome do título que vem antes da checklist.
• Descrição: o texto da issue, sem a formatação.

A aba abre por cima da mesa, sem esconder as cartas, e cada pessoa abre e fecha para si.

Ao salvar a estimativa, o número vai para o campo de número escolhido no projeto (por exemplo Estimate), não importa quem salvou. Quem grava é o computador de quem importou.

Segurança

• Só o seu Vcall usa o token. Quem fala com o GitHub é o processo principal do aplicativo de mesa. A página não ganha acesso à internet por isso: ela continua falando só com o próprio servidor.
• Só operações fechadas. O processo principal faz só cinco coisas: listar projetos, ler um quadro, ler os cards, ler os detalhes dos cards e gravar um número. Um script injetado na página não consegue fazer outra coisa com o seu token.
• Só nas salas abertas pelo seu Vcall. Na sala de outra pessoa, o pedido é recusado, e ninguém da chamada consegue fazer o seu computador gravar em outro projeto.
• Só links do GitHub. Um link que chega de outra pessoa da chamada só aparece se for do github.com.

Testado

Testado contra o GitHub de verdade:

• Leitura: projetos de organizações, um quadro com 585 cards e US com até 10 sub-issues.
• Gravação: feita num projeto temporário, apagado logo depois. Salvar 8 na mesa pôs 8 no campo Estimate do card.

Há uma limitação conhecida:

• Só no aplicativo de mesa. No navegador, o botão não aparece.

Vcall 3.18.0

Vcall 3.18.0: quem transmite pelo aplicativo de mesa para 3 ou mais pessoas codifica a tela uma vez só. Um servidor de mídia (SFU) dentro do próprio app repassa a imagem a cada uma, cifrada de ponta a ponta.

Por que a sala grande travava

Até a 3.17, cada pessoa da sala recebia uma cópia própria da tela, codificada só para ela. Com 5 pessoas assistindo, o processador de quem transmite fazia 5 codificações ao mesmo tempo e não passava de ~20 quadros por segundo, mesmo com internet de sobra.

O que mudou

O aplicativo de mesa agora traz o LiveKit (código aberto, Apache-2.0), um servidor de mídia que roda no PC de quem transmite. Numa sala de 3 ou mais pessoas:

• Uma codificação. A tela sai codificada uma vez, em duas camadas: até 1080p a 3,5 Mbps e uma de 360p para quem tem internet fraca. O SFU repassa a cada pessoa a camada que cabe na conexão dela.
• A troca não deixa ninguém sem imagem. Cada pessoa passa a receber pelo SFU e confirma quando os quadros chegam. Só então quem transmite para de mandar a cópia direta para ela. Se os quadros pararem, a cópia direta volta.
• Cifrado de ponta a ponta. Os quadros saem cifrados (SFrame), com uma chave nova a cada transmissão. A chave vai de pessoa para pessoa pelos canais da chamada e nunca passa pelo SFU, que repassa a imagem sem conseguir vê-la. Medido: quem recebe a chave errada não decifra nada e continua pela conexão direta.
• Pelo mesmo link. Quem assiste entra no SFU pelo endereço da sala (túnel ou Tailscale). Não é preciso abrir porta nem instalar nada.
• Só quem transmite publica. Só a janela do próprio aplicativo pode publicar no SFU. Quem chega pelo link só assiste.
• Som junto com a imagem. A sincronia da 3.17.4 (o som espera a imagem por até 250 ms) também vale para o que chega pelo SFU.

Em sala de 2, nada muda: a conexão direta continua, porque é a de menor atraso. No navegador, sem o aplicativo de mesa, a sala também continua como antes.

Medido

Medido num notebook com o vídeo 1080p a 60 quadros por segundo, e quem assiste em casas simuladas: 30 ms de atraso, 1% de perda e 5 Mbps de subida.

Pessoas assistindo, subida de quem transmite	Antes	3.18.0
5, a 60 Mbps	634×344, 30 quadros por segundo chegando	1404×760, 58 a 60 chegando
8, a 60 Mbps	não acompanha	1404×762, 57 a 59 chegando (usou 50 Mbps)
2, a 10 Mbps	950×516, 60 chegando	1268×688 a 1902×1032, 56 a 61 chegando (usou 7,4 Mbps)

Quantas pessoas cabem depende da subida de quem transmite: cada uma recebe até ~3,7 Mbps. Com 70 Mbps de subida, ficam ~16 pessoas em 720p ou 1080p a 60.

Há duas limitações conhecidas:

• Operadora com CGNAT. Quem assiste precisa alcançar o PC de quem transmite. Se a operadora usa CGNAT e a conexão não fecha, essa pessoa continua pela conexão direta, como na 3.17.
• Instalador maior. O instalador ficou ~20 MB maior, por causa do LiveKit.

Vcall 3.17.4

Vcall 3.17.4: a tela compartilhada para de travar pela internet, e o som não fica mais segundos atrás da imagem.

O som da tela não fica mais para trás

Na 3.17.3, o som do computador ia junto com a imagem, e o navegador de quem assistia segurava o som para casar com ela. Quando a imagem engasgava, o som ia junto: chegava a 2 a 2,7 s de atraso e levava mais de 25 s para voltar.

Agora o som vai separado, e o Vcall de quem assiste faz a sincronia: o som espera o mesmo tempo que a imagem, até no máximo 250 ms. Se a imagem engasgar, o som segue sozinho, sem atraso.

Medido com um vídeo 1080p a 60 quadros por segundo e 2 pessoas pela internet simulada (10 Mbps de envio, 30 ms de atraso, 1% de perda):

	Antes	3.17.4
Som atrás da imagem quando ela engasga	até 2,7 s	até ~20 ms
Som do computador (rede + espera)	1,6 a 2,4 s nos engasgos	~150 ms
Travadas	várias, até 13 s	nenhuma

A tela volta logo depois de um aperto na internet

Depois de um momento de pouca banda, a tela voltava a subir 15% por vez, e a imagem ficava parada 11 a 13 s. Agora, quando a internet se acalma, a tela volta à qualidade toda de uma vez.

A chamada também reiniciava a conexão a cada ~10 s em algumas redes, porque o Vcall lia os bytes no lugar errado e achava que ela tinha congelado.

Pela internet simulada a 10 Mbps	Antes	3.17.4
Reinícios da conexão por rodada	3 a 4	nenhum
Tempo com a tela parada por rodada	1,4 a 18,9 s	1,0 a 1,1 s
Trocas de resolução por rodada	~5	~2

A imagem só cresce depois de 18 s com folga. Diminui na hora.

Tela parada continua viva

Quando a tela compartilhada passa pelo relé e fica parada, o Vcall reenvia a última imagem uma vez por segundo. Essas cópias levavam a hora da captura antiga e o codificador descartava todas. Agora saem.

Outros

• Modo jogo: a sobreposição aparece no canto escolhido mesmo se ele mudar enquanto ela abre.
• Linux: tirada uma opção de captura do PipeWire que o Chromium já não usa.

Vcall 3.17.3

Vcall 3.17.3: vídeo e jogo compartilhados passam de 50 quadros por segundo, e o som da tela chega junto com a imagem.

Mais de 50 quadros no vídeo compartilhado

Um vídeo a 60 quadros por segundo compartilhado pelo aplicativo de mesa travava em ~45. O motivo era uma regra do Chromium: a captura de tela só pode ocupar metade do tempo de um núcleo do processador. O Vcall pedia a imagem já reduzida (para 720p ou 1080p), e reduzir dentro da captura custava ~6 ms por quadro. Cada quadro levava ~11 ms, e a próxima captura só vinha 22 ms depois.

Agora, na Fluidez, a janela é capturada no tamanho dela (até 1440p) e quem reduz a imagem é o codificador, em outro núcleo. Cada captura caiu para 6 a 9 ms.

Medido no notebook de teste, com o vídeo codificado pelo processador e quem assiste na mesma máquina:

O que foi compartilhado	Antes	3.17.3
Gameplay do YouTube a 1080p60, em tela cheia, com o Vcall atrás	43 a 45 qps	53 a 57 qps
Animação a 60 qps, com o Vcall minimizado	41 a 46 qps	52 a 55 qps
Animação a 60 qps, com o navegador em tela cheia	42 a 47 qps	52 a 56 qps

Pela internet (rede simulada com 3, 6 e 10 Mbps de envio e 1% a 2% de perda), a tela chegou a 59 quadros por segundo nas três. Com pouca banda, a imagem diminui para caber e os quadros continuam.

O som da tela junto com a imagem

O som do computador e a imagem da tela iam como duas transmissões soltas, e quem assistia tocava cada uma no seu ritmo. Agora vão juntas, e quem recebe segura a imagem para casar com o som.

Medido com uma tela que pisca e apita no mesmo instante, a diferença entre o som e a imagem para quem assiste caiu de ~95 ms para ~70 ms. O que sobra é o tempo que o Windows leva para entregar o som do computador ao Vcall.

Linux

A captura de tela não pede mais de 60 quadros por segundo no Linux. O PipeWire não entrega mais que isso, e no X11 pedir 120 só capturava e mandava quadros repetidos.

O Vcall abre mesmo com a porta ocupada

Se outro programa, ou outra cópia do Vcall, já usava a porta 7718, o aplicativo mostrava "A JavaScript error occurred in the main process" e ficava sem janela. Agora ele usa a porta seguinte, como já deveria.