A única interação pela qual todo mundo te julga
Um app de TV ao vivo tem cem telas, mas as pessoas julgam ele por uma coisa: a velocidade com que a imagem muda quando apertam a seta pra cima. Se o canal troca na hora, o app parece vivo. Se tem meio segundo de tela preta, parece quebrado — por melhor que seja o resto.
Na web isso é mais ou menos um problema resolvido. Na Smart TV, não. O hardware é um celular de seis anos atrás sem bateria e com uma GPU pior, o motor de JavaScript é antigo, e o garbage collection consegue congelar a interface inteira no meio do zapping. A implementação ingênua — destruir o player, criar um novo, buscar o manifesto, buscar a licença de DRM, bufferizar do zero — empilha quatro round-trips e um decoder frio exatamente no momento em que o usuário está olhando pra tela. Aí está a sua tela preta.
Aqui está o que de fato move o número.
Pare de destruir o player
A maior vitória também é a mais contraintuitiva: não recrie o player a cada troca de canal. Destruir uma instância de player e construir outra joga fora um decoder de vídeo quente e um pipeline de mídia vivo, e depois reconstrói os dois do zero. Num chip de TV limitado, esse destruir-e-reconstruir já é um travamento visível por si só, antes de você ter buscado um único byte do novo stream.
Em vez disso, mantenha uma instância de player de vida longa e entregue uma nova fonte pra ela. A maioria dos SDKs de player maduros (Bitmovin, Shaka, hls.js e afins) tem um load() / loadSource() que troca o stream sem descartar o engine. O decoder continua quente, a surface continua conectada, e você pula a parte mais cara da operação inteira.
Faça prefetch dos vizinhos
Quando alguém está no canal 12, os dois canais que ele tem mais chance de acessar em seguida são o 11 e o 13. Isso não é um palpite que precise de machine learning — são as setas pra cima e pra baixo.
Enquanto o canal atual está tocando e a CPU está ociosa, dá pra preparar de fininho os canais adjacentes: resolver os manifestos deles e, onde o esquema de DRM permitir, pré-adquirir as licenças. Assim, quando a seta realmente for pressionada, a busca do manifesto e o handshake da licença — dois dos seus quatro round-trips — já estão prontos. Você só paga pelo preenchimento do buffer.
Mantenha isso barato e limitado. Faça prefetch de um canal em cada direção, não da grade inteira; cancele os prefetches em andamento no instante em que o usuário se mexer de novo; e nunca deixe um prefetch competir por banda com o stream que está na tela. A ideia é gastar capacidade ociosa, não começar uma segunda guerra de downloads.
Trate um handshake que falha como normal, não como erro
CDNs engasgam. Servidores de licença de DRM dão timeout. Numa conexão instável de sala de estar isso não é a exceção — é terça-feira. A reação errada é mostrar um diálogo de erro no instante em que a primeira requisição falha, porque na maioria das vezes um único retry dá certo antes mesmo de o usuário perceber que houve problema.
Então o caminho da troca de canal precisa de lógica de retry com um backoff curto em volta dos passos frágeis — a requisição de licença e a busca do primeiro segmento. Um par de retries rápidos, e só então um estado de erro de verdade. A diferença entre "faz retry em silêncio" e "estoura na hora" é a diferença entre um app que parece sólido numa noite ruim e um que parece quebrado.
A sutileza é saber o que é retryável. Um 403 numa licença é uma falha de autorização real, e refazer só desperdiça tempo — mostre o erro. Um timeout ou um 503 é transitório — refaça. Deixe essa distinção embutida no tratamento de erro em vez de refazer tudo às cegas.
Mostre algo antes de o vídeo estar pronto
Parte do atraso é real e inevitável — você não consegue renderizar frames que ainda não baixou nem decodificou. Mas a latência percebida é um número separado da latência real, e a percebida você controla.
O truque é nunca mostrar preto. Segure o último frame do canal que está saindo, ou coloque o logo e o nome do canal que está entrando, no instante em que a tecla é pressionada. O buffer continua enchendo por baixo, mas a tela está fazendo algo intencional em vez de apagar. Uma troca de canal que leva o mesmo número de milissegundos parece muito mais rápida quando o vão é preenchido com a marca do canal em vez de um retângulo preto.
Meça o que o usuário realmente sente
Nada disso vale a pena se você não consegue ver se funcionou, e a métrica que importa não é "tempo pra carregar o player" — é o tempo entre a tecla e o primeiro frame: o vão entre o usuário apertar a seta e um frame de verdade do novo canal aparecer.
Dá pra medir isso direto com a User Timing API. Solte um performance.mark() no momento em que o evento de tecla dispara, solte outro quando o player reporta o primeiro frame renderizado da nova fonte, e tire o performance.measure() entre os dois. Agora o tempo de troca de canal é um número que você consegue acompanhar, colocar um orçamento em cima e defender contra regressões — em vez de uma sensação que alguém discute numa review.
Quando vira um orçamento monitorado, cada uma das técnicas acima deixa de ser questão de opinião. Reusar o player, fazer prefetch dos vizinhos, refazer em silêncio, pintar a marca do canal — dá pra ligar cada uma e ver o número se mexer. Em hardware fraco, esse ciclo de feedback medido é o jogo inteiro.