Respuesta corta: elija el protocolo que el lado receptor realmente pueda aceptar. SRT es una opción de contribución cuando ambos extremos la admiten y la ruta se ha configurado; RTMP sigue siendo una transferencia habitual de codificador a plataforma o servidor de ingesta. La reproducción y entrega al espectador siguen siendo trabajos descendentes configurados por separado.
Empiece por el receptor y después elija la transferencia
| Punto de decisión | Ruta SRT | Ruta RTMP |
|---|---|---|
| Receptor | Un receptor de contribución compatible con SRT que usted controla o le han asignado | Un endpoint de ingesta RTMP o URL de plataforma suministrado para publicar |
| Transporte | Sesión SRT basada en UDP; el modo en directo incluye controles de tiempo y retransmisión | Sesión RTMP basada en TCP hacia el endpoint configurado |
| Pregunta de red | ¿Pueden los dos pares alcanzarse y coinciden sus ajustes de modo, latencia y frase de paso? | ¿Puede el codificador alcanzar el host y coincide la URL/clave con el contrato del endpoint? |
| Pregunta de códec | Valide por separado el contenedor y códecs que acepta el receptor | Valide por separado el perfil de audio/vídeo que acepta el destino |
| Siguiente trabajo útil | Contribución a un flujo de operaciones o producción | Publicación a un servicio de ingesta o RTMP Server configurado |
Tres decisiones habituales
- La plataforma suministra solo una URL y clave de transmisión: publique RTMP usando ese contrato.
- Su equipo controla un receptor SRT: use SRT cuando modo, host:port, latencia y cualquier Stream ID/frase de paso se hayan acordado en ambos extremos.
- La contribución SRT termina en una plataforma RTMP/RTMPS: valide por separado la contribución SRT y la transferencia de publicación a plataforma.
El modo en directo de SRT está diseñado alrededor de una ventana de latencia configurada y retroalimentación del receptor; una ventana mayor puede permitir más tiempo de recuperación, pero sigue siendo una elección de despliegue, no una promesa de mejor imagen. La compatibilidad RTMP depende igualmente del endpoint. Una plataforma que requiere una URL RTMP o RTMPS decide la transferencia final incluso si el tramo de contribución en otro lugar usa SRT.
Qué cambia operativamente
| Antes de la primera conexión | Registre |
|---|---|
| SRT | Modo caller/listener/rendezvous; host:port; latencia; Stream ID o frase de paso cuando se use; contenedor y códecs de vídeo/audio. |
| RTMP | URL completa de ingesta, aplicación/ruta y clave; el perfil declarado por el receptor, a menudo H.264/AAC cuando el endpoint lo requiere; y su comprobación de salud de transmisión. |
Mantenga las credenciales fuera de capturas, registros de chat y grabaciones de prueba.
El cifrado SRT y RTMPS resuelven preguntas de seguridad de transporte distintas: SRT puede configurarse con cifrado, mientras RTMPS es RTMP transportado sobre TLS. Un destino RTMPS no describe las opciones de ingesta de un RTMP Server independiente.
Pruebe una ruta de contribución
Use la misma fuente preparada en cualquier pestaña: fije el formato de programa, anote los ajustes de códec de vídeo y audio y dé al publicador acceso al endpoint de prueba seleccionado. Inicie una sesión de protocolo, confirme el estado del publicador, inspeccione la vista previa y luego verifique la salida descendente si el flujo usa una.
DEMOS DE PROTOCOLOS
Elija un protocolo para probar
Cada demo se inicia manualmente y conserva su propio alquiler temporal. Use ajustes de fuente equivalentes al comparar flujos; esta página no ejecuta una prueba comparativa controlada de latencia.
Demostración SRT en directo
Probar una conexión SRT en directo
Cree una conexión temporal durante una hora. Envíe su flujo a la dirección de publicación en modo Caller, dejando vacío el ID de flujo. mírelo en Multiview a continuación o conecte su receptor a la dirección de recepción en modo Caller.
El resultado confirma que la fuente seleccionada alcanzó esa ruta temporal y su vista previa. Es una comprobación de configuración, no un benchmark comparativo, de modo que no clasifica latencia, calidad ni fiabilidad. Repita una configuración modificada como prueba nueva y conserve los registros del receptor o los datos de conexión visibles para el operador.
Dónde encaja Callaba
El RTMP Server de Callaba puede dar a publicadores y receptores reglas de acceso separadas y mostrar actividad visible para el operador. En cambio, un RTMP Server Guest puede estar abierto sin reglas de acceso predefinidas. Su SRT Server es el recurso de contribución correspondiente para un flujo SRT compatible. La observación en navegador y la reproducción para espectadores usan módulos configurados por separado; una URL de publicación RTMP no es una URL reproducible en navegador.
Próximos pasos
- Para un listener RTMP configurado, revise RTMP Server y sus controles de acceso/ciclo de vida.
- Para un receptor de contribución SRT, revise SRT Server.
- Para un puente explícito, use la ruta documentada de pasarela de contribución RTMP solo después de confirmar ambos endpoints.
