¿Qué es el streaming SRT? SRT vs RTMP explicado
SRT es un protocolo de transporte de vídeo diseñado para aguantar redes poco fiables. Te explicamos cómo recupera los paquetes perdidos, qué hace el ajuste de latencia, cómo se compara con RTMP y por qué la mayoría de las plataformas siguen pidiendo RTMP.
En esta página
SRT (Secure Reliable Transport) es un protocolo de código abierto para enviar vídeo en directo a través de redes impredecibles, como el internet público. Funciona sobre UDP, vuelve a solicitar los paquetes que se pierden, te permite elegir cuánto retardo cambiar por fiabilidad y puede cifrar la transmisión. Los profesionales de la emisión lo usan para mover señales de alta calidad entre ubicaciones.
No sustituye a RTMP en todas partes, pero resuelve muy bien problemas concretos. Así funciona y así sabrás cuándo merece la pena usarlo.
Puntos clave
- SRT usa UDP y recupera los paquetes perdidos dentro de una ventana de latencia que tú defines.
- Encaja en enlaces de larga distancia o con pérdidas, como sedes remotas y señales de contribución.
- La mayoría de las plataformas para creadores siguen documentando la ingesta por RTMP o RTMPS.
- El cifrado AES con una contraseña compartida protege las señales SRT en tránsito.
De dónde viene SRT y qué problema resuelve
SRT lo desarrolló la empresa de vídeo Haivision y se publicó como código abierto en 2017. Hoy lo admite una amplia gama de codificadores, decodificadores, servidores de medios y programas, incluidos OBS y FFmpeg.
El problema que ataca es fácil de describir: el internet público pierde y desordena paquetes, sobre todo a largas distancias, con Wi-Fi saturado o con conexiones móviles. Los enlaces de emisión tradicionales lo evitaban con circuitos dedicados o capacidad por satélite. SRT, en cambio, busca ofrecer una fiabilidad de nivel broadcast sobre conexiones a internet corrientes.
Y lo consigue sin preocuparse demasiado por lo que va dentro de la transmisión. SRT es un transporte, no un formato de vídeo, y lo más habitual es que lleve un flujo de transporte MPEG con vídeo H.264 o HEVC y audio AAC. Esa flexibilidad ayudó a que los flujos de trabajo profesionales lo adoptaran rápidamente.
Cómo funcionan la recuperación de paquetes y el búfer de latencia
RTMP va sobre TCP, que retransmite los datos perdidos pero ralentiza toda la conexión cada vez que detecta una pérdida. En enlaces de larga distancia con pérdidas, eso se traduce en cortes y buffering.
SRT usa UDP y gestiona la recuperación por su cuenta. El receptor guarda los paquetes en un búfer corto. Cuando detecta un hueco en la secuencia, pide al emisor que reenvíe solo el paquete que falta. Si el reemplazo llega antes de que ese momento del vídeo salga del búfer, nadie más adelante en la cadena lo nota.
El tamaño del búfer es el ajuste de latencia. Los valores más altos toleran peores redes a costa de más retardo; los más bajos mantienen el retardo reducido pero descartan los paquetes que llegan demasiado tarde. Un punto de partida habitual es unas cuantas veces el tiempo de ida y vuelta entre emisor y receptor, aumentándolo en enlaces inestables. Cada herramienta expresa la latencia en unidades distintas, así que consulta la documentación.
Cifrado, stream ID y modos de conexión
SRT incluye funciones que RTMP no ofrece por sí solo:
- Cifrado. AES con una contraseña que comparten ambos extremos, con claves de 128, 192 o 256 bits. RTMP necesita la variante aparte RTMPS para ir cifrado.
- Stream ID. Un identificador opcional que permite que un mismo puerto receptor acepte varias señales y enrute cada una correctamente, algo parecido a una clave de transmisión.
- Modos de conexión. Un lado escucha en un puerto y el otro lo llama. Un tercer modo, rendezvous, hace que ambos lados se conecten a la vez, lo que puede ayudar cuando los dos están detrás de cortafuegos.
Como SRT usa UDP, el puerto UDP del lado que escucha debe estar abierto en todos los cortafuegos del camino, a diferencia de las conexiones TCP salientes de RTMP. Para el lado de RTMP, consulta cómo funciona RTMP y RTMP vs RTMPS.
SRT vs RTMP: dónde gana cada uno
Ninguno de los dos protocolos es simplemente mejor; cada uno destaca en tareas distintas.
- SRT gana en contribución. Enviar una señal desde una sede remota, un equipo de exteriores o un enlace móvil de vuelta a un centro de producción es donde la recuperación de paquetes compensa, igual que en las cadenas de emisión que alimentan sistemas de playout, decodificadores y servidores de medios.
- SRT gestiona mejor la distancia. En enlaces intercontinentales con pérdidas y jitter, un búfer de latencia bien ajustado suele dar resultados más estables que RTMP sobre TCP.
- RTMP gana en compatibilidad. Casi todos los codificadores, servicios y plataformas lo admiten, y la configuración se reduce a una URL y una clave.
- RTMP es más sencillo de desplegar. No hay puertos UDP, ajustes de latencia ni contraseñas que coordinar.
Una regla práctica: usa SRT entre sistemas que controlas tú o un socio, y RTMP o RTMPS para el último salto hacia las plataformas públicas.
Por qué YouTube, Twitch y la mayoría de las plataformas siguen pidiendo RTMP
Si SRT es tan resistente, ¿por qué las grandes plataformas para creadores siguen documentando la ingesta por RTMP y RTMPS?
Primero, por compatibilidad: las plataformas quieren que cualquier streamer pueda conectarse, desde apps para móvil hasta codificadores de hardware antiguos, y RTMP es el protocolo que hablan todos. Segundo, la mayoría de los creadores emiten desde casa hacia un servidor de ingesta cercano, donde TCP rinde lo suficientemente bien. Tercero, las plataformas llevan años construyendo autenticación, gestión de claves y monitorización en torno a RTMP.
Ese panorama está cambiando. Algunas plataformas y muchos servicios de vídeo profesionales aceptan SRT u otros protocolos de ingesta más recientes. Aun así, en el momento de escribir esto, una plataforma social o de gaming convencional normalmente te dará una URL RTMP o RTMPS. La guía de streaming por RTMP personalizado explica cómo funcionan esos destinos.
Enviar RTMP y SRT desde la misma transmisión en la nube
Muchas configuraciones necesitan ambos protocolos a la vez: RTMP para las plataformas públicas y SRT para un estudio, un servidor de playout o el receptor de un socio. Desde un codificador en casa, eso significa dos salidas y el doble de subida.
StreamHouse lo resuelve en la nube. Añade YouTube, Twitch o Kick por RTMP o RTMPS, junto con una salida SRT personalizada que apunte a tu receptor, a la misma transmisión. Una sola emisión llega a todos ellos, y los destinos adicionales no consumen ranuras de transmisión extra.
Para la programación pregrabada, sube tus vídeos, que se preparan con antelación con un único perfil de codificación coherente, luego crea una lista de reproducción y iníciala o prográmala. La transmisión se repite en bucle 24/7, se reconecta automáticamente tras los fallos de red y sigue funcionando con tu ordenador apagado.
Preguntas frecuentes
¿Es SRT mejor que RTMP para hacer streaming?
En rutas de red largas o poco fiables, normalmente sí, porque SRT recupera los paquetes perdidos sin bloquear toda la conexión. Sin embargo, las plataformas convencionales a menudo solo ofrecen RTMP o RTMPS, así que la elección correcta depende de adónde vaya tu señal.
¿Tiene SRT menos latencia que RTMP?
Puede tenerla. El retardo de transporte de SRT es aproximadamente el búfer de latencia que configures, que puede ser pequeño en redes buenas. Pero el retardo total para los espectadores también depende del procesamiento y la reproducción de la plataforma, así que cambiar de protocolo no siempre se notará más rápido.
¿Puede OBS emitir por SRT?
Sí. Introduce una dirección srt:// como servidor personalizado en OBS, con parámetros como el modo, la latencia y la contraseña incluidos en la URL. El servidor o servicio receptor debe admitir SRT y estar configurado para aceptar la conexión.
¿SRT va cifrado por defecto?
Solo si defines una contraseña. Con la misma contraseña en ambos lados, SRT cifra la señal mediante AES con claves de 128, 192 o 256 bits. Sin ella viaja sin cifrar, así que configura una para las señales que atraviesen el internet público.
