Live streaming (Twitch)

01 · CONTEXTO E REQUISITOS

Dois caminhos num só produto: vídeo e chat

Uma plataforma de transmissão ao vivo recebe vídeo de quem transmite e o entrega, ao vivo, a muitos espectadores. A Twitch descreve, em um post de engenharia, um pico de dezenas de milhares de transmissões simultâneas entregues a espectadores no mundo todo. Quem transmite envia o vídeo por RTMP, e para escalar a entrega a muitos espectadores a Twitch usa HLS.

Para estudar o problema, vale separar dois caminhos: o do vídeo, que leva muitos bytes de um transmissor a muitos espectadores, e o do chat, em que cada espectador também envia mensagens. Os dois têm exigências diferentes e são desenhados separadamente.

02 · DO INGEST AO PLAYER

O caminho do vídeo

O RTMP foi projetado para transmitir vídeo e áudio pela internet e é usado principalmente em comunicação ponto a ponto. Já o HLS entrega o vídeo por HTTP e é compatível com a infraestrutura de cache HTTP de larga escala, o que apoia a entrega a grandes audiências.

No meio do caminho fica o transcodificador. Ele converte o fluxo RTMP recebido em HLS com várias variantes, cada uma com um bitrate diferente, para que espectadores com larguras de banda diferentes assistam na melhor qualidade possível para a sua conexão. Uma playlist mestre reúne as variantes, e o player alterna entre elas para se adaptar à rede.

1. O software de transmissão envia o vídeo ao servidor de ingest por RTMP.

2. O transcodificador converte o fluxo RTMP recebido em HLS, com várias variantes de bitrate.

3. Neste desenho, os segmentos e as playlists de cada variante são gravados numa origem, de onde a CDN os busca.

4. Neste desenho, a borda da CDN guarda playlists e segmentos em cache e atende os players; o HLS é compatível com a infraestrutura de cache HTTP.

5. O player recebe a playlist mestre e alterna entre as variantes para se adaptar às condições de rede.

Esta primeira versão mostra o fluxo inteiro, mas deixa em aberto o que acontece dentro do transcodificador.

03 · TRANSCODIFICAÇÃO

Variantes alinhadas e o custo do transcodificador

Transcodificar custa em dois sentidos. A compressão H.264 tem perdas, então recodificar degrada a qualidade do vídeo, e codificar é um processo computacionalmente muito caro, em especial com alta resolução e alta taxa de quadros. Por isso a Twitch diz que o ideal seria fazer transmux, isto é, repassar sem decodificar e recodificar, a variante mais alta, poupando computação e preservando a qualidade.

O problema do transmux é o alinhamento. A especificação HLS exige que os quadros IDR dos segmentos correspondentes de cada variante estejam alinhados, com o mesmo Presentation Timestamp, e é isso que permite ao player trocar de variante sem emendas quando a rede muda. Só que o intervalo de IDR do fluxo de origem é definido pela configuração do software de transmissão, fora do controle da plataforma. Se a fonte sofre apenas transmux, não há garantia de que os segmentos das variantes alinhem, e a Twitch observou pausas de reprodução no Chromecast com segmentos desalinhados.

1. O ingest recebe o fluxo RTMP e o entrega aos dois caminhos de processamento.

2. A variante mais alta só é repassada, sem recodificação: poupa computação e preserva a qualidade.

3. As demais variantes são recodificadas, e o encoder consegue forçar o IDR em intervalos fixos.

4. Na origem, não há garantia de que os segmentos da variante repassada alinhem com os das recodificadas.

5. O alinhamento que permite trocar de variante sem emendas não é garantido; a Twitch relata pausas de reprodução no Chromecast com segmentos desalinhados.

Há ainda o custo de gerar várias variantes. A forma mais simples é criar N transcodificadores independentes, um por variante, mas o ideal seria eliminar os decoders redundantes e alimentar o resto do pipeline com as imagens decodificadas por um só. O redimensionamento também é caro, e evitar repeti-lo sem necessidade melhora de forma significativa o desempenho. Como encoder e scaler são muito caros, a Twitch destaca o uso de CPUs multi-core para processar várias variantes ao mesmo tempo.

