Delay de 40 segundos na Cazé TV: eu explico de onde vem

A carteirada primeiro: eu não comento sobre isso, eu opero isso

Vou dar a minha carteirada antes, porque esse assunto virou terreno de palpite de quem nunca subiu uma live. Eu trabalho com esse negócio faz mais de 20 anos: streaming. Eu tenho um CDN de entrega de vídeo. Eu sou dono de uma empresa que mexe com isso e vende plataforma — e, apesar disso, eu ainda sou hands-on, sou eu que cuido dessa infraestrutura. Então é esse cara que está falando com você, não é comentarista de manchete.

Eu já contei aqui como eu fui parar nesse lugar: me senti enganado pela empresa que cuidava do meu telecom e fui fazer certificação de BGP e sistema autônomo pra cuidar do meu CDN eu mesmo. Depois disso eu nunca mais aceitei explicação pronta sobre rede — nem pra cima de mim, nem pra cima dos meus clientes.

A notícia que me tirou do sério

O que me motivou a gravar foi uma notícia que eu vi no noticiário de tecnologia: "extensão de navegador acaba com o delay da live do YouTube". Publicar isso em rede nacional é brincadeira. Parece coisa de estagiário que é amigo de quem fez a extensão — e o leitor comum lê aquilo e acha que resolveu.

Apuração minha, feita em 27/09/2026, porque no ar eu falei da notícia e não da ferramenta. A extensão dessa leva mais conhecida se chama ZeroDelay, e a descrição dela na loja do Chrome confirma por escrito, com as palavras do próprio autor, exatamente o que eu expliquei no quadro: quando a live com DVR começa a ficar pra trás, ela "aumenta levemente a velocidade de reprodução (1.25x suave) para consumir o conteúdo já baixado e trazer você de volta ao ao vivo". E tem a frase que fecha o caso: ela evita acelerar quando o buffer está baixo.

Leia de novo essa última parte. A própria ferramenta admite que ela só existe enquanto sobrar buffer — e buffer é o último elo de uma corrente de umas dez etapas. Ela não é fraude: ela faz o que diz. O problema é a manchete, que transformou "consumir o buffer acumulado no seu navegador" em "acaba com o delay". São coisas diferentes por uns 25 segundos.

Etapa 1 — antes da internet: câmera, mesa de corte e ilha

Vamos do começo. Pra ter live eu preciso de câmera. Podem ser N câmeras, ligadas por NDI, HDMI, Wi-Fi, link de rádio — e cada uma com a sua qualidade, o seu bitrate, a sua resolução e o seu codec. Todas ligadas num switcher, que é a mesa de corte. Por que eu estou falando isso? Porque isso aqui já é delay, meu filho.

Tem tempo pra câmera captar, empacotar o que ela está vendo lá no campo, mandar pelo cabo, chegar na mesa de corte, a mesa processar, cair na ilha, e a ilha mandar pro computador que grava. Se você pausar esse fluxo quadro a quadro, você vê o delayzinho. Isso aqui não é tempo real. E agora imagina no campo de verdade: dezenas de câmeras, replay, som lá de baixo — tudo isso precisa ser controlado e sincronizado antes de virar imagem.

Guarde este ponto porque ele resolve metade da discussão de boteco: esse primeiro pedaço do atraso é compartilhado por todo mundo, inclusive a TV aberta e o satélite. Não é culpa da internet, não é culpa do YouTube. É o tempo do equipamento capturando o evento.

Etapa 2 — sincronismo: o erro que eu vejo cliente cometendo até hoje

Você captura numa câmera dessas a 60 Mbps. Passa pelo switch a 60 Mbps. Isso aqui é checklist pra quem for fazer live: o switch aguenta? A câmera está sincronizada com o switcher? A sua placa de captura ou o seu encoder estão sincronizados com esse fluxo inteiro? O áudio está sincronizado? A galera do áudio e do vídeo que me perdoe a obviedade — eu falo porque a gente tem cliente que manda material até hoje sem isso sincronizado.

Por que eu insisto nisso? Porque eu já vi jogo grande de Champions com o áudio dessincronizado do vídeo numa Smart TV Samsung bem na hora do anúncio. Você acha que gravaram errado? Não. Isso é falta de sincronia entre o que está sendo mandado e o que a plataforma aceita. E quem opera a live muitas vezes não sabe disso.

