SRTLA vs SRT vs RTMP: qual é o melhor protocolo para streaming IRL?

Para streaming IRL, o SRT costuma ser mais indicado do que o RTMP, e o SRTLA é a melhor opção quando você consegue enviar por várias conexões ao mesmo tempo. O RTMP continua sendo necessário porque as plataformas de streaming o esperam, mas o lugar dele é no último trecho estável entre um servidor e a plataforma, não em uma rede móvel.

Este guia explica como funcionam os três protocolos, como eles se comportam em conexões móveis e como definir corretamente a latência SRT.

O que é o RTMP?

O RTMP (Real-Time Messaging Protocol) foi especificado pela Adobe e publicado como especificação aberta em 2009. Ele foi projetado para funcionar sobre um transporte confiável como o TCP, que garante que todas as mensagens cheguem em ordem (especificação RTMP). O rascunho do IETF para o SRT chama o RTMP de padrão de fato para contribuição pela internet pública, e é por isso que praticamente todos os encoders, apps e plataformas o suportam.

O ponto fraco vem do mesmo design. Como o RTMP depende do TCP, ele só oferece uma confiabilidade aceitável em conexões com um tempo de ida e volta baixo, e o controle de congestionamento do TCP o impede de aproveitar toda a banda de uma conexão. É uma combinação pouco adequada para um celular que passa de uma antena para outra.

O RTMP clássico também tem limites de codecs: ele só suporta dois canais de áudio e um conjunto restrito de codecs, sem HEVC, VP9 nem AV1. A especificação Enhanced RTMP adiciona esses codecs, e o YouTube já indica H.264, H.265 e AV1 para RTMP(S). Mas tanto o seu software quanto a plataforma precisam suportá-lo. O RTMPS é o RTMP dentro de uma conexão SSL criptografada, e o YouTube o recomenda justamente por isso.

O que é o SRT?

O SRT (Secure Reliable Transport) é um protocolo de código aberto desenvolvido no repositório público do GitHub da Haivision e descrito em um Internet-Draft do IETF. Ele funciona sobre UDP e adiciona a confiabilidade que o UDP, sozinho, não tem. O método principal é o ARQ (Automatic Repeat reQuest): quando o receptor percebe que falta um pacote, ele pede ao emissor que envie esse pacote de novo. O protocolo também suporta Forward Error Correction e o seu próprio bonding de conexões.

Três propriedades são importantes para streaming IRL:

• Buffer de latência: O receptor retém cada pacote por um tempo configurado antes de repassá-lo. Essa janela dá tempo para os pacotes perdidos serem retransmitidos e reproduz a temporização original da stream. Pacotes que chegam tarde demais podem ser descartados, para que o atraso se mantenha constante em vez de crescer.
• Criptografia: O SRT suporta criptografia AES com chaves de 128, 192 ou 256 bits.
• Independência de codec: O SRT é agnóstico quanto ao conteúdo transportado. Ele transporta qualquer codec, resolução ou taxa de quadros, incluindo HEVC.

O compromisso já vem embutido. O buffer acrescenta atraso de propósito, então você precisa escolher um valor de latência adequado à sua rede (mais sobre isso abaixo).

O que é o SRTLA?

O SRTLA é um proxy de transporte SRT com agregação de conexões. Ele nasceu no projeto BELABOX e transporta tráfego SRT por várias conexões de rede para obter mais capacidade e redundância. O tráfego é balanceado dinamicamente conforme as condições da rede, e o uso previsto é o bonding de modems móveis para transmissão ao vivo.

O SRTLA não substitui o SRT. Ele fica entre o emissor e o receptor SRT: o seu dispositivo envia a stream SRT, por exemplo, por dois chips ou por um chip mais Wi-Fi, e um receptor que entenda SRTLA junta os pacotes de novo e os entrega como uma stream SRT normal. Disso resultam três consequências práticas:

