SRT vs RTMP, por qué el protocolo de 2001 está muriendo.

SRT (Secure Reliable Transport) alcanza +85 miembros en la SRT Alliance incluyendo Microsoft, Avid y Telestream. El protocolo liberado como open source por Haivision en NAB Show 2017 se convierte en el estándar de facto para ingesta de video en vivo. Las mediciones en campo muestran que SRT es 5 a 12 veces más rápido que RTMP en latencia extremo-a-extremo. La recuperación de paquetes perdidos funciona sin retransmisión completa. RTMP, el protocolo dominante desde 2001, enfrenta su obsolescencia técnica.

Para operadores de plataformas de streaming en vivo, esta transición representa un cambio fundamental en la arquitectura de ingesta. RTMP fue diseñado para redes estables con baja pérdida de paquetes. SRT fue diseñado para redes públicas con congestión variable. La diferencia es crítica para transmisiones desde ubicaciones remotas, conexiones móviles o redes con ancho de banda limitado. SRT hace viable el streaming profesional desde contextos donde RTMP falla.

Por qué RTMP está muriendo

RTMP (Real-Time Messaging Protocol) fue desarrollado por Macromedia en 2002 y adquirido por Adobe en 2005, siendo el protocolo diseñado para streaming de video sobre redes locales o conexiones de internet estables, donde RTMP asume que la pérdida de paquetes es inferior al 1% y que la latencia de red es consistente, asunciones que eran razonables en 2002 pero no reflejan la realidad de las redes públicas actuales.

El problema principal de RTMP es que usa TCP como protocolo de transporte. TCP garantiza la entrega ordenada de paquetes mediante retransmisión automática. Si un paquete se pierde, TCP detiene la transmisión hasta que el paquete perdido se retransmite y se recibe. Esto genera latencia variable. En una red con 5% de pérdida de paquetes, la latencia de RTMP puede aumentar de 2 segundos a 10 segundos o más.

RTMP tampoco tiene mecanismos de recuperación de errores específicos para video. Si se pierde un paquete que contiene un fotograma clave (I-frame), el decoder no puede reconstruir los fotogramas siguientes hasta que recibe el próximo I-frame. Esto genera congelamiento de video visible para el espectador. RTMP no puede solicitar retransmisión selectiva de fotogramas clave. Solo puede esperar a que TCP retransmita todo.

Adobe dejó de desarrollar RTMP activamente después de 2012, por lo que el protocolo no recibe actualizaciones para soportar codecs modernos como HEVC o AV1, no tiene soporte nativo para encriptación y no puede adaptarse dinámicamente a cambios en el ancho de banda disponible, de modo que RTMP es un protocolo legacy que sobrevive por inercia, no por superioridad técnica.

Cómo funciona SRT y por qué es superior

SRT usa UDP como protocolo de transporte en lugar de TCP. UDP no garantiza entrega ordenada ni retransmisión automática. Esto parece peor que TCP pero permite que SRT implemente su propio mecanismo de recuperación de errores optimizado para video. SRT puede solicitar retransmisión selectiva de paquetes perdidos sin detener la transmisión completa. La latencia se mantiene constante incluso con pérdida de paquetes del 10% o más.

SRT implementa un buffer adaptativo que ajusta su tamaño según las condiciones de red. Si la red es estable, el buffer se reduce para minimizar latencia. Si la red tiene pérdida de paquetes variable, el buffer aumenta para absorber la variabilidad. El tamaño del buffer se ajusta dinámicamente cada segundo. Esto permite que SRT mantenga latencia baja en redes buenas y estabilidad en redes malas.

SRT incluye encriptación AES-128 o AES-256 nativa. El stream de video se encripta antes de salir del encoder y se desencripta en el servidor de ingesta. Esto protege el contenido contra interceptación en redes públicas. RTMP requiere tunelización mediante RTMPS (RTMP sobre TLS) para lograr encriptación, lo que agrega complejidad y overhead.

SRT soporta modo caller, listener y rendezvous para establecer conexiones. Esto permite configuraciones donde el encoder inicia la conexión (caller), el servidor inicia la conexión (listener) o ambos se conectan simultáneamente (rendezvous). RTMP solo soporta modo caller donde el encoder siempre inicia la conexión. Esto limita las opciones de configuración de red.

Mediciones de latencia en campo

Haivision publica mediciones comparativas de latencia entre SRT y RTMP en redes con diferentes niveles de pérdida de paquetes, donde en una red con 0% de pérdida, RTMP tiene latencia de 2 segundos y SRT tiene latencia de 0.5 segundos, siendo SRT 4 veces más rápido en condiciones ideales, diferencia que se debe al overhead de TCP y al buffer fijo de RTMP.

En una red con 5% de pérdida de paquetes, RTMP tiene latencia de 8 segundos y SRT mantiene latencia de 1 segundo. SRT es 8 veces más rápido. La diferencia se debe a que TCP retransmite paquetes perdidos de forma secuencial mientras SRT retransmite solo los paquetes necesarios sin detener el stream.

En una red con 10% de pérdida de paquetes, RTMP tiene latencia de 15 segundos o más y SRT mantiene latencia de 2 segundos. SRT es 7 a 12 veces más rápido. En este nivel de pérdida, RTMP es prácticamente inutilizable para streaming en vivo. SRT sigue siendo funcional aunque con calidad de video reducida si el bitrate no es suficiente para compensar la pérdida.

