Resposta curta: escolha o protocolo que o lado receptor realmente pode aceitar. SRT é uma opção de contribuição quando ambas as pontas o suportam e o caminho foi configurado; RTMP continua sendo uma transferência comum de codificador para plataforma ou servidor de ingest. A reprodução e entrega ao espectador permanecem tarefas downstream configuradas separadamente.
Comece pelo receptor e escolha a transferência
| Ponto de decisão | Caminho SRT | Caminho RTMP |
|---|---|---|
| Receptor | Receptor de contribuição compatível com SRT que você controla ou recebeu | Endpoint de ingest RTMP ou URL de plataforma fornecida para publicação |
| Transporte | Sessão SRT baseada em UDP; o modo ao vivo inclui controles de temporização e retransmissão | Sessão RTMP baseada em TCP para o endpoint configurado |
| Pergunta de rede | Os dois pares conseguem se alcançar e seus parâmetros de modo, latência e passphrase coincidem? | O codificador alcança o host e a URL/chave corresponde ao contrato do endpoint? |
| Pergunta de codec | Valide separadamente contêiner e codecs aceitos pelo receptor | Valide separadamente o perfil de áudio/vídeo aceito pelo destino |
| Próxima tarefa útil | Contribuição para um fluxo de operações ou produção | Publicação para um serviço de ingest ou RTMP Server configurado |
Três decisões comuns
- A plataforma fornece somente URL e chave de stream: publique RTMP usando esse contrato.
- Sua equipe controla um receptor SRT: use SRT quando modo, host:porta, latência e qualquer Stream ID/passphrase tiverem sido acordados nas duas pontas.
- A contribuição SRT termina em uma plataforma RTMP/RTMPS: valide separadamente a contribuição SRT e a transferência de publicação para a plataforma.
O modo ao vivo SRT é projetado em torno de uma janela de latência configurada e feedback do receptor; uma janela maior pode permitir mais tempo para recuperação, mas continua sendo uma escolha de implantação, não uma promessa de imagem melhor. A compatibilidade RTMP também é específica do endpoint. Uma plataforma que exige URL RTMP ou RTMPS define a transferência final, mesmo que a perna de contribuição em outro trecho use SRT.
O que muda operacionalmente
| Antes da primeira conexão | Registre |
|---|---|
| SRT | Modo caller/listener/rendezvous; host:porta; latência; Stream ID ou passphrase, quando usados; contêiner e codecs de vídeo/áudio. |
| RTMP | URL completa de ingest, aplicação/caminho e chave; perfil declarado pelo receptor, muitas vezes H.264/AAC quando o endpoint exige; e sua verificação de integridade do stream. |
Mantenha credenciais fora de capturas de tela, logs de chat e gravações de teste.
Criptografia SRT e RTMPS resolvem perguntas diferentes de segurança de transporte: SRT pode ser configurado com criptografia, enquanto RTMPS é RTMP transportado sobre TLS. Um destino RTMPS não descreve as opções de ingest de um RTMP Server separado.
Teste um caminho de contribuição
Use a mesma fonte preparada para qualquer aba: fixe o formato do programa, anote configurações de codec de vídeo e áudio e conceda ao publicador acesso ao endpoint de teste selecionado. Inicie uma sessão de protocolo, confirme o estado do publicador, inspecione a prévia e então verifique a saída downstream se o fluxo usar uma.
DEMONSTRAÇÕES DE PROTOCOLOS
Escolha um protocolo para testar
Cada demonstração é iniciada manualmente e mantém sua própria concessão temporária. Use configurações de fonte equivalentes ao comparar fluxos de trabalho; esta página não executa um teste de latência controlado.
Demonstração SRT ao vivo
Teste uma conexão SRT ao vivo
Crie uma conexão temporária por uma hora. Envie seu feed ao endereço do publicador no modo Caller, deixando o ID de stream vazio. Assista-o no Multiview abaixo ou conecte seu receptor ao endereço do receptor no modo Caller.
O resultado confirma que a fonte selecionada alcançou esse caminho temporário e sua prévia. É uma verificação de configuração, não um benchmark comparativo; portanto, não classifica latência, qualidade ou confiabilidade. Repita uma configuração alterada como novo teste e retenha logs do receptor ou dados de conexão visíveis ao operador.
Onde o Callaba se encaixa
O RTMP Server do Callaba pode conceder regras de acesso separadas a publicadores e receptores e mostrar atividade visível ao operador. Um RTMP Server Guest pode, em vez disso, permanecer aberto sem regras de acesso predefinidas. Seu SRT Server é o recurso de contribuição correspondente para um fluxo SRT compatível. Observação no navegador e reprodução para espectadores usam módulos configurados separadamente; uma URL de publicação RTMP não é reproduzível no navegador.
Próximos passos
- Para um listener RTMP configurado, consulte RTMP Server e seus controles de acesso/ciclo de vida.
- Para um receptor de contribuição SRT, consulte SRT Server.
- Para uma ponte explícita, use o caminho documentado de gateway de contribuição RTMP apenas depois de confirmar ambos os endpoints.
