SRTLA vs SRT vs RTMP: ¿qué protocolo es mejor para el streaming IRL?

Para el streaming IRL, SRT suele encajar mejor que RTMP, y SRTLA es la mejor opción cuando puedes enviar por varias conexiones a la vez. RTMP sigue siendo necesario porque las plataformas de streaming lo esperan, pero su lugar está en el último tramo estable entre un servidor y la plataforma, no en una red celular.

Esta guía explica cómo funcionan los tres protocolos, cómo se comportan en conexiones celulares y cómo ajustar bien la latencia SRT.

¿Qué es RTMP?

RTMP (Real-Time Messaging Protocol) fue especificado por Adobe y publicado como especificación abierta en 2009. Está diseñado para funcionar sobre un transporte fiable como TCP, que garantiza que todos los mensajes lleguen en orden (especificación de RTMP). El borrador del IETF sobre SRT llama a RTMP el estándar de facto para la contribución por internet público, y por eso prácticamente todos los encoders, apps y plataformas lo entienden.

El punto débil viene del mismo diseño. Como RTMP depende de TCP, solo ofrece una fiabilidad aceptable en conexiones con un tiempo de ida y vuelta bajo, y el control de congestión de TCP le impide aprovechar todo el ancho de banda de una conexión. Es una mala combinación para un celular que salta de una antena a otra.

El RTMP clásico también tiene límites de códec: solo admite dos canales de audio y un conjunto restringido de códecs, sin HEVC, VP9 ni AV1. La especificación Enhanced RTMP añade esos códecs, y YouTube ya indica H.264, H.265 y AV1 para RTMP(S). Eso sí, tanto tu software como la plataforma tienen que ser compatibles. RTMPS es RTMP dentro de una conexión SSL cifrada, y YouTube lo recomienda precisamente por eso.

¿Qué es SRT?

SRT (Secure Reliable Transport) es un protocolo de código abierto que se desarrolla en el repositorio público de GitHub de Haivision y se describe en un Internet-Draft del IETF. Funciona sobre UDP y añade la fiabilidad de la que UDP carece por sí solo. El método principal es ARQ (Automatic Repeat reQuest): cuando el receptor detecta que falta un paquete, pide al emisor que lo envíe de nuevo. El protocolo también admite Forward Error Correction y su propio bonding de conexiones.

Tres propiedades importan para el streaming IRL:

• Búfer de latencia: El receptor retiene cada paquete durante un tiempo configurado antes de pasarlo. Esta ventana da tiempo a que se retransmitan los paquetes perdidos y reproduce la temporización original del stream. Los paquetes que llegan demasiado tarde pueden descartarse, así que el retraso se mantiene constante en lugar de crecer.
• Cifrado: SRT admite cifrado AES con claves de 128, 192 o 256 bits.
• Independencia del códec: SRT es agnóstico respecto a la carga útil. Transporta cualquier códec, resolución o tasa de fotogramas, incluido HEVC.

El equilibrio es inherente al diseño. El búfer añade retraso a propósito, así que tienes que elegir un valor de latencia que encaje con tu red (más sobre esto abajo).

¿Qué es SRTLA?

SRTLA es un proxy de transporte SRT con agregación de enlaces. Nace del proyecto BELABOX y transporta tráfico SRT por varios enlaces de red para ganar capacidad y redundancia. El tráfico se reparte de forma dinámica según el estado de la red, y su uso previsto es el bonding de módems celulares para streaming en vivo.

SRTLA no sustituye a SRT. Se sitúa entre el emisor y el receptor SRT: tu dispositivo envía el stream SRT, por ejemplo, por dos tarjetas SIM o por una SIM más Wi-Fi, y un receptor que entienda SRTLA vuelve a juntar los paquetes y los entrega como un stream SRT normal. De ahí se derivan tres consecuencias prácticas:

