Latência de transmissão não é dessincronia labial

Duas reclamações soam quase iguais e não têm nada a ver uma com a outra. "Os espectadores estão vendo atrasado" é latência. "A boca não bate com a voz" é dessincronia. Elas se corrigem em lugares diferentes, por pessoas diferentes, e a primeira coisa útil que você pode fazer é se recusar a tratá-las como um único problema.

Como diferenciar em dez segundos

A distinção que mais importa: latência é um atraso que você pode planejar, e dessincronia é um defeito. Dez segundos de latência são uma decisão de projeto. Duzentos milissegundos de erro de sincronia labial são algo quebrado, com qualquer latência.

Do que é feito o atraso

Latência não é um número único gerado por uma única coisa. É uma soma, e cada parcela pertence a alguém diferente. Saber qual parcela é qual mostra na hora se dá para fazer alguma coisa a respeito.

O seu encoder. Ele precisa juntar quadros suficientes para comprimi-los uns em relação aos outros e depois entregar o resultado. É pouco, e depende principalmente das configurações de buffer do próprio encoder.

O caminho até nós. A distância física mais a proteção que você pediu. Se você usa SRT, a URL carrega um orçamento de latência de no mínimo 500 ms: você comprou explicitamente esse atraso em troca de sobreviver à perda de pacotes, e isso é a troca funcionando como deveria, não um defeito.

Nossa codificação e empacotamento. A transmissão é recodificada na escada de qualidades e cortada em segmentos. O dcast usa segmentos de 4 segundos com intervalo de keyframe de 2 segundos, então um segmento só pode ser publicado quando seus 4 segundos já existem. Na entrega segmentada, essa é a maior parcela da cadeia, e é aritmética, não ineficiência.

A entrega ao espectador. Levar os segmentos até onde o espectador estiver.

O buffer do player. Antes de mostrar qualquer coisa, o player acumula segmentos para que um momento lento na conexão do espectador não vire um travamento visível. É a parcela que a maioria das pessoas nem sabe que existe, e muitas vezes é a maior depois do empacotamento. Um player que guarda três segmentos de 4 segundos está doze segundos atrás do ao vivo antes de desenhar um único quadro, não porque algo esteja lento, mas porque ele decidiu jogar seguro.

O que você consegue reduzir e o que não consegue

Some as parcelas e fica óbvio onde há margem. A física (a distância, a velocidade da rede) você não muda. O buffer do seu encoder é tão pequeno que ajustá-lo raramente compensa o risco. O orçamento de latência do SRT você pode baixar, mas a sua tolerância à perda de pacotes cai exatamente na mesma medida, e, se você estava usando SRT, provavelmente tinha um motivo.

As duas parcelas com margem real são a duração do segmento e o buffer do player, e elas estão ligadas: o player armazena em unidades de segmento, então a duração do segmento se multiplica. No dcast, o lado do player aparece como um modo de latência da transmissão (normal, low ou ultra), e vale ser preciso sobre o que essa configuração é: ela muda quanto o player armazena e não chega ao encoder de jeito nenhum. A grade de codificação é a mesma para todas as transmissões da plataforma.

Esse é o formato honesto da troca. Um buffer mais curto significa que o espectador fica mais perto do ao vivo e tem menos proteção contra as oscilações da própria conexão; um buffer mais longo significa o contrário. Não existe configuração que entregue as duas coisas, e quem diz que um protocolo elimina essa troca só a mudou de lugar, não a eliminou.

Decida o quão ao vivo sua transmissão precisa ser

A maioria das transmissões não precisa de baixa latência, e as que precisam geralmente precisam por um motivo específico, que vale nomear antes de começar a abrir mão de robustez.

Se seus espectadores interagem com você ao vivo (você lê o chat em voz alta, responde perguntas, conduz um leilão), a latência é o produto inteiro, e um espectador vinte segundos atrás está participando de uma conversa diferente da sua.

Se seus espectadores podem ver o acontecimento duas vezes (um jogo em que o vizinho grita gol antes, ou qualquer situação em que uma notificação no celular pode chegar antes da sua transmissão), a latência é um problema de spoiler.

Se nenhum dos dois se aplica, e na maioria das transmissões não se aplica, um buffer folgado é a melhor escolha de engenharia, porque a falha que ele evita (um travamento no meio da palestra) é mais visível para o espectador do que estar dez segundos atrás de um evento que ele não tem como ver de outra forma.

A latência que você mesmo adiciona

Antes de culpar a entrega, vale contar o atraso que existe dentro da sua própria sala, porque ele costuma ser maior do que se imagina, e é a parte que você realmente consegue eliminar.

