Como monitorar quadros perdidos (dropped frames) nas estatísticas do OBS Studio

Quando a live trava, o painel de Estatísticas do OBS Studio diz exatamente onde está o problema — antes que o público reclame. Aprender a lê-lo é o que separa o chute do diagnóstico.

O sintoma antes do número

Você quase sempre sente o problema antes de abrir qualquer painel. Nas palavras do tutorial: a perda de quadro em um ou mais processos "pode ocasionar problemas como bufferização e quedas na transmissão". Na prática, é isto que o operador percebe:

• a imagem engasga ou "pula" em blocos, mesmo com o áudio contínuo;
• o espectador vê a rodinha de carregamento voltando o tempo todo;
• a transmissão cai e volta sozinha;
• o próprio OBS acende um indicador amarelo ou vermelho ao lado do status de transmissão.

Qualquer um desses sinais é o momento de abrir o painel. Sem ele, o que sobra é adivinhação — e trocar peça de computador por palpite sai caro.

Abrir o painel de Estatísticas

No OBS Studio atual, o caminho é o menu Painéis → Estatísticas (Docks → Stats, na interface em inglês). Se você seguiu um tutorial antigo e não achou o item, é porque ele mudou de lugar: em versões mais antigas o painel ficava em Exibir → Docks → Estatísticas, e no vídeo acima, de 2020, ele é aberto pelo antigo menu "Mostrar" da barra superior. O conteúdo é o mesmo; só o menu mudou.

O painel mostra, em tempo real, três linhas de perda — e é fundamental saber o nome exato de cada uma, porque a maior parte do material de referência está em inglês:

• Quadros perdidos (rede) — Dropped Frames (Network);
• Quadros perdidos devido à demora na renderização — Frames missed due to rendering lag;
• Quadros ignorados devido à demora na codificação — Skipped frames due to encoding lag.

Além delas, o painel traz uso de CPU, taxa de quadros, espaço em disco e a duração da sessão. Deixe-o visível durante a transmissão: o que importa não é o número absoluto, é qual linha começa a subir e quando — se ela dispara toda vez que você entra numa cena específica, você já achou o culpado.

Tabela: sintoma → linha → causa → primeira ação

Quadros perdidos (rede)

O número mais importante. Se ele sobe durante a transmissão, o seu upload não está sustentando o bitrate — o OBS descarta frames para não atrasar. O conselho comum é "melhore a sua internet", o que não ajuda ninguém. O tutorial é mais específico e mais útil: os gargalos "vindos da rede podem ser elas internas, roteadores, firewalls ou até mesmo do provedor de internet local". Vale percorrer essa cadeia na ordem, porque o custo cresce a cada passo:

1. Rede interna e Wi-Fi — troque o Wi-Fi por cabo antes de qualquer outra coisa. É o teste mais barato e o culpado mais frequente. Verifique também quem mais está usando a rede durante a live (backup em nuvem, atualização, outro streaming).
2. Roteador — equipamento saturado, muitas sessões abertas, QoS mal configurado ou firmware antigo. Reiniciar e testar com a máquina ligada direto no modem isola o roteador da conta.
3. Firewall e proxy — inspeção de pacotes e bloqueio de portas de saída atrapalham o envio contínuo. Em rede corporativa, esse costuma ser o ponto invisível: tudo "funciona", menos o streaming.
4. Provedor — o upload contratado é o teto real, e ele não é o mesmo número do download. Meça o upload no horário da live, não à tarde de um dia calmo. Se o teto for o problema, nenhuma configuração do OBS resolve.
5. Plataforma de destino — se todos os passos acima estão limpos e a perda continua, o gargalo pode estar do lado de quem recebe.

Um paliativo útil enquanto você investiga: em Configurações → Avançado → Rede, a opção "Alterar taxa de bits dinamicamente para gerenciar o congestionamento" (dynamic bitrate) deixa o OBS baixar o bitrate sozinho quando a rede oscila, em vez de descartar frames. Ela reduz o sintoma; não substitui achar a causa. Para o resto, valem as dicas para a live não travar e a escolha do link de internet adequado para live.

Demora na renderização (GPU)

Frames perdidos por demora na renderização indicam que a placa de vídeo não desenha a cena a tempo. Aqui a palavra-chave é cena: o OBS precisa ler todas as fontes, aplicar filtros e compor a imagem final dentro do intervalo de um quadro — cerca de 33 ms a 30 fps, e apenas 16 ms a 60 fps. Se estourar, o frame é descartado antes mesmo de existir.

Como o tutorial resume, a perda nessa linha "pode indicar uma sobrecarga de processamento ao adicionar as fontes no programa". Os suspeitos, em ordem de impacto:

• Fontes de captura de tela e de janela em excesso, principalmente em várias cenas ativas ao mesmo tempo;
• Filtros de imagem — chroma key, correção de cor, máscaras e scaling de resolução alta para baixa em cada fonte;
• Sobreposições animadas (browser sources, alertas, tickers) — cada uma é um navegador rodando por baixo;
• Jogo ou aplicativo pesado disputando a mesma GPU com o OBS.