O FFmpeg não atende a alguns requisitos técnicos específicos da operação da Twitch, e a série de posts explica por que ela constrói seu próprio transcodificador. Com transcodificador e player próprios, a empresa controla o pipeline completo de ingest, transcodificação, CDN e reprodução.

04 · PLAYLIST AO VIVO

Como o player acompanha um fluxo sem fim

Numa transmissão ao vivo a playlist não é fixa: o cliente precisa recarregá-la periodicamente para saber qual mídia está disponível, descobrindo os segmentos adicionados. Pelo RFC do HLS, se a playlist mudou o cliente espera ao menos a duração-alvo antes de recarregar; se não mudou, espera metade da duração-alvo antes de tentar de novo.

Do lado do servidor, enquanto a transmissão não termina, cada nova versão da playlist deve trazer ao menos um segmento novo e sair entre meia e uma vez e meia a duração-alvo depois da anterior. O servidor pode limitar a disponibilidade de segmentos removendo-os da playlist, mas o segmento removido precisa continuar disponível por um tempo, para não interromper quem ainda o reproduz.

1. O player pede a playlist da variante à borda da CDN.

2. Neste desenho, a borda busca na origem a playlist e os segmentos que ainda não tem em cache.

3. O servidor publica novas versões da playlist, cada uma com ao menos um segmento novo.

4. O player espera ao menos a duração-alvo antes de recarregar a playlist e, se ela não mudou, metade da duração-alvo.

O player, por sua vez, não deve escolher um segmento que comece a menos de três durações-alvo do fim da playlist, porque isso pode causar travamentos. Também não deve recarregar playlists de variantes que não está tocando, para reduzir a carga no servidor.

05 · CHAT

Conexões longas, rajadas e limites

Para o chat, o RFC do WebSocket resume o problema anterior: aplicações bidirecionais exigiam abusar do HTTP com polling para receber atualizações e chamadas HTTP separadas para enviar, e cada mensagem do cliente ao servidor carregava um cabeçalho HTTP. A proposta é uma única conexão TCP para o tráfego nos dois sentidos.

O chat da Twitch é exposto como uma interface IRC baseada em um RFC1459 modificado e na especificação de tags do IRCv3, e clientes WebSocket se conectam por wss na porta 443. A documentação recomenda usar assinaturas EventSub e chamadas de API em vez do IRC, que tem limitações e é mais complicado de interpretar.

Conexões longas pedem manutenção. O servidor envia PING para saber se o cliente está vivo e encerra a conexão se não receber PONG. Quando precisa encerrar por manutenção, ele envia RECONNECT, e o caminho normal é reconectar e reentrar nos canais. A documentação avisa ainda que a ordem das mensagens não é garantida e que uma mensagem pode ser enviada mais de uma vez.

1. Cada espectador mantém uma conexão persistente com um servidor de chat, escolhido pelo balanceador de conexões.

2. Ao receber uma mensagem, o servidor consulta o estado da sala, por exemplo se o modo lento está ativo.

3. Neste desenho, se a mensagem passa pelas regras da sala, o servidor a publica no barramento da sala.

4. Neste desenho, o barramento entrega a mensagem a todos os servidores com espectadores da sala, e cada um a repassa aos seus clientes.

5. Em manutenção, o servidor envia RECONNECT; o caminho normal do cliente é reconectar e reentrar na sala.

O chat também tem limites. Mensagens enviadas em rápida sucessão são descartadas em silêncio pelo servidor, que pode até fechar a conexão. Em salas com mais de mil usuários, o bot deixa de receber as mensagens JOIN e PART. E moderadores podem ativar configurações da sala, como o modo lento e o modo só para seguidores, que o servidor anuncia com ROOMSTATE.

06 · RESUMO

Dois caminhos, dois protocolos