Cada equipamento por onde o sinal passa custa alguma coisa. Uma câmera, um conversor, um switcher, um scaler, um segundo switcher alimentando um projetor: cada um segura a imagem por um instante enquanto faz seu trabalho. Uma cadeia de quatro equipamentos são quatro atrasos, e nenhum deles está documentado em algum lugar fácil de achar.

Links sem fio custam mais que os cabeados. Um transmissor de vídeo sem fio precisa empacotar, proteger e remontar; essa proteção é exatamente a mesma troca de um orçamento de latência do SRT, só que feita por um equipamento em vez de por você.

Um relay custa uma viagem completa. Se o seu sinal vai do local do evento para um escritório e de lá para a plataforma, você paga os dois trechos mais o que a caixa do meio fizer. É comum descobrir que a "latência do streaming" de que alguém reclama é, na maior parte, um salto que existe por razões históricas.

O jeito de encontrá-la é colocar um relógio na frente da câmera e fotografar o relógio junto com cada tela ao longo da cadeia: o monitor da própria câmera, a saída de programa do switcher, o preview do encoder. Cada etapa mostra quanto aquele estágio custou. Muitas vezes um único equipamento acaba sendo responsável pela maior parte, e tirá-lo do caminho é mais rápido e mais barato que qualquer mudança de configuração mais adiante.

Sincronia labial é um defeito completamente diferente

Agora, a outra reclamação. Se a voz e os lábios não batem, mudar as configurações de latência não vai ajudar, porque o áudio e o vídeo viajam juntos: a transmissão empacotada inteira chega atrasada como uma coisa só. Um erro de sincronia significa que os dois já estavam desalinhados quando chegaram, ou que algo os separou.

Quase sempre isso acontece antes do encoder. Som e imagem chegam ao seu encoder por equipamentos diferentes, e equipamentos diferentes levam tempos diferentes.

Normalmente o vídeo é o mais lento. A câmera processa e redimensiona, a placa de captura converte, o switcher compõe. Cada etapa custa um pouco. O áudio, por outro lado, costuma chegar por um caminho bem mais curto: um microfone direto em uma interface.

Por isso a correção usual é atrasar o áudio, e não adiantar o vídeo, porque não dá para adiantar nada: a imagem já está o mais cedo que vai estar. Quase todo switcher e toda interface de áudio oferecem um atraso de áudio justamente por isso.

Meça antes de ajustar. Bata uma palma na frente da câmera e do microfone ao mesmo tempo, grave a saída de programa e veja onde a palma cai em cada faixa. Assim você tem um número em vez de um chute, e esse número costuma ser estável para uma mesma cadeia de equipamentos, então você ajusta uma vez só.

Quando a diferença cresce durante a transmissão

Uma diferença fixa é chata, mas fácil. Uma diferença que começa pequena e uma hora depois já tem um segundo é um defeito diferente, e ajustes de atraso não vão segurá-la.

Isso é um problema de clock. Seu equipamento de áudio e seu equipamento de vídeo contam o tempo cada um com o próprio oscilador, e, se eles discordam mesmo que por uma fração minúscula, a diferença se acumula enquanto você estiver no ar. Uma diferença de apenas 0,01% já dá um terço de segundo por hora.

A solução é fazer os dois compartilharem um clock, e não corrigir o sintoma. Quando o seu equipamento permitir, alimente áudio e vídeo a partir de uma única referência. Quando não permitir (o caso comum em equipamentos de consumo), prefira caminhos que mantenham os dois juntos: áudio embutido no sinal de vídeo via HDMI ou SDI, ou capturado pelo mesmo dispositivo que captura o vídeo, em vez de uma interface de áudio separada com o próprio cristal.

Se nenhuma das duas opções estiver disponível, a mitigação prática é manter cada transmissão curta o bastante para que o erro acumulado fique abaixo do ponto em que alguém percebe, e realinhar entre os blocos.

Uma ordem de diagnóstico que funciona

Antes de qualquer coisa, verifique a sua própria saída de programa, na sua própria máquina. Se a sincronia já está errada ali, nada mais adiante causou o problema e nenhuma configuração da plataforma vai consertá-lo.

Se a saída local estiver correta, verifique uma gravação da transmissão entregue. Sincronia certa localmente e errada mais adiante é algo realmente incomum e vale ser reportado, porque não é problema de configuração.

Só depois de confirmar que a sincronia está correta é que você deve olhar para a latência. Corrigir o atraso enquanto o áudio está descompassado só te dá uma transmissão errada mais rápida.

E meça a latência do jeito que o espectador a vive, não pelas estatísticas do seu encoder: coloque um relógio na tela, assista à transmissão em um dispositivo que não tenha nada a ver com a produção e fotografe os dois. Esse número inclui o buffer do player, que é a parcela que o seu encoder não enxerga e que muitas vezes é a maior.