O método de diagnóstico é ir tirando, não adivinhar: desligue os filtros da cena suspeita um a um, com o painel aberto, e veja em qual deles o contador para de subir. Simplificar as cenas e fontes do OBS Studio, reduzir a resolução de saída ou a taxa de quadros são as saídas que aliviam a GPU sem trocar hardware. Vale notar: essa linha subir não significa que a sua placa é ruim — significa que essa cena, com esses filtros, é mais cara do que essa placa entrega no tempo de um quadro.

Demora na codificação (encoder)

Frames ignorados por demora na codificação significam que o encoder não terminou de comprimir o quadro a tempo. É a etapa seguinte à renderização: o quadro já existe, mas não foi codificado. O tutorial já apontava o essencial — a perda nesse campo "pode indicar um gargalo na CPU, na GPU ou em ambos na hora de codificar o conteúdo".

Esse detalhe é o que a maioria dos textos erra: não é sempre "problema de CPU". Depende de qual encoder você escolheu:

• x264 (software) — codifica na CPU. Aqui, sim, a culpa é do processador, e o preset é o botão certo: veryfast pesa muito menos que medium. Programas abertos em segundo plano competem diretamente.
• NVENC, AMF ou QuickSync (hardware) — codificam num bloco dedicado da placa de vídeo. A CPU sai da conta, mas você passa a disputar a GPU com a renderização das cenas — e as duas linhas podem subir juntas.

Por isso a ordem importa: primeiro descubra qual das duas linhas sobe. Se sobem as duas, aliviar a cena costuma resolver as duas de uma vez. Se sobe só a de codificação com x264, troque o preset ou migre para o encoder de hardware. Se sobe só a de codificação já usando NVENC, o caminho é reduzir resolução ou FPS de saída. Tentar 1080p60 num computador modesto continua sendo a causa mais comum de todas — e o ajuste de taxa de bits e resolução no OBS Studio é o passo natural depois deste diagnóstico.

O teste controlado: mesma máquina, duas configurações

Esta é a parte do tutorial que quase nenhum material sobre quadros perdidos tem, e é a mais importante. Em vez de comparar computadores diferentes, o vídeo faz o contrário: usa a mesma máquina, com configurações intermediárias, e transmite duas vezes. Na primeira, "uma configuração mais básica, para transmissão de palestras e eventos em HD" — sem perda. Na segunda, "uma configuração que exige mais do render deste mesmo computador" — com perda.

A conclusão do apresentador é a tese que falta à maioria dos diagnósticos: "dependendo da configuração setada no seu encoder de vídeo, você iria necessitar de um hardware mais avançado ou não". Ou seja:

Quadro perdido quase nunca significa "compre um computador melhor". Significa "a sua configuração está acima do que essa máquina entrega". São coisas diferentes, e só a segunda é resolvível de graça.

O método que o tutorial recomenda — "testarem as configurações da sua transmissão em mais de um equipamento com configurações distintas antes de estar optando por uma mudança no seu setup" — vira este roteiro:

1. Grave localmente, sem transmitir, com a configuração atual. Se as linhas de renderização e codificação já sobem, o problema é local e a rede está fora da conta.
2. Baixe um degrau por vez — 1080p60 → 1080p30 → 720p60 → 720p30 — repetindo o mesmo trecho de cena, com o painel aberto.
3. Anote em qual degrau as linhas zeram. Esse é o teto real da sua máquina com essa cena, e é um número seu, medido, não um chute de fórum.
4. Só então decida. Se o teto medido atende ao seu evento, não há nada para comprar. Se não atende, você já sabe exatamente qual etapa (render ou encoder) precisa de mais capacidade.

Uma ressalva honesta: não existe um limiar universal de perda "aceitável". O OBS não publica esse número e este artigo não vai inventar um. O critério prático é a tendência — contador parado é o objetivo; contador subindo durante a transmissão é problema, mesmo que o percentual pareça pequeno. Se a sua máquina é modesta, o caminho de partida é a configuração enxuta descrita em como fazer uma live no OBS Studio com um computador básico.

Quadro perdido não é delay

Os dois sintomas se confundem, e a correção de um não serve para o outro. Quadro perdido é conteúdo que sumiu — ele não chega, e a imagem engasga. Delay é conteúdo que chega inteiro, só que atrasado: nada é descartado, o painel de Estatísticas fica limpo, e mesmo assim há segundos entre o que acontece e o que o público vê. Se o painel está zerado e ainda há reclamação de atraso, o assunto é outro — veja como funciona o delay na transmissão ao vivo no OBS Studio. Do lado da entrega, os recursos de estabilidade e qualidade da live tratam do caminho depois que o vídeo sai da sua máquina.

Transcrição do tutorial

Assista ao tutorial completo no canal da JMV Technology — os 5min17s de vídeo, com a demonstração das duas configurações na mesma máquina.

Se o seu lado está limpo e ainda há perda, o gargalo pode ser a plataforma de entrega. Fale com o time da Sitehosting sobre CDN e origem redundante, ou ligue para (11) 4063-8923.