O que é SRT no streaming? SRT e RTMP: as diferenças explicadas
O SRT é um protocolo de transporte de vídeo criado para resistir a redes instáveis. Veja como ele recupera pacotes perdidos, o que faz a configuração de latência, como se compara ao RTMP e por que a maioria das plataformas ainda pede RTMP.
Nesta página
O SRT (Secure Reliable Transport) é um protocolo de código aberto para enviar vídeo ao vivo por redes imprevisíveis, como a internet pública. Ele roda sobre UDP, pede de novo os pacotes que se perdem, permite escolher quanto atraso trocar por confiabilidade e pode criptografar a transmissão. Emissoras o usam para levar sinais de alta qualidade entre locais.
Ele não substitui o RTMP em todos os casos, mas resolve muito bem problemas específicos. Veja como ele funciona e quando vale a pena usá-lo.
Principais pontos
- O SRT usa UDP e recupera pacotes perdidos dentro de uma janela de latência definida por você.
- Ele é ideal para links de longa distância ou com perdas, como locais remotos e sinais de contribuição.
- A maioria das plataformas para criadores ainda documenta ingestão via RTMP ou RTMPS.
- A criptografia AES com uma senha compartilhada protege os sinais SRT durante o trajeto.
De onde veio o SRT e qual problema ele resolve
O SRT foi desenvolvido pela empresa de vídeo Haivision e lançado como código aberto em 2017. Hoje ele é compatível com uma grande variedade de encoders, decoders, servidores de mídia e softwares, incluindo o OBS e o FFmpeg.
O problema que ele ataca é fácil de descrever: a internet pública perde pacotes e os entrega fora de ordem, principalmente em longas distâncias, em Wi-Fi congestionado ou em conexões de celular. Os links de transmissão tradicionais evitavam isso com circuitos dedicados ou capacidade de satélite. O SRT busca entregar confiabilidade de nível broadcast por conexões de internet comuns.
Ele faz isso sem se importar muito com o que está dentro da transmissão. O SRT é um transporte, não um formato de vídeo, e o mais comum é que ele carregue um MPEG transport stream com vídeo H.264 ou HEVC e áudio AAC. Essa flexibilidade ajudou os fluxos de trabalho profissionais a adotá-lo rapidamente.
Como funcionam a recuperação de pacotes e o buffer de latência
O RTMP funciona sobre TCP, que retransmite os dados perdidos, mas deixa a conexão inteira mais lenta sempre que detecta uma perda. Em links de longa distância com perdas, isso aparece como travamentos e buffering.
O SRT usa UDP e cuida da recuperação por conta própria. O receptor guarda os pacotes em um buffer curto. Quando percebe uma lacuna na sequência, ele pede ao emissor que reenvie apenas o pacote que falta. Se a reposição chega antes de aquele trecho de vídeo sair do buffer, ninguém mais adiante percebe.
O tamanho do buffer é a configuração de latência. Valores maiores toleram redes piores ao custo de mais atraso; valores menores mantêm o atraso baixo, mas descartam os pacotes que chegam tarde demais. Um ponto de partida comum é algumas vezes o tempo de ida e volta entre emissor e receptor, aumentado em links instáveis. As ferramentas expressam a latência em unidades diferentes, então confira a documentação.
Criptografia, stream IDs e modos de conexão
O SRT inclui recursos que o RTMP não oferece sozinho:
- Criptografia. AES com uma senha compartilhada pelos dois lados, usando chaves de 128, 192 ou 256 bits. O RTMP precisa da variante separada RTMPS para ser criptografado.
- Stream ID. Um identificador opcional que permite que uma única porta do receptor aceite vários sinais e encaminhe cada um corretamente, mais ou menos como uma chave de transmissão.
- Modos de conexão. Um lado escuta em uma porta e o outro a chama. Um terceiro modo, o rendezvous, faz os dois lados se conectarem ao mesmo tempo, o que pode ajudar quando os dois estão atrás de firewalls.
Como o SRT usa UDP, a porta UDP do lado que escuta precisa estar aberta em todos os firewalls do caminho, ao contrário das conexões TCP de saída do RTMP. Para o lado do RTMP, veja como o RTMP funciona e RTMP ou RTMPS.
SRT ou RTMP: onde cada um se sai melhor
Nenhum dos protocolos é simplesmente melhor; eles são bons em tarefas diferentes.
- O SRT vence na contribuição. Enviar um sinal de um local remoto, de uma equipe externa ou de um link de celular de volta para uma central de produção é onde a recuperação de pacotes compensa, assim como nas cadeias de broadcast que alimentam sistemas de playout, decoders e servidores de mídia.
- O SRT lida melhor com a distância. Em links intercontinentais com perdas e jitter, um buffer de latência bem ajustado costuma dar resultados mais estáveis do que o RTMP baseado em TCP.
- O RTMP vence na compatibilidade. Quase todo encoder, serviço e plataforma é compatível com ele, e a configuração se resume a uma URL e uma chave.
- O RTMP é mais simples de implantar. Não há portas UDP, ajuste de latência nem senhas para coordenar.
Uma regra prática: use SRT entre sistemas que você ou um parceiro controlam, e RTMP ou RTMPS no último trecho até as plataformas públicas.
Por que YouTube, Twitch e a maioria das plataformas ainda pedem RTMP
Se o SRT é tão resistente, por que as grandes plataformas para criadores continuam documentando a ingestão via RTMP e RTMPS?
Primeiro, compatibilidade: as plataformas querem que qualquer streamer consiga se conectar, dos apps de celular aos encoders de hardware mais antigos, e o RTMP é o protocolo que todos eles falam. Segundo, a maioria dos criadores transmite de casa para um servidor de ingestão próximo, onde o TCP funciona bem o bastante. Terceiro, as plataformas construíram anos de autenticação, gestão de chaves e monitoramento em torno do RTMP.
Esse cenário está mudando. Algumas plataformas e muitos serviços de vídeo profissionais aceitam SRT ou outros protocolos de ingestão mais novos. No momento em que escrevemos, porém, uma plataforma social ou de games convencional normalmente vai entregar a você uma URL RTMP ou RTMPS. O guia de RTMP personalizado explica como esses destinos funcionam.
Enviando RTMP e SRT a partir da mesma transmissão na nuvem
Muitas configurações precisam dos dois protocolos ao mesmo tempo: RTMP para as plataformas públicas e SRT para um estúdio, um servidor de playout ou o receptor de um parceiro. A partir de um encoder em casa, isso significa duas saídas e o dobro do upload.
O StreamHouse resolve isso na nuvem. Adicione YouTube, Twitch ou Kick via RTMP ou RTMPS, mais uma saída SRT personalizada apontada para o seu receptor, à mesma transmissão. Uma única live chega a todos eles, e os destinos extras não consomem slots de transmissão extras.
Para programação pré-gravada, faça o upload dos seus vídeos, que são preparados com antecedência em um único perfil de codificação consistente, depois monte uma playlist e inicie ou agende a transmissão. Ela roda em loop 24/7, reconecta automaticamente depois de falhas de rede e continua no ar com o seu computador desligado.
Perguntas frequentes
O SRT é melhor que o RTMP para transmissão ao vivo?
Em trajetos de rede longos ou instáveis, geralmente sim, porque o SRT recupera pacotes perdidos sem travar a conexão inteira. Mas as plataformas convencionais muitas vezes só oferecem RTMP ou RTMPS, então a escolha certa depende de para onde o seu sinal vai.
O SRT tem latência menor que o RTMP?
Pode ter. O atraso de transporte do SRT é mais ou menos o buffer de latência que você define, que pode ser pequeno em redes boas. Mas o atraso total para os espectadores também depende do processamento e da reprodução da plataforma, então trocar de protocolo nem sempre vai parecer mais rápido.
O OBS consegue transmitir via SRT?
Sim. Digite um endereço srt:// como servidor personalizado no OBS, com parâmetros como modo, latência e senha incluídos na URL. O servidor ou serviço que recebe precisa ser compatível com SRT e estar configurado para aceitar a conexão.
O SRT é criptografado por padrão?
Só quando você define uma senha. Com a mesma senha nos dois lados, o SRT criptografa o sinal usando AES com chaves de 128, 192 ou 256 bits. Sem senha, ele trafega sem criptografia, então defina uma para sinais que atravessam a internet pública.
