Teste de Fluxo Real de Webcam: o que o interlocutor vê?

A imagem que você vê na sua pré-visualização de webcam é uma visualização de captura local — o feed da câmera conforme entregue pelo getUserMedia() — e não a saída bruta do sensor. A imagem que o destinatário da sua videoconferência vê é um fluxo codificado pelo navegador que foi silenciosamente negociado, comprimido e possivelmente degradado pelo WebRTC. Este guia explica como funciona a negociação de codec WebRTC, como usar getStats() em um RTCPeerConnection para medir parâmetros reais do fluxo e como corrigir causas comuns de perda de qualidade. Observe que a ferramenta de webcam deste site verifica apenas a faixa de captura local e a taxa de quadros do navegador; ela não mede o fluxo codificado WebRTC de saída.

Você senta em uma videoconferência e sua própria janela mostra uma imagem 1080p nítida e bem iluminada. Você está definido, o fundo está limpo e o enquadramento está correto. Então um colega diz que seu vídeo continua travando e ficando borrado, e quando eles compartilham a tela você se vê como uma imagem em blocos e com bordas macias que uma webcam de entrada de uma década atrás teria produzido. Mesma câmera. Mesma iluminação. Mesma máquina. Uma imagem diferente. Aqui está o que a maioria dos guias de videoconferência ignora: essa lacuna geralmente não é uma falha de hardware ou um defeito de sensor — embora um driver mal-comportado às vezes possa causá-la também. É tipicamente a diferença entre o que sua câmera produz e o que seu navegador realmente envia. Sua pré-visualização é alimentada pelo caminho de captura local — o quadro que a câmera produziu conforme entregue pelo getUserMedia() — antes da codificação WebRTC, o que a torna uma visão mais favorável de seu vídeo do que o que os outros participantes recebem. Essa visão ainda pode incluir dimensionamento, conversão de cor ou processamento de restrições aplicado pelo navegador, então não é saída bruta do sensor. O que os outros participants recebem é um fluxo comprimido que foi negociado, re-codificado, limitado em taxa e possivelmente degradado pelo WebRTC nos milissegundos antes de sair da sua máquina. Essa camada de codificação é invisível pela interface do usuário e silenciosa durante a operação normal. Nada na janela da chamada diz que ela existe, nada relata suas decisões e nada em sua pré-visualização reflete essas decisões. Uma cena familiar: um usuário passa horas reinstalando o driver da câmera porque uma chamada mostra uma imagem borrada — só para descobrir via chrome://webrtc-internals que o navegador estava negociando para baixo até 480p15 com base em estimativa de banda, não por causa da câmera ou do driver. Esta página explica o que acontece entre o sensor da câmera e a tela do seu parceiro de chamada, por que o navegador baixa silenciosamente sua qualidade e, mais importante, como medir o fluxo real saindo da sua máquina em vez de confiar na pré-visualização.

O que sua pré-visualização não mostra

A videoconferência se apoia em um pipeline que roda inteiramente fora da sua percepção. Cada quadro que você envia passa pelas seguintes etapas:

1. O sensor da câmera captura um quadro; o navegador então o entrega através de getUserMedia() na resolução e taxa de quadros solicitadas, o que pode envolver dimensionamento, conversão de cor e processamento de restrições.
2. O navegador recebe esse quadro através da API getUserMedia() e o passa ao motor WebRTC. Sua pré-visualização local é alimentada por essa etapa — é por isso que ela sempre parece perfeita, independentemente do que aconteça a seguir.
3. O codificador WebRTC comprime o quadro em um fluxo de bits usando um codec negociado, em uma resolução, taxa de quadros e bit rate negociados.
4. O quadro codificado é dividido em pacotes RTP e enviado pela rede, geralmente por um servidor de mídia que o retransmite para todos os outros.
5. Cada receptor decodifica os pacotes de volta em uma imagem e a renderiza na tela. Sua pré-visualização se conecta ao pipeline na etapa dois. Ela exibe o quadro que a câmera produziu conforme entregue pelo getUserMedia(), antes da codificação WebRTC. O navegador pode aplicar dimensionamento, conversão de cor ou processamento de restrições nessa etapa, mas nenhuma compressão WebRTC é aplicada. O fluxo que seu parceiro de chamada vê é o que sai da etapa três. Entre esses dois pontos, o codificador decide o que o mundo recebe, e toma essa decisão com base em condições que você nunca vê. O codificador negocia silenciosamente três parâmetros, e cada um pode mudar durante a chamada sem nenhum aviso:

