¿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
- Sin corrección de errores: Si un paquete se pierde, se pierde
- 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; no debe confundirse con ARQ ni darse por activo en XtreamCast. El canal actual usa autenticación por token en streamid; no se promete cifrado AES en esa configuración.
¿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
- Necesitas cifrado real: SRT cifra todo nativamente, RTMP no
- 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 | 16, 24 o 32 | Longitud de clave AES (128/192/256 bits) |
passphrase | Tu contraseña | 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: su disponibilidad requiere un origen preparado y habilitación del canal. Confirma con soporte la configuración y la compatibilidad antes de presupuestarlo. No está disponible como compra directa general en el checkout y no debe combinarse en el mismo canal con WebRTC.
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.
¿Quieres streaming estable desde cualquier conexión?
XtreamCast ofrece HLS y WebRTC como complemento. LL-HLS requiere confirmar origen y habilitación con soporte. Prueba la señal y su compatibilidad antes de elegir.