RTMP, SRT ou WHIP: como escolher o protocolo de ingest

Antes da comparação: o erro que custa a primeira hora de muita gente está na URL do SRT, e ele não gera nenhuma mensagem de erro. Leia a próxima seção mesmo que pule todo o resto.

A falha que parece que nada está acontecendo

Uma URL de ingest SRT traz um streamid com esta cara: #!::r=live/sk_srt_…,m=publish. Esses caracteres — #, !, :, , — são exatamente os que uma pessoa cuidadosa codifica em porcentagem por hábito. Não faça isso. A biblioteca SRT não decodifica o streamid; ela repassa os bytes literais ao servidor. Por isso, um streamid codificado chega como um nome de stream que começa com %23, o servidor trata a conexão como um pedido de reprodução, e não de publicação, e nada é informado a você. Seu encoder mostra uma conexão saudável. O card do stream não mostra sinal. Não há erro em lugar nenhum.

Cole a URL do SRT exatamente como a API a devolve. O dcast a entrega na forma literal, pronta para publicar, em data.ingest.srt no GET /api/v1/streams/:id, e o mesmo valor em data.ingest.srtDisplay, que existe apenas como alias para integrações antigas. Qualquer uma das duas vai direto para o seu encoder, sem reescrever nada.

O que o dcast aceita

Um card de stream pode ser alimentado por qualquer uma destas opções. A escolha é sua, card a card, e não muda a imagem que seus espectadores recebem.

O hostname é sempre a.dcast.pro — o ponto de entrada do pool de roteamento, nunca o nome de um servidor específico. Isso é proposital: significa que o endereço que você configurou uma vez continua funcionando quando o stream cai em outra máquina.

RTMP: o que sempre funciona

O RTMP é antigo, e essa é toda a sua vantagem. Todo encoder, toda câmera com modo de streaming, todo app de celular e qualquer equipamento que te entreguem no local consegue enviar RTMP sem configuração além de um servidor e uma chave. Se você transmite de uma rede estável e não está resolvendo um problema específico, RTMP é a escolha certa e você pode parar de ler aqui.

O ponto fraco dele é o que acontece quando a rede não é estável. O RTMP roda sobre TCP, e o TCP lida com perda retransmitindo e esperando. Num link bom, isso é invisível. Num link com perda de pacotes de verdade, não é: o stream acumula uma latência que nunca devolve, ou trava, e a recuperação vai de elegante até uma desconexão, dependendo do encoder.

Se o seu encoder pede servidor e chave separados, divida a URL na última barra: servidor rtmp://a.dcast.pro/live, chave sk_rtmp_…. (As chaves de stream levam como prefixo o protocolo para o qual o card foi criado — sk_rtmp_, sk_srt_, sk_webrtc_ —, então a chave que você colar deve corresponder à porta em que está batendo.)

SRT: o das redes ruins

O SRT existe para o caso que o RTMP resolve mal: um link com perda de pacotes que você não consegue consertar, o que na prática significa redes móveis, Wi-Fi público de locais de evento e qualquer coisa que atravesse uma longa distância.

A ideia é um orçamento de latência fixo. Em vez de retransmitir até o pacote chegar, leve o tempo que levar, o SRT mantém um buffer do tamanho escolhido e só volta a pedir os pacotes perdidos enquanto ainda há tempo de encaixá-los no lugar certo. Pacotes que não conseguem chegar a tempo são descartados em vez de atrasar tudo o que vem depois. O resultado é um stream com atraso previsível e degradação suave diante da perda, em vez de atraso imprevisível e travamentos.

Esse buffer é o parâmetro latency, expresso em milissegundos. As URLs que o dcast emite trazem 500 ms, e você pode aumentar até 7000. A troca é direta e não existe ajuste mágico: um valor maior aguenta perdas piores e acrescenta exatamente esse atraso. Se o seu stream está perdendo pacotes, aumente.

Baixar para menos de 500 é a única coisa que não vai funcionar, e vale saber o motivo em vez de descobrir na prática. Nosso ingest declara 500 ms por conta própria, e uma conexão SRT fica com o maior dos valores das duas pontas — então um encoder que pede 80 ms continua recebendo 500. O número é um piso, não apenas um padrão.

Vale conhecer mais duas configurações do SRT. Modo — o dcast emite URLs caller, ou seja, seu encoder inicia a conexão para fora, o que funciona atrás de um roteador sem redirecionamento de portas. listener e rendezvous existem para configurações que precisam deles. E passphrase — o SRT pode criptografar o link; se você definir uma, ela precisa ter pelo menos dez caracteres.

WHIP: o do navegador

WHIP é a forma como uma fonte WebRTC publica. Em vez de uma URL de stream, você envia uma oferta SDP para um endpoint HTTPS e uma conexão peer é estabelecida. O dcast devolve esse endpoint junto com os outros no card do stream.