• Resolução — a largura e altura dos quadros codificados, que podem cair de 1920 por 1080 para 1280 com 720 ou 640 por 480 por conta própria.
• Taxa de quadros — quantos quadros por segundo sobrevivem à codificação, que frequentemente cai primeiro (de 30 para 15 ou menos) já que cortar a taxa pela metade corta a taxa de dados ao meio sem alterar a resolução — embora algumas implementações possam reduzir a resolução em vez disso, dependendo do codec e da plataforma.
• Bit rate — quantos bits por segundo o codificador pode gastar, o que define o nível geral de compressão. Esses três valores determinam tudo o que o outro lado vê. Uma imagem 1080p comprimida a um bit rate baixo fica macia e borrada. Um fluxo de 30 fps que de repente roda a 10 fps fica travado e antinatural. Quando você entende que a pré-visualização não reporta nenhum desses valores, o mistério da chamada terrível com uma ótima câmera se desfaz.

SDP negocia antes de você enviar um quadro

A negociação começa antes do primeiro quadro ser enviado. Quando você entra em uma chamada, a plataforma e seu navegador trocam uma oferta e resposta de Session Description Protocol (SDP). O SDP anuncia os codecs e capacidades de mídia que cada lado suporta; a resolução e taxa de quadros reais são então negociadas através de parâmetros de envio e recebimento e limitadas por estimativa de banda. Em testes informais no Chrome 125 no Windows 10 (maio de 2024), a resposta SDP foi observada oferecendo VP9 primeiro, depois H.264, depois VP8; no Safari 17 no macOS 14 (mesmo período), H.264 apareceu primeiro. Essas observações foram feitas em uma máquina por navegador sem condições de rede controladas, então ilustram a variação que existe em vez de definir uma ordem universal. O codec selecionado na verdade depende do navegador, da plataforma, dos parâmetros SDP e das capacidades de hardware. Escolhas comuns incluem VP9, H.264, VP8 e AV1, mas não há uma ordem de preferência fixa em todas as plataformas. A seleção de codec é apenas o início. Uma vez que a chamada está viva, um segundo mecanismo assume: estimativa de banda. O WebRTC monitora continuamente o caminho de rede em ambas as direções e executa um algoritmo de controle de congestionamento — mais comumente Google Congestion Control — que faz três medições em base rolante:

• Perda de pacotes, reportada pelo receptor através de mensagens de feedback RTCP.
• Tempo de ida e volta, o atraso entre enviarum pacote e receber um reconhecimento de chegada.
• Vazão, a taxa efetiva em que dados realmente atravessam a conexão. O algoritmo alimenta essas medições em um modelo que estima quanto de banda a rede consegue carregar no momento. Essa estimativa se torna um bit rate alvo entregue ao codificador, e o codificador adapta sua saída para caber. O loop é contínuo e rápido: quando a estimativa cai, o codificador re-codifica a um bit rate mais baixo em uma fração de segundo. Os limiares são aproximados e dependem do algoritmo de controle de congestionamento em uso. Perda de pacotes sustentada acima de aproximadamente cinco por cento pode acionar uma redução no bit rate alvo, mas o comportamento exato — quanto o bit rate cai, se resolução ou taxa de quadros também mudam e em que nível de perda — varia por algoritmo, codec e plataforma. Não há um mapeamento universal de uma porcentagem de perda para uma resolução de saída específica. O loop de feedback que dirige essas decisões é definido em ([Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP](https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc)). Um fluxo 1080p a 30 fps geralmente precisa de cerca de quatro a seis megabits por segundo de banda de upload para ficar limpo, embora isso dependa do codec, das configurações de codificação e da complexidade da cena. Se o estimador concluir que apenas um megabit está disponível, ele não tenta forçar o fluxo — ele reduz o alvo e o codificador responde baixando resolução para 480p e taxa de quadros para 15 fps. Se a estimativa cair ainda mais, a imagem se degrada novamente, tudo até um rosto falante de 320 por 240. Cada etapa é deliberada: o objetivo é manter a chamada viva e o áudio estável, e a qualidade do vídeo é a primeira coisa sacrificada para alcançar isso.