A ordem certa é de trás pra frente. Esse é o checklist que eu passo pra quem vai subir uma live:

1. Comece pela plataforma. Vá lá e leia o que ela recomenda: codec de áudio e de vídeo, bitrate, resolução, FPS e intervalo de quadro-chave. Não chute nenhum desses.
2. Ajuste o encoder ou a placa de captura pra bater exatamente com o que você leu. É aqui que mora a maior parte dos problemas que chegam pra mim.
3. Ajuste o switcher e confirme que ele aguenta o fluxo — 60 Mbps de câmera não passam num switch que não foi dimensionado pra isso.
4. Só então as câmeras, sincronizadas entre si e com o switcher.
5. Confira o áudio por último e de novo: taxa de amostragem, sincronia com a imagem, nível. Som dessincronizado é o erro que o público percebe na hora.

Se você fizer no sentido contrário, você vai empurrar pra plataforma um sinal que ela vai ter que consertar. E consertar é tempo.

Etapa 3 — a plataforma: RTMP entra, pacotinho sai

Passamos do switcher. Agora o sinal sobe. O YouTube usa até hoje, por padrão, o velho RTMP — ou RTMPS, que é a versão criptografada, mesma relação que HTTP tem com HTTPS. Aquele protocolo que a Apple fez o favor de matar lá atrás e que segue vivo e passando bem no ingest de todo mundo.

Apuração minha (27/09/2026), porque no ar eu troquei o número: a porta padrão do RTMP é a 1935/TCP. Eu falei 1965 e 195 no vídeo, atrapalhado no quadro — é 1935. O resto do que eu falei está certo e é prática de mercado: a gente também deixa rodar RTMPS na 443 e na 80, porque tem órgão público e rede corporativa que bloqueia porta alta, e assim o cliente não precisa brigar com o firewall dele pra subir o sinal.

Quando a plataforma recebe esse RTMP — que é um protocolo binário, com áudio e vídeo sincronizados do jeito que você mandou —, começa mais uma etapa de atraso. Ela precisa pegar aquilo e transformar num formato palatável pra internet: empacotar, desempacotar e virar HLS ou DASH. O fluxo contínuo vira vários pacotinhos, os chunks. Streaming é pacotinho.

E aí vem a parte pesada, que é a que a maioria das pessoas não imagina que existe. Em geral a galera manda 4K a 18, 20 Mbps. Não é todo mundo que tem internet pra isso — muito menos 21 milhões de pessoas ao mesmo tempo. Então a plataforma tem que pegar esse mesmo vídeo e gerar 1080p, 720p, 360p, às vezes 180p, cada um com o seu bitrate.

Quer sentir o peso disso? Pega o seu computador agora, abre o CapCut, o Premiere, o que você usar, joga um vídeo 4K do seu telefone e manda renderizar em 1080p. Lembra o tempo que demora? Lembra a ventoinha ligando como se o computador fosse decolar? Agora imagina isso em tempo real, em todas as qualidades ao mesmo tempo, com GPU cavalona. É exatamente isso que acontece. E isso é exclusivo da internet: o sinal convencional de TV aberta não precisa fazer nada disso.

Etapa 4 — o buffer do player: os 20 segundos que a extensão ataca

Agora a imagem precisa chegar na casa do torcedor. E ali está a maior fatia isolada do atraso: o buffer.

O player acumula na memória um tempo de vídeo já baixado pra privilegiar o não travamento. Junto com isso trabalha a taxa de bits adaptativa, aquele sistema que a Apple criou no HLS: conforme a qualidade da sua internet oscila, ele troca automaticamente pra uma qualidade menor e depois volta. Você já viu isso acontecer no YouTube e na Netflix sem ninguém tocar em nada. Confere com a letra da própria Apple: a página oficial do HTTP Live Streaming diz que o HLS "dynamically adapts to network conditions by optimizing playback for the available speed of wired and wireless connections".

Na prática, os players são configurados em geral pra segurar uns 20 segundos de buffer. E foi aí, e só aí, que o rapaz que fez a extensão atuou. Ele acelera o vídeo e come o buffer do navegador. O que acontece quando você tira o buffer? Trava. Você não vai tirar o buffer todo, porque ele é a sua rede de segurança — e a primeira oscilação da sua internet vira imagem congelada na melhor hora do jogo.