• Necesitas un emisor compatible con SRTLA. La app gratuita para iOS Moblin, por ejemplo, puede usar a la vez una conexión celular, una Wi-Fi y varias conexiones Ethernet. IRL Pro y los dispositivos BELABOX también ofrecen bonding SRTLA.
• Necesitas un receptor SRTLA. Una plataforma de streaming o un simple listener SRT no puede hacerlo, así que tiene que haber en medio un servidor con entrada SRTLA.
• Hay que ajustarlo. Los paquetes llegan desordenados por los distintos enlaces. Por eso el README exige opciones en el receptor como lossmaxttl y una latencia adecuada.

RTMP vs SRT vs SRTLA de un vistazo

Por qué las plataformas quieren RTMP y por qué hay un servidor en medio

La documentación para encoders de las grandes plataformas sigue girando en torno a RTMP. YouTube indica RTMP/RTMPS como protocolo del encoder (HLS es la alternativa), y la documentación para desarrolladores de Twitch describe el envío del stream a Twitch por RTMP. Por eso, en la mayoría de los casos no puedes apuntar SRT ni SRTLA directamente a una plataforma.

Un servidor resuelve esto y aporta una segunda ventaja. La cadena es así:

1. Tu celular o encoder envía SRT o SRTLA (o RTMP) a un servidor.
2. Tu software de streaming, como OBS Studio, toma el stream de ese servidor.
3. OBS envía el stream ya terminado a la plataforma por RTMP(S) a través de una conexión estable.

El tramo celular débil usa el protocolo más tolerante, y la plataforma recibe el protocolo que espera por una conexión que no se mueve. Si la señal celular se cae un momento, OBS sigue transmitiendo a la plataforma, así que el stream no se corta para tus espectadores. Tanto tu encoder como OBS inician la conexión hacia el servidor, por lo que no necesitas abrir puertos en tu router.

Eso es lo que hace nuestro IRL Endpoint Server por ti con OBS en tu propio PC. Acepta RTMP, SRT y SRTLA como entrada. Si no tienes un PC para streaming, el IRL Broadcasting Server ejecuta OBS Studio en la nube y admite las mismas tres entradas. Para ver el panorama completo de una configuración IRL, consulta nuestra guía de streaming IRL.

Cómo ajustar la latencia SRT

La latencia SRT no es el retraso total entre la cámara y el espectador. En la documentación de Haivision, describe solo el retraso que introduce el envío por la red. La codificación, la decodificación, OBS y la plataforma se suman a eso. Lo que el ajuste define de verdad es el tiempo extra que espera el receptor para compensar los paquetes tardíos y las retransmisiones.

La base de conocimiento de OBS da una regla práctica para la opción más importante:

• El valor predeterminado es 120 ms.
• El valor debe ser al menos 2,5 veces el tiempo de ida y vuelta entre el encoder y el servidor, en milisegundos.
• En una URL al estilo FFmpeg, que es la que usa OBS, la unidad es el microsegundo. Una latencia de 1 segundo se escribe latency=1000000.

Ejemplo: si un ping a tu servidor muestra un tiempo de ida y vuelta de 80 ms, la regla da un mínimo de 200 ms, así que ingresarías srt://SERVER:PORT?latency=200000. Usa la dirección y el puerto exactos de tu portal de cliente. En OBS, estas opciones se pueden añadir a la URL SRT de una fuente multimedia o de un destino de stream personalizado.

Para los streams hacia nuestros servidores recomendamos una latencia de 2 segundos. Según la app, la ingresas como 2000 (milisegundos) o 2000000 (microsegundos). Casi siempre hay un campo propio para ello. Si no, añádela a la URL SRT, por ejemplo srt://<server>:<port>?streamid=publish:publish/<streamkey>&latency=2000. Es posible usar un valor más bajo, pero recomendamos 2 segundos a propósito para favorecer la estabilidad.

Ten en cuenta algunas cosas:

• Las unidades cambian. La biblioteca SRT y el README de SRTLA usan milisegundos, mientras que las URL al estilo FFmpeg usan microsegundos. Verifica qué unidad espera tu app antes de escribir un valor.
• Ambos lados negocian. Según el borrador de SRT, la latencia de una conexión es el máximo de los valores propuestos por el emisor y el receptor. Bajarla en un lado no sirve de nada si el otro lado pide más.
• Las conexiones celulares y en bonding necesitan margen. La regla anterior es un mínimo, no una recomendación. Una ventana mayor da más tiempo para la retransmisión y el reordenamiento, pero también añade más retraso. El README de SRTLA, por ejemplo, usa latency=2000 (ms) junto con lossmaxttl en su configuración de receptor de ejemplo.
• Cambia una sola cosa a la vez y prueba en movimiento, no solo en tu escritorio.

Ubicación del servidor y latencia

Como la latencia SRT mínima crece con el tiempo de ida y vuelta, la distancia importa. Un servidor más cercano a ti tiene un tiempo de ida y vuelta más corto, así que puedes usar una ventana de latencia menor o conseguir la misma estabilidad con menos retraso. La misma lógica vale para el último tramo: Twitch, por ejemplo, recomienda endpoints de ingest según la ruta de red hasta tu dispositivo.

Ofrecemos servidores en las regiones EE. UU., Europa, Asia y Sudamérica. Con el IRL Endpoint Server puedes elegir entre ellas en el plan estándar y cambiar en cualquier momento en el portal de cliente, lo que ayuda cuando viajas. En el plan Dedicated, configuramos un endpoint para ti, por defecto en la ubicación más cercana a tu dirección de facturación.

¿Qué protocolo deberías usar?

• Una conexión, app moderna: usa SRT y ajusta la latencia según tu tiempo de ida y vuelta.
• Dos o más conexiones: usa SRTLA, si tu app lo admite y tu servidor lo acepta.
• App o cámara que solo habla RTMP: usa RTMP. Funciona, pero tolera peor las redes débiles.
• HEVC: SRT es independiente del códec. Verifica que toda tu cadena, del encoder a OBS y a la plataforma, sea compatible. Configura el intervalo de fotogramas clave del encoder en 2 segundos y, con HEVC en dispositivos Apple, desactiva los B-frames si la app lo permite.

FAQ

¿Es SRT mejor que RTMP para el streaming IRL?

Para el tramo celular, normalmente sí. SRT funciona sobre UDP y retransmite los paquetes perdidos dentro de una ventana de latencia configurable, mientras que RTMP depende de TCP y solo es fiable en conexiones con un tiempo de ida y vuelta bajo. RTMP sigue siendo la opción habitual para la conexión de un servidor u OBS a la plataforma.

¿Cuál es la diferencia entre SRT y SRTLA?

SRT es el protocolo de transporte para una sola conexión. SRTLA transporta el tráfico SRT por varios enlaces de red a la vez, por ejemplo dos tarjetas SIM, para sumar capacidad y redundancia. SRTLA necesita una app compatible con SRTLA y un receptor que lo entienda.

¿Puedo transmitir por SRT directamente a Twitch o YouTube?

La documentación para encoders de ambas plataformas se centra en RTMP(S), con HLS como alternativa en YouTube. Si quieres usar SRT o SRTLA en el tramo celular, pon un servidor y OBS entre tu dispositivo y la plataforma.

¿Qué latencia debo configurar en SRT?

Para los streams hacia nuestros servidores recomendamos 2 segundos, que se ingresan como 2000 (milisegundos) o 2000000 (microsegundos) según la app. Es posible usar un valor más bajo, pero 2 segundos es una decisión deliberada a favor de la estabilidad. Como regla general, la base de conocimiento de OBS indica al menos 2,5 veces el tiempo de ida y vuelta a tu servidor, con un valor predeterminado de 120 ms. Las redes celulares y las conexiones en bonding suelen necesitar más margen, a costa de más retraso.

¿El IRL Endpoint Server admite los tres protocolos?

Sí. El IRL Endpoint Server y el IRL Broadcasting Server aceptan RTMP, SRT y SRTLA como entrada.