Três padrões de falha que seu fluxo esconde

A pré-visualização esconde o estado real do fluxo por trás de três padrões de falha recorrentes. Aprenda a reconhecer cada um por seus sintomas, porque a correção correta difere em cada caso. Todos os três compartilham uma pista: a pré-visualização permanece perfeita o tempo todo, porque é amostrada antes do codificador. Apenas o fluxo codificado — e, portanto, as telas dos outros participants — mostra o dano.

A Armadilha de Bit Rate

Sintomas: Sua pré-visualização está perfeita e sua máquina tem CPU ociosa. O outro lado vê uma imagem borrada e de baixa resolução que nunca nitidece, mesmo durante uma pausa. Gravações locais ficam excelentes; a chamada fica ruim. Diagnóstico: O navegador estimou que a rede não consegue carregar o fluxo completo e limitou o bit rate, forçando o codificador a reduzir a resolução. A restrição é sua banda de upload ou a capacidade de retransmissão do servidor de mídia, não sua câmera. Execute um teste de velocidade e compare seu upload medido contra os quatro a seis megabits que 1080p30 exige. Se você compartilhar uma conexão com outros dispositivos transmitindo, baixando ou sincronizando, eles estão competindo pelo mesmo orçamento.

O Limiar de Perda

Sintomas: Imagens estáticas da chamada ficam boas, mas qualquer movimento fica travado e robótico. Áudio permanece suave enquanto o vídeo engasga, e travamentos curtos ocorrem a cada poucos segundos antes da imagem retomar em uma taxa de quadros menor. Diagnóstico: A perda de pacotes está cruzando o limiar de cinco por cento intermitentemente, então o controlador de congestionamento está cortando repetidamente o bit rate alvo e o codificador está descartando quadros para acompanhar. A taxa de quadros cai primeiro porque é a alavanca mais barata — reduzir de 30 para 15 fps corta a taxa de dados ao meio sem alterar a resolução. Verifique interferência Wi-Fi, um cabo Ethernet marginal ou uma VPN adicionando perda e latência. O vídeo continuará se degradando até que o caminho de rede seja reparado.

O Travamento de Keyframe

Sintomas: Nos primeiros dois a cinco segundos após entrar, ou após compartilhar sua tela, o outro lado vê uma imagem travada ou fortemente borrada. Então a imagem entra em foco e se comporta normalmente até a próxima grande mudança de cena. Diagnóstico: Codecs de vídeo enviam dois tipos de quadro. Keyframes codificam a imagem inteira e aparecem em intervalos fixos — comumente a cada um a dez segundos dependendo da plataforma e configuração. Delta frames codificam apenas as mudanças desde o quadro anterior, o que os torna minúsculos. Se um pacote de um delta frame for perdido, o receptor não consegue reconstruir aquele quadro — ele pode solicitar uma retransmissão (NACK), pedir ao remetente um keyframe fresco (PLI ou FIR) ou ocultar o erro enquanto espera. Quando uma solicitação tem sucesso, a recuperação é rápida; quando não tem, a imagem fica travada até o próximo keyframe agendado chegar. Essa espera é o travamento que você vê. Intervalos curtos de keyframe recuperam mais rápido mas custam banda; intervalos longos são eficientes mas tornam cada perda mais visível. Isso não é uma falha — é o codec funcionando conforme projetado.

Medindo o fluxo real com getStats()

Pare de adivinhar. Os números não são lisonjeiros, mas são verdadeiros. A API WebRTC expõe uma interface de estatísticas que relata exatamente o que o codificador está fazendo, e qualquer página web que você controla pode ler sua própria conexão peer. Chame getStats() no objeto RTCPeerConnection, depois filtre o relatório retornado pela entrada outbound-rtp cujo kind é video. Nas entradas media-source e outbound-rtp você encontrará os valores que importam:

• framesPerSecond (na entrada media-source) — a taxa de quadros que a câmera está entregando ao codificador. Se isso estiver abaixo de 30 em uma câmera de 30 fps, o próprio caminho de captura é o problema — muitas vezes trata-se de concorrência de banda USB, que nosso guia sobre concorrência de banda USB explica como diagnosticar.
• framesPerSecond (na entrada outbound-rtp) — a taxa de quadros que o codificador está realmente produzindo. Quando isso for menor que a taxa de entrada, o codificador está descartando quadros.
• frameWidth e frameHeight (na entrada outbound-rtp) — a resolução codificada. Compare com suas configurações de chamada; qualquer diferença é uma degradação silenciosa.
• bytesSent (na entrada outbound-rtp) — dados codificados totals. Amostre duas vezes com um segundo de intervalo e calcule a diferença vezes 8 para obter o bit rate real.
• packetsSent e packetsLost — observe que packetsLost na entrada outbound-rtp nem sempre está preenchida; a proporção de perda é lida com mais segurança na entrada remote-inbound-rtp, que reporta a perspectiva do receptor.
• currentRoundTripTime (na entrada candidate-pair) — o atraso de rede. Um RTT alto combinado com perda indica congestionamento. Diferentes navegadores podem reportar nomes de campos levemente diferentes ou omitir algumas estatísticas inteiramente, então confira contra a página de internals WebRTC do navegador quando disponível. As regras de interpretação são simples. Se o framesPerSecond do outbound-rtp estiver visivelmente abaixo do framesPerSecond do media-source, o codificador está descartando quadros sob pressão. Se frameWidth e frameHeight estiverem abaixo da resolução que você configurou, o orçamento de conexão não conseguiu carregar. Se bytesSent se traduz em um bit rate muito abaixo do requisito do codec para essa resolução, a imagem está sendo esmagada — e a pré-visualização, que nunca vê o codificador, vai ficar perfeita o tempo todo. Você não precisa escrever código para ler esses valores. Chrome e Edge vêm com um visualizador de estatísticas embutido em chrome://webrtc-internals que captura todas as conexões WebRTC no navegador, inclusive a que uma plataforma de chamada criou. Abra antes de entrar em uma reunião, deixe gravar e inspecione as entradas outbound-rtp do transmissor de vídeo depois. Os mesmos números de taxa de quadros, resolução, bit rate e perda estão lá, junto com um gráfico de linha do tempo mostrando exatamente quando o codificador mudou sua saída. Esta é a forma mais rápida de pegar uma degradação em ato em uma chamada real de plataforma. Faça essa medição enquanto sua própria chamada fica ociosa em segundo plano, depois de novo durante uma reunião ocupada, e compare os dois conjuntos de números. Uma comparação típica: ocioso, outbound-rtp framesPerSecond lê 30; durante uma reunião ocupada ele pode cair para 18 enquanto a pré-visualização local ainda mostra 30. Essa comparação revela se sua rede de base é adequada e se a concorrência durante a chamada é o que aciona a degradação. Nosso teste de webcam mostra a resolução e taxa de quadros da faixa de captura local conforme negociada pelo getUserMedia() — uma linha de base útil para o que sua câmera consegue entregar ao navegador, mas não uma medição do fluxo codificado WebRTC de saída, que exige uma conexão peer ou a página de internals WebRTC do navegador.

Zoom, Meet, Teams: três câmeras diferentes

A mesma câmera, o mesmo laptop e a mesma rede podem produzir resultados visivelmente diferentes em aplicações diferentes, porque cada plataforma aplica sua própria política de codificação por cima da implementação WebRTC do navegador.

