Voltar ao blog

Buffer inteligente: como o player se mantém estável em rede ruim

Por trás do que parece magia: como o WatchHub mede latência, ajusta buffer dinamicamente e reconecta sem o usuário perceber em conexões instáveis.

15 de abril de 20264 min de leitura· Equipe WatchHub

Player de mídia em TV Box opera num ambiente hostil: Wi-Fi compartilhado com outros 5 dispositivos, repetidor mal posicionado, conexão instável que cai por 2 segundos a cada 30. Um player ingênuo entrega esses 2 segundos como travamento visível — tela congelada, ícone de loading, "buffering...".

A versão atual do WatchHub trata esse cenário como o caso normal, não a exceção. Este post explica como.

O que é buffer e por que importa

Buffer é o quanto de mídia já está baixado e pronto para tocar localmente, sem precisar do servidor. Imagine uma fita: o que você está assistindo agora é a parte da fita que está saindo do leitor. O buffer é a fita já enrolada, pronta para passar.

Buffer muito pequeno = qualquer microqueda de rede vira travamento. Buffer muito grande = atraso de 30 segundos entre você apertar play e a imagem aparecer.

A pergunta certa não é "qual o tamanho ideal do buffer", é "como o tamanho do buffer deve mudar ao longo da execução conforme a rede varia".

A estratégia de 3 camadas

Internamente o player do WatchHub trabalha com três alvos de buffer:

  1. Buffer mínimo (5s). Abaixo disso, pausamos a reprodução em vez de mostrar tela travada.
  2. Buffer ótimo (15-20s). Faixa que tentamos manter em condição normal.
  3. Buffer máximo (30s). Teto para não consumir RAM nem antecipar troca de canal.

O ExoPlayer (player de baixo nível usado pelo app) é configurado para abastecer agressivamente quando está abaixo do mínimo, abastecer normal entre mínimo e ótimo, e parar de abastecer acima do máximo. Isso é configuração padrão.

A mágica acontece nas decisões em runtime.

Detecção de rede ruim

A cada 1 segundo, o player mede:

  • Latência média das últimas 10 requisições ao servidor.
  • Throughput estimado comparando bytes recebidos vs. tempo decorrido.
  • Taxa de erro (retentativas de fragmento, timeouts, 5xx).

Se latência sobe ou throughput cai abaixo do necessário para sustentar o bitrate atual, o player antecipa que vai dar problema antes que dê. A reação possível depende do conteúdo:

  • Stream adaptativo (HLS): o player cai para uma resolução menor automaticamente. O usuário vê 720p em vez de 1080p, mas continua assistindo sem corte.
  • Stream de bitrate único: o player aumenta o buffer-target temporariamente para acumular margem de segurança.

Reconexão silenciosa

Quando a conexão cai de fato (TCP error, DNS timeout, socket reset), o player não desiste. Ele:

  1. Mantém o que está no buffer tocando — o usuário não vê nada.
  2. Tenta reconectar com backoff exponencial: 1s, 2s, 4s, 8s, 16s.
  3. Se reconectar antes do buffer esvaziar, retoma silenciosamente do ponto exato.
  4. Se o buffer esvaziar antes da reconexão, mostra um overlay sutil ("reconectando...") em vez de tela preta.
  5. Após 3 tentativas falhadas, oferece trocar de servidor (se o cliente tem fallback configurado pelo revendedor).

Em testes internos com Wi-Fi simulado caindo a cada 20 segundos, o usuário viu interrupção visível em menos de 5% dos cortes — o resto foi absorvido pelo buffer + reconexão.

Por que TV Box importa nesse cálculo

TV Box tem CPU fraca, RAM limitada (1-2 GB típico) e decoder de hardware específico. Buffer agressivo demais consome RAM que o decoder precisa. Buffer pequeno demais força o decoder a trabalhar reativamente, gerando glitches de áudio/vídeo.

A configuração do WatchHub foi calibrada em hardware real: TV Box H96, X96, T95 — os "pretos quadrados" que dominam o mercado. O que funciona em emulador desktop não funciona em TV Box.

O que isso significa para você revendedor

O cliente final raramente vai notar essas decisões. Ele vai notar a ausência delas:

  • Não vai ligar pra reclamar de "travando" — porque não trava.
  • Não vai pedir suporte pra "buffering" — porque o buffer recupera silenciosamente.
  • Vai associar a estabilidade à sua marca, não à sua sorte com a operadora.

Estabilidade em rede instável é a feature mais difícil de demonstrar e a mais fácil de perder. A maioria dos players alheios falha aqui silenciosamente — e o cliente atribui o problema à internet, ao TV Box, à TV, a tudo menos ao app. Investir nessa camada é o que separa player profissional de player amador.

Próximos passos

A próxima evolução é predição baseada em histórico — o player vai aprender o padrão de rede do TV Box específico (manhã estável, noite ruim) e ajustar o buffer-target preventivamente. Hoje a calibração é reativa; em breve será preditiva.

Mas isso fica para outro post.