• Você precisa de um emissor compatível com SRTLA. O app gratuito para iOS Moblin, por exemplo, consegue usar ao mesmo tempo uma conexão celular, uma conexão Wi-Fi e várias conexões Ethernet. O IRL Pro e os dispositivos BELABOX também oferecem bonding SRTLA.
• Você precisa de um receptor SRTLA. Uma plataforma de streaming ou um simples listener SRT não consegue fazer isso, então é preciso haver no meio um servidor com entrada SRTLA.
• Exige ajuste fino. Os pacotes chegam fora de ordem pelas diferentes conexões. Por isso, o README exige opções no receptor como lossmaxttl e uma latência adequada.

RTMP vs SRT vs SRTLA em resumo

Por que as plataformas querem RTMP e por que há um servidor no meio

A documentação de encoders das grandes plataformas ainda gira em torno do RTMP. O YouTube indica RTMP/RTMPS como protocolo do encoder (o HLS é a alternativa), e a documentação para desenvolvedores da Twitch descreve o envio da stream para a Twitch por RTMP. Por isso, na maioria dos casos você não pode apontar SRT e SRTLA diretamente para uma plataforma.

Um servidor resolve isso e traz uma segunda vantagem. A cadeia é assim:

1. O seu celular ou encoder envia SRT ou SRTLA (ou RTMP) para um servidor.
2. O seu software de streaming, como o OBS Studio, busca a stream nesse servidor.
3. O OBS envia a stream final para a plataforma por RTMP(S), por meio de uma conexão estável.

O trecho móvel fraco usa o protocolo mais tolerante, e a plataforma recebe o protocolo que espera, por uma conexão que não está em movimento. Se o sinal móvel cair por instantes, o OBS continua transmitindo para a plataforma, então a stream não termina para os seus espectadores. Tanto o seu encoder quanto o OBS se conectam ao servidor de dentro para fora, então você não precisa abrir portas no roteador.

É isso que o nosso IRL Endpoint Server faz por você, com o OBS no seu próprio PC. Ele aceita RTMP, SRT e SRTLA como entrada. Se você não tem um PC para streaming, o IRL Broadcasting Server executa o OBS Studio na nuvem e aceita as mesmas três entradas. Para ter uma visão mais ampla de uma configuração IRL, veja o nosso guia de streaming IRL.

Como definir a latência SRT

A latência SRT não é o atraso total entre a câmera e o espectador. Na documentação da Haivision, ela descreve apenas o atraso introduzido pelo envio pela rede. A codificação, a decodificação, o OBS e a plataforma se somam a isso. O que a configuração realmente determina é o tempo extra que o receptor espera para compensar pacotes atrasados e retransmissões.

A base de conhecimento do OBS dá uma regra prática para a opção mais importante:

• O valor padrão é 120 ms.
• O valor deve ser pelo menos 2,5 vezes o tempo de ida e volta entre o encoder e o servidor, em milissegundos.
• Em uma URL no estilo FFmpeg, que é o que o OBS usa, a unidade é o microssegundo. Uma latência de 1 segundo se escreve latency=1000000.

Exemplo: se um ping para o seu servidor mostrar um tempo de ida e volta de 80 ms, a regra dá um mínimo de 200 ms, então você digitaria srt://SERVER:PORT?latency=200000. Use o endereço e a porta exatos do seu portal do cliente. No OBS, essas opções podem ser acrescentadas à URL SRT de uma fonte de mídia ou de um destino de stream personalizado.

Para streams para os nossos servidores, recomendamos uma latência de 2 segundos. Dependendo do app, você informa 2000 (milissegundos) ou 2000000 (microssegundos). Na maioria dos apps existe um campo próprio. Se não existir, adicione-a à URL SRT, por exemplo srt://<server>:<port>?streamid=publish:publish/<streamkey>&latency=2000. Um valor mais baixo é possível, mas recomendamos 2 segundos de propósito, em favor da estabilidade.

Algumas coisas para ter em mente:

• As unidades variam. A biblioteca SRT e o README do SRTLA usam milissegundos, enquanto as URLs no estilo FFmpeg usam microssegundos. Verifique qual unidade o seu app espera antes de digitar um valor.
• Os dois lados negociam. Segundo o rascunho do SRT, a latência de uma conexão é o máximo dos valores propostos pelo emissor e pelo receptor. Reduzi-la em um dos lados não adianta se o outro lado pedir mais.
• Streams móveis e em bonding precisam de folga. A regra acima é um mínimo, não uma recomendação. Uma janela maior dá mais tempo para retransmissão e reordenação, mas também aumenta o atraso. O README do SRTLA, por exemplo, usa latency=2000 (ms) junto com lossmaxttl na sua configuração de receptor de exemplo.
• Mude uma coisa de cada vez e teste em movimento, não apenas na sua mesa.

Localização do servidor e latência

Como a latência SRT mínima aumenta com o tempo de ida e volta, a distância conta. Um servidor mais perto de você tem um tempo de ida e volta mais curto, então você pode usar uma janela de latência menor ou obter a mesma estabilidade com menos atraso. A mesma lógica vale para o último trecho: a Twitch, por exemplo, recomenda endpoints de ingest com base no caminho de rede até o seu dispositivo.

Oferecemos servidores nas regiões EUA, Europa, Ásia e América do Sul. Com o IRL Endpoint Server, você pode escolher entre elas no plano Standard e trocar a qualquer momento no portal do cliente, o que ajuda quando você viaja. No plano Dedicated, configuramos um endpoint para você, por padrão na localização mais próxima do seu endereço de cobrança.

Qual protocolo você deve usar?

• Uma conexão, app moderno: use SRT e defina a latência com base no seu tempo de ida e volta.
• Duas ou mais conexões: use SRTLA, se o seu app suportar e o seu servidor aceitar.
• App ou câmera que só fala RTMP: use RTMP. Funciona, mas tolera menos as redes fracas.
• HEVC: o SRT é independente de codec. Confirme que toda a sua cadeia, do encoder ao OBS e à plataforma, suporta o HEVC. Defina o intervalo de keyframes no encoder para 2 segundos e, com HEVC em dispositivos Apple, desative os B-frames se o app permitir.

FAQ

O SRT é melhor do que o RTMP para streaming IRL?

Para o trecho móvel, normalmente sim. O SRT funciona sobre UDP e retransmite os pacotes perdidos dentro de uma janela de latência configurável, enquanto o RTMP depende do TCP e só se mantém confiável em conexões com um tempo de ida e volta baixo. O RTMP continua sendo a escolha comum para a conexão de um servidor ou do OBS com a plataforma.

Qual é a diferença entre SRT e SRTLA?

O SRT é o protocolo de transporte para uma única conexão. O SRTLA transporta tráfego SRT por várias conexões de rede ao mesmo tempo, por exemplo dois chips, para acrescentar capacidade e redundância. O SRTLA precisa de um app compatível com SRTLA e de um receptor que o entenda.

Posso transmitir SRT diretamente para a Twitch ou o YouTube?

A documentação de encoders das duas plataformas se concentra no RTMP(S), com o HLS como alternativa no YouTube. Se você quer usar SRT ou SRTLA no trecho móvel, coloque um servidor e o OBS entre o seu dispositivo e a plataforma.

Qual latência devo definir no SRT?

Para streams para os nossos servidores, recomendamos 2 segundos, informados como 2000 (milissegundos) ou 2000000 (microssegundos), dependendo do app. Um valor mais baixo é possível, mas os 2 segundos são uma escolha deliberada em favor da estabilidade. Como regra geral, a base de conhecimento do OBS indica pelo menos 2,5 vezes o tempo de ida e volta até o seu servidor, com um valor padrão de 120 ms. Redes móveis e conexões em bonding costumam precisar de mais folga, ao custo de mais atraso.

O IRL Endpoint Server suporta os três protocolos?

Sim. O IRL Endpoint Server e o IRL Broadcasting Server aceitam RTMP, SRT e SRTLA como entrada.