Alterlatina opera infraestructura de streaming desde 1999 y observa que los clientes que transmiten desde ubicaciones remotas enfrentan pérdida de paquetes del 5% al 15% regularmente. Conexiones satelitales, redes móviles 4G y conexiones de internet residenciales tienen pérdida variable. SRT hace viable el streaming profesional desde estos contextos. RTMP requiere conexiones dedicadas con QoS garantizado.

Casos de uso donde SRT es crítico

Las transmisiones deportivas desde estadios remotos requieren ingesta confiable sobre redes públicas. Un partido de fútbol en una ciudad pequeña puede no tener acceso a fibra óptica dedicada. La transmisión debe funcionar sobre 4G o conexiones de internet residenciales. SRT permite que la transmisión sea estable incluso con pérdida de paquetes del 10%. RTMP falla en estas condiciones.

Los eventos corporativos en ubicaciones temporales no tienen infraestructura de red dedicada. Una conferencia en un centro de convenciones usa la red WiFi del venue. La red puede tener cientos de usuarios simultáneos compitiendo por ancho de banda. SRT mantiene la transmisión estable mediante recuperación de paquetes perdidos. RTMP genera congelamiento de video visible.

Las transmisiones desde vehículos en movimiento enfrentan cambios constantes en la calidad de red. Un camión de transmisión que se mueve entre zonas de cobertura 4G experimenta pérdida de paquetes variable. SRT ajusta su buffer dinámicamente para absorber la variabilidad. RTMP no puede adaptarse y la transmisión se interrumpe cada vez que la red cambia.

Los periodistas que transmiten desde zonas de conflicto o desastres naturales no tienen acceso a redes estables. La transmisión debe funcionar sobre conexiones satelitales con latencia de 500ms o más. SRT compensa la latencia alta mediante buffers adaptativos. RTMP no fue diseñado para latencias superiores a 100ms y genera timeouts frecuentes.

Adopción de SRT en la industria

La SRT Alliance fundada por Haivision y Wowza en 2017 alcanza +85 miembros para 2019. Microsoft integra SRT en Azure Media Services. Avid integra SRT en Media Composer. Telestream integra SRT en Wirecast. Los fabricantes de encoders como Teradek, LiveU y Dejero soportan SRT nativamente. La adopción industrial es masiva.

Las plataformas de streaming como YouTube, Facebook Live y Twitch aún no soportan SRT como protocolo de ingesta. Estas plataformas siguen usando RTMP porque su infraestructura fue construida sobre ese protocolo. La migración a SRT requiere actualizar millones de líneas de código y reentrenar a millones de creadores de contenido. La transición tomará años.

Los operadores de plataformas OTT propias adoptan SRT más rápidamente. Una plataforma nueva puede implementar SRT desde el inicio sin costo de migración. Los proveedores de infraestructura como Wowza Streaming Engine y Nimble Streamer soportan SRT desde 2018. La barrera técnica para adopción es baja.

El costo de implementación de SRT es similar al de RTMP. Los encoders que soportan RTMP pueden actualizarse a SRT mediante firmware. Los servidores de ingesta pueden agregar soporte SRT mediante bibliotecas open source. No hay costos de licencia porque SRT es open source. La única barrera es la inercia organizacional.

Preguntas frecuentes sobre SRT y RTMP

¿SRT reemplazará completamente a RTMP?

Eventualmente sí, pero la transición tomará años. RTMP tiene 18 años de inercia y millones de implementaciones existentes. Las plataformas grandes como YouTube y Facebook seguirán soportando RTMP durante años. Pero las implementaciones nuevas deberían usar SRT desde el inicio. RTMP es legacy, SRT es el futuro.

¿SRT funciona con cualquier encoder y servidor de streaming?

SRT requiere soporte específico en el encoder y el servidor. Los encoders modernos de Teradek, LiveU, Dejero y otros soportan SRT nativamente. Los servidores como Wowza, Nimble Streamer y Azure Media Services soportan SRT. Los encoders y servidores antiguos que solo soportan RTMP no pueden usar SRT sin actualización de firmware o software.

¿Cuál es la latencia mínima que SRT puede lograr?

SRT puede lograr latencia de 200 a 500 milisegundos en redes locales con pérdida de paquetes inferior al 1%. En redes públicas con pérdida del 5%, la latencia típica es de 1 a 2 segundos. La latencia depende del tamaño del buffer que se configura. Buffers más pequeños reducen latencia pero aumentan el riesgo de congelamiento si la red se degrada.

¿SRT consume más ancho de banda que RTMP?

SRT consume aproximadamente 10% más de ancho de banda que RTMP debido al overhead de recuperación de errores y encriptación. Para un stream de 5 Mbps, SRT usa 5.5 Mbps. El overhead adicional es aceptable considerando los beneficios de confiabilidad y latencia. En redes con pérdida de paquetes, SRT es más eficiente que RTMP porque no retransmite paquetes innecesariamente.

¿Su organización necesita migrar de RTMP a SRT para transmisiones en vivo confiables? Conozca nuestra ingeniería para streaming en vivo con SRT desde ubicaciones remotas o inicie una consulta técnica con nuestros arquitectos de sistemas.