Ele mexeu nos 20 segundos e esqueceu de todo o resto — as três etapas de cima e as duas de baixo. Por isso os relatos falam em ganhar 15 segundos, não 40: o teto dele é o buffer, e nem o buffer inteiro ele pode comer.

Etapa 5 — a viagem física: 130 ms só pra atravessar o Atlântico

Agora a parte que eu mais gosto, porque é onde as pessoas esquecem que a internet é feita de coisa física enterrada no chão e jogada no fundo do mar.

A imagem está sendo gerada nos Estados Unidos. Ela tem que vir por fibra óptica, atravessando o Atlântico. Eu tenho data center no Brasil e nos Estados Unidos, então esse número eu não chuto: usando o melhor trânsito IP que a gente tem hoje, fibra pura, dá uns 130 milissegundos entre Brasil e Estados Unidos. Isso é o piso. Ninguém vence a velocidade da luz no vidro.

Eu já escrevi aqui inteiro sobre esse pedaço submarino da nossa internet e o que acontece se cortarem o cabo — e é o mesmo cabo que traz o gol.

Chegando no Brasil, o conteúdo cai num data center e precisa vencer a última parte, que é a mais traiçoeira: chegar na casa do assinante. E aí entra o dinheiro. Quando um provedor contrata internet pra revender, ele compra de um provedor maior: é o trânsito IP, o backbone. Ele tem um link de tamanho fixo — digamos 10 Gb. Faça a conta comigo: se 1.000 assinantes assistirem ao mesmo tempo puxando 10 Mbps cada, são 10 Gb — e acabou. Saturou o link do cara, e o resto dos clientes dele fica sem nada.

Isso não é hipótese: é o que acontece em todo jogo do Brasil. Em nenhum outro momento da vida todos os assinantes de um provedor ligam no mesmo conteúdo ao mesmo tempo.

Etapa 6 — Google Global Cache e IX: onde some o resto dos segundos

O Google viu isso e resolveu com engenharia de rede pancadona. Ele pega um servidor parrudo e mete dentro do provedor. Chama Google Global Cache, GGC. Em vez de mil casas puxarem o mesmo vídeo lá do data center, o Google manda um fluxo fininho pra caixa que está dentro do provedor, e o provedor distribui localmente pra todo mundo, na porta de 100 Gb do switch dele.

Apuração minha (27/09/2026), na documentação do próprio Google: a página oficial do GGC diz que ele "allows ISPs to serve certain Google content from within their own networks", que tipicamente de 70% a 90% do tráfego cacheável pode ser servido dali, e que isso "eases congestion within your network, and reduces the amount on traffic on your peering and transit links". O Google entrega o hardware e o provedor entrega rack, energia e conexão. Não é pra qualquer provedor, é NDA, custa negociação — e todo mundo quer esse trem.

E pra quem não consegue um GGC, existe o IX, o Internet Exchange — que aqui a gente chama de PTT, ponto de troca de tráfego. O Google está no IX, e centenas de provedores puxam o conteúdo dali em vez de pagar trânsito. O maior do país é o de São Paulo; tem no Rio; tem espalhado.

Agora junte tudo. Cada salto desses — data center nos Estados Unidos, data center no Brasil, cache no provedor — guarda alguns segundos pra não travar. Uns 5 aqui, uns 3 ali, mais uns 5 na caixa do provedor conforme a demanda cresce. Os 40 segundos são a soma disso tudo. É o preço de aguentar uma porrada dessas vindo dos Estados Unidos: somando o que sai de cada provedor, é uma quantidade de banda que, se você olhar o gráfico de tráfego dos pontos de troca em dia de jogo, você vê o degrau a olho nu.

E é por isso que, quando você lê "o YouTube não está aguentando, travou aqui pra mim", na maioria das vezes — e eu não posso afirmar 100% sem análise de rede caso a caso — o que não aguentou foi o roteador do provedor local. Pensa num provedor pequeno: mil clientes, link pequeno, um roteador de 10 Gb que não foi feito pra isso. Todo mundo ligou junto. Travou. A culpa foi parar no Google.

