¿Qué es SRT y por qué todo el mundo habla de él?
SRT (Secure Reliable Transport) es un protocolo de transporte de video de código abierto, desarrollado originalmente por Haivision y liberado como open source en 2017. Su promesa: lograr la calidad de una transmisión satelital, pero por internet regular.
Para entender por qué SRT es tan relevante, primero hay que entender las limitaciones de RTMP, el protocolo que ha dominado el streaming durante 20 años:
Los problemas de RTMP
- Creado en 2002 por Macromedia (Adobe) para Flash Player, una tecnología muerta
- Sin cifrado nativo: Los datos viajan en texto plano (RTMPS fue un parche posterior)
- Sensible a pérdida de paquetes: En redes inestables, RTMP se degrada notablemente
- Recuperación mediante TCP: La retransmisión de paquetes puede aumentar el retraso cuando la red pierde datos
- Protocolo propietario: Aunque Adobe lo "abrió", sigue siendo un protocolo legacy
- TCP only: No aprovecha las ventajas de UDP para baja latencia
Lo que SRT resuelve
- Basado en UDP: Menor latencia que TCP (RTMP)
- Corrección de errores (ARQ): Retransmite solo los paquetes perdidos, sin esperar
- Cifrado opcional: requiere soporte y parámetros compatibles en ambos extremos. No está implícito por usar una URL SRT.
- Resiliente a jitter: Compensa las fluctuaciones de la red automáticamente
- Open source: Sin licencias, sin dependencia de una empresa
- Firewall-friendly: Funciona sobre un solo puerto UDP, fácil de configurar
Analogía: RTMP es como enviar un paquete por correo certificado: seguro pero lento y rígido. SRT es como un dron de entrega: rápido, adaptable a las condiciones, y si algo falla, reintenta al instante.
Comparar el transporte y medir su rendimiento
| Aspecto | RTMP | SRT |
|---|---|---|
| Transporte | TCP | UDP con recuperación selectiva |
| Recuperación | Retransmisión de TCP | ARQ dentro de un buffer configurable |
| Cifrado | RTMPS cuando ambos extremos lo soportan | Opcional mediante configuración compatible |
| Compatibilidad | Comprobar encoder y servicio | Comprobar modo, streamid y parámetros en ambos extremos |
No hay un porcentaje de pérdida que produzca siempre un resultado idéntico. Influyen duración de las ráfagas, RTT, bitrate y tiempo disponible para recuperar paquetes. Prueba tu conexión y conserva los parámetros del ensayo.
SRT admite un filtro FEC opcional en implementaciones compatibles, distinto de la retransmisión ARQ. En XtreamCast, la ingesta SRT se autentica con un token en el streamid, sin passphrase.
¿Cuándo usar RTMP y cuándo SRT?
Sigue usando RTMP cuando:
- Transmites a redes sociales: YouTube, Facebook, Twitch e Instagram solo aceptan RTMP como ingesta
- Transmites desde red estable: Fibra óptica o WiFi dedicado con <1% de pérdida
- Tu setup es simple: OBS → servidor → público (sin complicaciones)
- Usas apps móviles básicas: La mayoría soporta RTMP nativamente
- Tu servidor de streaming no soporta SRT: Verifica primero con tu proveedor
Cambia a SRT cuando:
- Transmites por 4G/5G: Bonding celular con SRT es muchísimo más estable
- Cubres eventos de campo: Deportes, exteriores, locaciones remotas
- Entregas a un cableoperador: Headends, IRD y receptores profesionales reciben SRT de forma nativa
- Necesitas menor latencia de ingesta: 0.5-1 segundo vs 3-5 segundos de RTMP
- Transmites entre continentes: SRT maneja mejor las distancias largas con alta latencia
- Usas encoders profesionales: LiveU, Teradek y Haivision soportan SRT nativamente
La estrategia híbrida (recomendada)
La mejor estrategia en 2026 para muchos productores es SRT para la ingesta (desde tu encoder al servidor) y HLS para la distribución (desde el servidor a los espectadores). Así obtienes la estabilidad de SRT en la subida y la compatibilidad universal de HLS en la salida.
Flujo recomendado: Encoder (SRT) → Servidor de streaming → CDN (HLS) → Espectadores. Esto combina la resiliencia de SRT con la compatibilidad universal de HLS. Tu encoder gana estabilidad, y tus espectadores ganan compatibilidad.
Cómo configurar SRT en OBS Studio
OBS Studio soporta SRT desde la versión 25 (2020). La configuración es sencilla si tu servidor de streaming lo acepta:
Paso a paso
- Abre OBS Studio → Settings → Stream
- En "Service", selecciona "Custom..."
- En "Server", escribe la URL SRT de tu servidor:
srt://tu-servidor.com:port?streamid=tu-stream-key&latency=200000 - El campo "Stream Key" déjalo vacío (ya va en la URL)
- Haz clic en OK y luego en "Start Streaming"
Parámetros SRT importantes
| Parámetro | Valor recomendado | Qué hace |
|---|---|---|
latency | 200000 (200ms) | Buffer de corrección de errores |
pbkeylen | Solo si el servidor usa passphrase | Longitud de clave AES (128/192/256 bits) |
passphrase | La que exija el servidor; vacía en XtreamCast, que autentica con token en el streamid | Cifrado AES (10-79 caracteres) |
streamid | Tu stream key | Identificador del stream |
¿Qué valor de latency usar?
- 120000 (120ms): Red muy estable (fibra directa al servidor)
- 200000 (200ms): Red estable (fibra, buena WiFi): recomendado por defecto
- 500000 (500ms): Red inestable (4G, WiFi compartido)
- 1000000 (1s): Red muy inestable (3G, satélite, zonas remotas)
Tip: Empieza con 200ms. Si ves que OBS muestra "dropped frames" o el stream se corta, sube a 500ms. A mayor latency buffer, más estabilidad pero más delay en la ingesta. Encuentra tu punto óptimo probando antes del evento.
El futuro: ¿RTMP va a morir?
La pregunta del millón. Y la respuesta honesta: no en el corto plazo, pero su papel va a cambiar.
Por qué RTMP sobrevive
- YouTube, Facebook y Twitch lo usan: Mientras las redes sociales más grandes acepten RTMP para ingesta, seguirá vivo
- Simplicidad: Configurar RTMP es trivial. Copiar, pegar URL y key, listo
- Base instalada: Millones de encoders, cámaras IP y dispositivos solo hablan RTMP
- Documentación: 20 años de tutoriales, guías y soporte comunitario
Lo que cambiará
- Ingesta profesional → SRT: Para transmisiones de campo, contribution y feeds entre centros de producción, SRT ya es el estándar
- Ultra baja latencia → WebRTC: Para interacción en tiempo real, WebRTC (<500ms) es imbatible
- Distribución → HLS/DASH: Para entregar video a espectadores, HLS sigue siendo rey
- RTMP queda como → gateway universal: El "idioma común" que todo encoder habla y todo servidor acepta
Ecosistema de protocolos en 2026
| Etapa | Protocolo actual | Protocolo emergente |
|---|---|---|
| Encoder → Servidor | RTMP | SRT, RIST |
| Servidor → CDN | RTMP, HLS | SRT, CMAF |
| CDN → Espectador | HLS, DASH | HLS LL, WebRTC |
| Interactivo | - | WebRTC |
LL-HLS en XtreamCast: adicional por canal de USD 20/mes, con latencia de alrededor de 3 s. Lo activa nuestro equipo en tu canal, sin cambiar tu encoder. Para interacción en tiempo real, WebRTC llega hasta 0,3 s por USD 20/mes.
Fuentes y alcance de esta guía
Revisión editorial: 4 de septiembre de 2026. Las fuentes describen los estándares o servicios indicados; los resultados de una transmisión dependen de su configuración y de la red.
Conectar tu encoder con un servidor SRT
Si vas a emitir una señal propia desde un encoder compatible, revisa el servicio de servidor SRT y sigue la configuración de ingesta SRT con los datos de tu canal. Haz una prueba con el bitrate y la conexión que utilizarás en producción; elegir SRT no elimina los límites de la red ni sustituye la validación de audio y vídeo.
¿Quieres streaming estable desde cualquier conexión?
XtreamCast entrega HLS en todos los planes de pago y suma LL-HLS o WebRTC como adicionales por canal, con WebRTC hasta 0,3 s. Comienza con nuestro plan gratis y pasa a un plan de pago cuando necesites baja latencia.