¿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 AES-128/256 nativo: El stream viaja cifrado desde el origen
- ✅ 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.
SRT vs RTMP: Comparativa técnica punto a punto
| Característica | RTMP | SRT |
|---|---|---|
| Protocolo de transporte | TCP | UDP |
| Latencia típica | 3-5 segundos | 0.5-2 segundos |
| Tolerancia a pérdida de paquetes | Baja (TCP retransmite todo) | Alta (ARQ selectivo) |
| Cifrado | RTMPS (opcional, capa SSL) | AES-128/256 nativo |
| Corrección de errores | No | Sí (FEC + ARQ) |
| Adaptación al ancho de banda | No | Sí (automática) |
| Código | Propietario | Open source (LGPL) |
| Soporte en OBS | ✅ Nativo | ✅ Desde OBS 25+ |
| Soporte en encoders HW | ✅ Universal | ✅ LiveU, Teradek, Haivision |
| Soporte en servidores | ✅ Universal | ⚠️ Creciendo rápido |
Rendimiento bajo pérdida de paquetes
Aquí es donde SRT realmente brilla. Cuando la red es perfecta, RTMP y SRT se comportan de forma parecida. Pero cuando la red tiene problemas (que es la mayoría de las veces en transmisiones de campo, 4G, o internet latinoamericano), la diferencia es brutal:
| Pérdida de paquetes | RTMP | SRT |
|---|---|---|
| 0% (red perfecta) | Funciona bien | Funciona bien |
| 1-2% | Micro-cortes visibles | Sin impacto visible |
| 3-5% | Congelamiento frecuente | Artefactos menores ocasionales |
| 5-10% | Inutilizable | Degradación notable pero funcional |
| 10%+ | Desconexión | Funciona con calidad reducida |
📡 Para transmisiones de campo (deportes, eventos al aire libre, 4G/5G), SRT es objetivamente superior a RTMP. La corrección de errores marca la diferencia entre una transmisión que se mantiene al aire y una que se corta.
¿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 |
🔮 Nuestra visión: En 5 años, RTMP seguirá existiendo pero será principalmente el "adaptador universal" para redes sociales. SRT dominará la ingesta profesional. WebRTC dominará lo interactivo. Y HLS seguirá siendo el estándar de distribución. En XtreamCast aceptamos tanto RTMP como HLS, y estamos preparados para soportar SRT en la ingesta a medida que la demanda crezca.
¿Quieres streaming estable desde cualquier conexión?
XtreamCast acepta ingesta RTMP con distribución HLS optimizada. CDN global, ultra baja latencia y soporte en español 24/7. Prueba gratis 3 días.