Quem quiser entender por dentro como esse jogo de bloco de IP, ASN e peering funciona — e por que ele é caro —, eu contei a minha própria via crúcis em como é comprar um bloco de IPv4 no mercado de hoje.

Etapa 7 — o seu aparelho também atrasa (e isso você testa hoje)

Falta o último elo, e esse aqui você comprova em casa sem instalar nada. Pegue o seu telefone e a sua Smart TV na mesma rede e ligue os dois no mesmo jogo. O telefone quase sempre vai estar na frente.

Por quê? Os formatos que eu citei — HLS, H.264 — são de compactação: compacta-se de um lado, transporta-se, descompacta-se do outro. Quem descompacta é processador, GPU, memória. E o processamento de Smart TV é infinitamente menor que o de um telefone atual. Quanto maior a qualidade e maior o bitrate, mais tempo a TV gasta pra decodificar. Nesse fluxo, a Smart TV sempre perde. Some a isso o player do celular, que costuma ter aceleração e um buffer menor.

Baixa latência existe — só não nessa escala

Pra não deixar dúvida: dá pra transmitir com pouco atraso. Eu tenho serviço de stream de baixa latência que chega a 2 segundos. Pra leilão, aula, evento de alguns milhares de pessoas, é tranquilo. O próprio YouTube tem essa função.

E a documentação dele explica por que a Copa não usa isso. A página oficial de latência do YouTube diz que, na latência baixa, a maioria dos espectadores fica abaixo de 10 segundos, e na ultrabaixa, abaixo de 5. Só que ela avisa, na mesma página, que nenhuma das duas suporta 4K e que a ultrabaixa aumenta a chance de o espectador travar e faz qualquer problema de ingestão na sua rede bater muito mais forte no público.

Ou seja: a escolha não é entre "atraso" e "sem atraso". É entre atraso e travamento. Pra 21 milhões de dispositivos ao mesmo tempo, não tem tecnologia disponível no mercado hoje, pra dar o play e usar, que entregue latência baixa nessa escala. Não dá. O que sustenta a escala é justamente o cache espalhado pela rede — e cache é tempo.

Nota de cronologia (importante)

Eu gravei em 5 de julho de 2026, no meio da Copa, e escrevi este texto em 27 de setembro de 2026 — quase três meses depois. Então vale atualizar dois pontos, e isso é honestidade de cronologia, não enfeite.

O número que eu citei no ar estava certo pra época: a CazéTV bateu 21 milhões de dispositivos simultâneos em Brasil × Japão, recorde mundial do YouTube na ocasião, noticiado em 29/06/2026. Depois da minha gravação o recorde subiu de novo, e a marca da Copa ficou ainda maior. Ou seja: o problema de escala que eu descrevi não diminuiu, aumentou.

E a extensão continua lá, com cerca de 100 mil instalações e nota alta na loja. Isso não a torna correta — torna o mal-entendido popular. As pessoas instalam, ganham alguns segundos, veem travar e acham que é a internet delas.

Uma ressalva final de honestidade técnica: eu simplifiquei muito este desenho. Quem é engenheiro de rede de verdade sabe que eu comi um monte de coisa no caminho — tem codec, tem detalhe de protocolo, tem redundância geográfica em cada ponto, porque qualquer um desses elos pode cair e o sinal tem que vir de outro lugar sem ninguém perceber. Se eu fosse detalhar tudo, o vídeo teria três horas e este texto não acabaria.

Perguntas frequentes

Resumindo o que eu levo disso: o usuário não faz a menor ideia de nada que eu escrevi aqui — ele só quer assistir o jogo e gritar gol. E está certo. Ninguém vê essa engenharia acontecendo por trás dos panos, e quando ela funciona, ninguém comenta. Isso aqui é o suprassumo da engenharia de rede, e é um mercado fantástico. Eu me apaixonei por isso quando fui ser hands-on de verdade, quando fui aprender as coisas na marra. Infraestrutura virou o superpoder da vez, e quem entende disso não fica sem trabalho.

E se você é consultor, é empresário, quer ter nuvem própria ou só quer aprender a construir um negócio desses — é exatamente disso que eu trato na Imersão de Infraestrutura, presencial em São Paulo. Valor, data e condição ficam na página dela, que é onde essa informação está certa. Um abraço, e até a próxima.