Use quando a sua fonte for um navegador — um convidado sem nada instalado, uma superfície de controle web, um compartilhamento de tela — ou quando precisar de uma latência de contribuição menor do que um caminho segmentado consegue oferecer. Encoders com suporte a WHIP o oferecem como um serviço de streaming em que você cola a URL devolvida do jeito que ela vem; não há campo separado para a chave de stream, porque a chave já está na URL.

A limitação é que o WebRTC é mais exigente de operar do que um envio por TCP. Ele é mais sensível a redes restritivas e tem suporte menos universal em encoders de hardware do que o RTMP.

A escolha do protocolo não muda a sua imagem

Esta é a parte que poupa muito teste. Seja qual for o protocolo que entrega o seu stream, ele é normalizado para uma única forma interna antes de qualquer outra coisa, e a escada de codificação que roda em seguida é idêntica. Os mesmos degraus, os mesmos tetos de bitrate, o mesmo intervalo de keyframes de 2 segundos, os mesmos segmentos de 4 segundos com dois keyframes cada.

Ou seja: um stream SRT e um stream RTMP com a mesma fonte no mesmo bitrate geram o mesmo resultado. Escolher SRT não te dá uma imagem melhor, e escolher RTMP não te custa uma. Escolha com base em como a sua rede se comporta, que é a única coisa que a escolha realmente afeta.

A taxa de quadros também é decidida do nosso lado, e não pelo protocolo, e do mesmo jeito para os três: no momento em que este texto foi escrito, a escada ao vivo é codificada a 30 fps, seja o que for que você envie.

Não monte a URL de ingest na mão

Cada endereço de ingest que o dcast te dá é emitido pela API para um card de stream específico, e cada parte dele tem uma função. O GET /api/v1/streams/:id devolve todos juntos em data.ingest, e o fluxo correto é copiar dali toda vez, em vez de guardar uma URL num documento e editar a chave nela.

O hostname é o ponto de entrada do pool, e não o nome de uma máquina, então continua válido se o seu stream for servido de outro lugar na semana que vem. A chave identifica o seu card. No SRT, o streamid também carrega o modo — m=publish é o que faz da conexão uma publicação, e não uma reprodução —, e é justamente por isso que a falha de codificação do início deste artigo é tão silenciosa: ao corromper o streamid, você não enviou uma requisição malformada; enviou uma requisição perfeitamente válida para assistir a um stream que não existe.

Dois hábitos evitam quase tudo isso. Copie a URL inteira, incluindo tudo o que vem depois do ?, de uma vez só. E quando um encoder insistir em campos separados de servidor e chave, divida na última barra e cole as duas metades em vez de digitar qualquer uma delas de novo.

Se você está fazendo uma integração em vez de configurar na mão, peça os destinos de ingest no momento do uso em vez de guardá-los em cache, pelo mesmo motivo: o valor que você recebe está correto agora, e pedir de novo custa pouco.

Criptografar o link

O SRT pode criptografar o stream entre o seu encoder e nós com uma passphrase. Vale a pena ativar sempre que o link passar por uma rede que você não controla — o Wi-Fi de convidados de um local, um hotel, um uplink compartilhado num congresso —, porque nessas redes o sinal de contribuição é a única coisa que você realmente não consegue refazer se alguém interferir nele.

A passphrase precisa ter pelo menos dez caracteres. Defina o mesmo valor nas duas pontas; se não baterem, o handshake falha em vez de degradar, e esse é o comportamento que você quer, porque cair silenciosamente para uma conexão sem criptografia seria pior do que uma recusa.

A criptografia custa um pouco de processamento em cada ponta e nada em qualidade de imagem. Se você já usa SRT porque a rede não é confiável, o mesmo raciocínio geralmente vale para a pergunta de se ela deveria poder ser lida.

Como escolher, em um parágrafo

Se a sua rede é uma conexão cabeada num prédio que você controla, use RTMP. Se você está numa conexão móvel, no Wi-Fi de um local de evento ou enviando de um continente para outro, use SRT e aumente a latência até o stream ficar limpo. Se a sua fonte é um navegador, use WHIP. Se o conteúdo já existe como stream em outro lugar, use HTTP pull e deixe que a gente busque, em vez de retransmitir na mão. Essas quatro frases cobrem quase todos os casos reais.

Testar o ingest antes do evento

Teste com a URL real do card de stream real, não com uma URL que você mesmo montou. A maioria das falhas da primeira vez é um endereço montado na mão.

Teste a partir do local real, na conexão real e no horário real, se o local fica cheio. Uma rede que está limpa às nove da manhã e saturada às sete da noite é o caso normal, não a exceção.

No SRT especificamente, durante o teste acompanhe os contadores de perda e retransmissão do seu encoder em vez de olhar para a imagem. A imagem parece perfeita até o momento em que o orçamento de latência se esgota, então são os contadores que te avisam, não a imagem.

E confirme que o card do stream mostra sinal, não só que o seu encoder aparece como conectado. São duas afirmações diferentes, e a falha do streamid do SRT descrita no início deste artigo é exatamente o caso em que a primeira é verdadeira e a segunda é falsa.