• Zoom costuma priorizar estabilidade. Dependendo da versão, tipo de conta e configurações da reunião, ele pode limitar a resolução de saída e sacrificar qualidade de vídeo para manter áudio e compartilhamento de tela estáveis. Uma câmera capaz de 1080p pode transmitir 720p ou menos no Zoom.
• Google Meet tende a se adaptar à banda medida, baixando a resolução cedo e restaurando-a rapidamente quando as condições melhoram. Seu comportamento acompanha seu estado real de rede, para bem e para mal.
• Microsoft Teams aplica seu próprio pipeline de codificação e pós-processamento. Dependendo da versão e das configurações da reunião, a imagem pode ser ainda mais comprimido além da negociação WebRTC bruta.
• WebRTC nativo do navegador, o tipo que você obtém em uma página web simples, envia o fluxo negociado sem política de plataforma por cima. É a coisa mais próxima de verdade básica para o que seu hardware e rede podem entregar sob WebRTC puro. Políticas de plataforma variam por versão, tipo de conta e configuração de reunião, então trate essas como tendências gerais, não regras fixas. A consequência prática: comparar uma chamada no Zoom contra uma chamada no Meet não é um teste de câmera. É um teste das decisões de codificação de cada plataforma. Meça o fluxo bruto primeiro com uma página WebRTC simples ou a ferramenta teste de webcam. Se o fluxo bruto estiver limpo e uma plataforma ainda parecer ruim, a política da plataforma é a restrição, e nenhuma atualização de hardware vai mudá-la. Quando uma chamada de plataforma está em andamento, chrome://webrtc-internals permite acompanhar suas decisões de codificador ao vivo, então você pode ver se a degradação é a política da plataforma ou o comportamento da rede, sem confiar no auto-relato de nenhum dos dois lados.

Sete passos para um fluxo limpo

Esses passos isolam causas distintas. Você pode parar assim que o fluxo parecer correto — mas meça antes e depois de cada mudança para confirmar que a correção realmente moveu os números.

1. Meça primeiro. Abra chrome://webrtc-internals ou use getStats() na sua própria conexão peer e registre resolução, taxa de quadros e bit rate. Se o fluxo bruto já estiver degradado, sua câmera e conexão são o problema. Se estiver limpo, a plataforma é.
2. Verifique banda. Videoconferências precisam de pelo menos 1 Mbps de upload para 720p e cerca de 4 Mbps para 1080p. Teste da máquina de onde você liga, não de outro dispositivo, e reteste com outros tráfegos na rede. Mova para uma conexão com fio se puder; perda Wi-Fi é a causa mais comum de degradações invisíveis.
3. Corrija a iluminação. Um assunto bem iluminado comprime dramaticamente melhor que um escuro, porque o codificador gasta bit rate em detalhes visíveis em vez de ruído. Encare uma janela ou use uma fonte de luz suave. Isso não custa nada e frequentemente produz uma melhora maior do que qualquer configuração.
4. Desabilite redução de ruído de vídeo quando seu ambiente já estiver tranquilo e bem iluminado. Algumas plataformas aplicam descompactação agressiva em cenas com pouca luz, o que pode suavizar detalhes finos notavelmente no fluxo codificado. A pré-visualização local não vai mostrar essa diferença; apenas o fluxo codificado vai. Verifique as configurações específicas da plataforma para confirmar quais controles estão disponíveis.
5. Desabilite fundo virtual. A segmentação de fundo adiciona sobrecarga ao bit rate efetivo e consome ciclos de GPU do codificador. Um fundo real limpo com iluminação consistente supera qualquer um virtual.
6. Verifique o codec. Se sua CPU conseguir lidar, VP9 entrega a melhor qualidade por bit; se você vir queda de quadros ou picos de CPU, H.264 codifica mais rápido. Algumas plataformas expõem uma preferência de codec nas configurações.
7. Teste uma plataforma diferente. If a qualidade for boa em um serviço e ruim em outro, a política de codificação da plataforma é a restrição. Ajuste suas expectativas ou sua ferramenta de reunião de acordo — seu hardware não é culpado.

Conclusão

A pré-visualização é a autoimagem local de sua câmera: uma visão favorável do que sua câmera consegue entregar ao navegador. O fluxo é o que o mundo realmente vê — negociado, comprimido e moldado por condições de rede e política da plataforma. Eles são dois vídeos diferentes do mesmo assunto, e apenas um deles importa para como você aparece. Se você já se perguntou por que sua câmera parece ótima na sua tela mas terrível na chamada, agora você tem a resposta e a ferramenta para medi-la.

Abra chrome://webrtc-internals. Entre em sua próxima chamada. Acompanhe as entradas outbound-rtp. Se frameWidth ou framesPerSecond estiverem abaixo do que você configurou nas configurações da câmera, a degradação está acontecendo. A causa é tipicamente relacionada a banda — o que seu navegador pode gastar e se sua conexão consegue realmente carregar o fluxo que você acha que está enviando — mas carga de CPU, seleção de codificador, políticas de plataforma e configuração de restrições também podem contribuir ou dominar a degradação.