Baseado na gravação do canal @josimarjmv publicada em 05/07/2026 (27min49), com transcrição própria das legendas do próprio vídeo. São da minha vivência e foram ditos na gravação: trabalhar com streaming há mais de 20 anos, ter um CDN de entrega de vídeo, ser dono de empresa que vende plataforma e ainda ser hands-on cuidando dessa infraestrutura; a irritação com a notícia de que uma extensão de navegador acabaria com o delay da live; a cadeia de captação com N câmeras por NDI, HDMI, Wi-Fi ou link, o switcher, a ilha e o computador que grava, e a observação de que esse pedaço do atraso é compartilhado com a TV aberta e o satélite; o checklist de sincronismo entre câmera, switcher, placa de captura e encoder, e o caso do jogo de Champions com áudio dessincronizado do vídeo numa Smart TV Samsung na hora do anúncio; a ordem de configurar de trás pra frente, a partir do que a plataforma recomenda; o ingest em RTMP e RTMPS, também servido em 443 e 80 por causa de rede que bloqueia porta alta, e a existência de ingest HLS e DASH; a transcodificação em tempo real de 4K a 18–20 Mbps para 1080p, 720p, 360p e 180p, com a analogia do tempo de renderizar um vídeo no computador de casa; o fatiamento do fluxo contínuo em chunks de HLS ou DASH; o buffer de cerca de 20 segundos dos players e a adaptação automática de qualidade; a explicação de que a extensão atua só no buffer do navegador e que tirar buffer trava; a existência de stream de baixa latência com até 2 segundos na minha empresa e a impossibilidade de usar isso em escala de dezenas de milhões; os 130 ms de fibra pura entre Brasil e Estados Unidos no melhor trânsito IP, medidos por quem tem data center nos dois países; a saturação do link de trânsito do provedor local com o exemplo de 10 Gb contratados e 1.000 assinantes a 10 Mbps; o Google Global Cache instalado dentro do provedor, sob NDA, e o fluxo fino que vira distribuição local; o IX e o ponto de troca de tráfego como alternativa para quem não tem GGC, com o de São Paulo como o maior; a avaliação de que travamento em dia de jogo costuma ser o roteador do provedor local, e não o YouTube, com a ressalva explícita de que não dá pra afirmar 100% sem análise de rede caso a caso; a diferença de decodificação entre Smart TV e celular na mesma rede; a necessidade de redundância geográfica em cada elo; e o convite para a imersão presencial de infraestrutura em São Paulo. É apuração minha, feita em 27/09/2026, e não estava na gravação: a identificação da extensão como ZeroDelay, na loja do Chrome, com a descrição do próprio autor de que ela acelera a reprodução em 1.25x para consumir o conteúdo já baixado e que evita acelerar quando o buffer está baixo, além das cerca de 100 mil instalações registradas na loja; a recomendação oficial de encoder do YouTube, com 44,1 kHz para estéreo e 48 kHz para 5.1 (que corrige o número que eu dei de cabeça), áudio em AAC ou MP3 e intervalo de quadro-chave recomendado de 2 segundos e máximo de 4 (que me confirma); a porta padrão 1935/TCP do RTMP, que corrige o número que eu troquei no quadro; a página oficial do HTTP Live Streaming da Apple, com a frase "dynamically adapts to network conditions by optimizing playback for the available speed of wired and wireless connections"; a documentação do Google Global Cache, com "allows ISPs to serve certain Google content from within their own networks", a faixa de 70% a 90% do tráfego cacheável e o efeito de reduzir tráfego nos links de peering e trânsito; a informação do IX.br de que hoje são 40 pontos de troca de tráfego alcançando todos os estados, que corrige o meu "não tem IX no país inteiro"; a documentação de latência do YouTube, com menos de 10 segundos na latência baixa, menos de 5 na ultrabaixa, sem suporte a 4K em nenhuma das duas e aviso de maior chance de travamento na ultrabaixa; e o recorde de 21 milhões de dispositivos simultâneos em Brasil × Japão, noticiado em 29/06/2026. Sobre a minha imersão eu não repito preço, data nem condição aqui: essa informação é final e fica na página da Imersão de Infraestrutura.