RTMP, SRT o WHIP: cómo elegir el protocolo de ingesta

Antes de la comparación: el error que les cuesta a muchos su primera hora está en la URL de SRT, y no genera ningún mensaje de error. Lee la siguiente sección aunque te saltes todo lo demás.

El fallo que parece que no pasa nada

Una URL de ingesta SRT lleva un streamid con este aspecto: #!::r=live/sk_srt_…,m=publish. Esos caracteres —#, !, :, ,— son justo los que una persona cuidadosa codifica por costumbre con porcentajes. No lo hagas. La biblioteca SRT no decodifica el streamid; reenvía los bytes literales al servidor. Por eso un streamid codificado llega como un nombre de stream que empieza por %23, el servidor trata la conexión como una solicitud de reproducción y no de publicación, y nadie te avisa de nada. Tu codificador muestra una conexión sana. La tarjeta del stream no muestra señal. No hay ningún error en ninguna parte.

Pega la URL de SRT exactamente como la devuelve la API. dcast la entrega en su forma literal, lista para publicar, en data.ingest.srt de GET /api/v1/streams/:id, y el mismo valor en data.ingest.srtDisplay, que existe solo como alias para integraciones antiguas. Cualquiera de las dos va directa a tu codificador sin reescribir nada.

Qué acepta dcast

Una tarjeta de stream puede alimentarse con cualquiera de estas opciones. Eliges tú en cada tarjeta, y la elección no cambia la imagen que reciben tus espectadores.

El nombre de host es siempre a.dcast.pro: el punto de entrada del pool de enrutamiento, nunca el nombre de un servidor concreto. Es a propósito: así la dirección que configuraste una vez sigue funcionando cuando el stream cae en otra máquina.

RTMP: el que siempre funciona

RTMP es antiguo, y esa es toda su ventaja. Cualquier codificador, cualquier cámara con modo de streaming, cualquier app del móvil y cualquier aparato que te pongan en las manos en el lugar del evento puede enviar RTMP sin más configuración que un servidor y una clave. Si transmites desde una red estable y no estás resolviendo un problema concreto, RTMP es la opción correcta y puedes dejar de leer aquí.

Su punto débil es lo que ocurre cuando la red no es estable. RTMP va sobre TCP, y TCP gestiona la pérdida retransmitiendo y esperando. En un buen enlace eso no se nota. En un enlace con pérdida de paquetes real sí: el stream acumula una latencia que nunca recupera, o se congela, y la forma de recuperarse va desde algo elegante hasta una desconexión, según el codificador.

Si tu codificador pide el servidor y la clave por separado, divide la URL por la última barra: servidor rtmp://a.dcast.pro/live, clave sk_rtmp_…. (Las claves de stream llevan el prefijo del protocolo para el que se creó la tarjeta —sk_rtmp_, sk_srt_, sk_webrtc_—, así que la clave que pegues debe corresponder a la puerta a la que llamas.)

SRT: el de las redes malas

SRT existe para el caso que RTMP gestiona mal: un enlace con pérdida de paquetes que no puedes arreglar, lo que en la práctica significa redes móviles, wifi público de recintos y cualquier cosa que cruce una gran distancia.

La idea es un presupuesto de latencia fijo. En lugar de retransmitir hasta que el paquete llegue, tarde lo que tarde, SRT mantiene un búfer del tamaño elegido y vuelve a pedir los paquetes perdidos solo mientras todavía hay tiempo de colocarlos en su sitio. Los paquetes que no pueden llegar a tiempo se descartan en vez de retrasar todo lo que viene detrás. El resultado es un stream con un retardo predecible y una degradación suave ante la pérdida, en lugar de retardo impredecible y congelaciones.

Ese búfer es el parámetro latency, expresado en milisegundos. Las URL que emite dcast llevan 500 ms, y puedes subirlo hasta 7000. El intercambio es directo y no hay ningún ajuste mágico: un valor mayor aguanta peor pérdida y añade exactamente ese retardo. Si tu stream pierde paquetes, súbelo.

Bajarlo por debajo de 500 es lo único que no va a funcionar, y vale la pena saber por qué en vez de descubrirlo. Nuestra ingesta declara sus propios 500 ms, y una conexión SRT se queda con la mayor de las cifras de ambos extremos, así que un codificador que pide 80 ms sigue obteniendo 500. El número es un mínimo, no solo un valor por defecto.

Hay otros dos ajustes de SRT que conviene conocer. Modo: dcast emite URL en modo caller, es decir, tu codificador inicia la conexión hacia fuera, que es lo que funciona detrás de un router sin redirección de puertos. listener y rendezvous existen para las configuraciones que los necesitan. Y passphrase: SRT puede cifrar el enlace; si defines una, debe tener al menos diez caracteres.

WHIP: el del navegador

WHIP es la forma en que publica una fuente WebRTC. En lugar de una URL de stream, envías una oferta SDP a un endpoint HTTPS y se establece una conexión peer. dcast devuelve ese endpoint junto con los demás en la tarjeta del stream.

Úsalo cuando tu fuente sea un navegador —un invitado que no tiene nada instalado, una superficie de control web, una pantalla compartida— o cuando necesites una latencia de contribución inferior a la que puede ofrecer una ruta segmentada. Los codificadores compatibles con WHIP lo ofrecen como un servicio de streaming donde pegas la URL devuelta tal cual; no hay campo aparte para la clave de stream, porque la clave ya va en la URL.

Su limitación es que WebRTC es más exigente de operar que un envío por TCP. Es más sensible a las redes restrictivas y los codificadores por hardware lo soportan de forma menos universal que RTMP.

El protocolo que elijas no cambia tu imagen

Esta es la parte que le ahorra a la gente muchas pruebas. Sea cual sea el protocolo que entrega tu stream, se normaliza a una única forma interna antes de que ocurra nada más, y la escalera de codificación que se ejecuta después es idéntica. Los mismos escalones, los mismos techos de bitrate, el mismo intervalo de keyframes de 2 segundos, los mismos segmentos de 4 segundos con dos keyframes cada uno.

Es decir: un stream SRT y un stream RTMP que llevan la misma fuente con el mismo bitrate producen el mismo resultado. Elegir SRT no te da mejor imagen, y elegir RTMP no te la empeora. Elige en función de cómo se comporta tu red, que es lo único a lo que realmente afecta la elección.

La tasa de fotogramas también se decide en nuestro lado y no la determina el protocolo, y de forma idéntica para los tres: en el momento de escribir esto, la escalera en directo se codifica a 30 fps envíes lo que envíes.

No construyas la URL de ingesta a mano

Cada dirección de ingesta que te da dcast la emite la API para una tarjeta de stream concreta, y cada una de sus partes cumple una función. GET /api/v1/streams/:id las devuelve todas juntas en data.ingest, y el flujo de trabajo correcto es copiarlas de ahí cada vez, en lugar de guardar una URL en un documento y editarle la clave.

El nombre de host es el punto de entrada del pool y no el nombre de una máquina, así que sigue siendo válido aunque la semana que viene tu stream se sirva desde otro sitio. La clave identifica tu tarjeta. En SRT, el streamid además lleva el modo —m=publish es lo que convierte la conexión en una publicación y no en una reproducción—, y precisamente por eso el fallo de codificación del principio de este artículo es tan silencioso: si corrompes el streamid no has enviado una solicitud mal formada, has enviado una solicitud perfectamente válida para ver un stream que no existe.

Dos hábitos evitan casi todo esto. Copia la URL entera, incluido todo lo que va después del ?, de una sola vez. Y cuando un codificador se empeñe en tener campos separados de servidor y clave, divide por la última barra y pega las dos mitades en lugar de volver a teclear ninguna.

Si estás haciendo una integración en lugar de configurar a mano, pide los destinos de ingesta en el momento de usarlos en vez de guardarlos en caché, por el mismo motivo: el valor que te dan es correcto ahora, y volver a pedirlo cuesta poco.

Cifrar el enlace

SRT puede cifrar el stream entre tu codificador y nosotros con una passphrase. Merece la pena activarlo siempre que el enlace atraviese una red que no controlas —el wifi de invitados de un recinto, un hotel, un enlace compartido en un congreso—, porque en esas redes la señal de contribución es lo único que de verdad no puedes repetir si alguien interfiere con ella.

La passphrase debe tener al menos diez caracteres. Pon el mismo valor en ambos extremos; si no coinciden, el handshake falla en lugar de degradarse, y ese es el comportamiento que quieres, porque bajar en silencio a una conexión sin cifrar sería peor que un rechazo.

El cifrado cuesta un poco de procesamiento en cada extremo y nada en calidad de imagen. Si ya usas SRT porque la red no es de fiar, el mismo razonamiento suele aplicarse a si debería poder leerse.

Cómo elegir, en un párrafo

Si tu red es una conexión por cable en un edificio que controlas, usa RTMP. Si estás en una conexión móvil, en el wifi de un recinto o enviando de un continente a otro, usa SRT y sube la latencia hasta que el stream quede limpio. Si tu fuente es un navegador web, usa WHIP. Si el contenido ya existe como stream en otro sitio, usa HTTP pull y deja que lo recojamos nosotros en vez de reemitirlo a mano. Esas cuatro frases cubren casi todos los casos reales.

Probar la ingesta antes del evento

Haz la prueba con la URL real de la tarjeta de stream real, no con una URL que hayas montado tú. La mayoría de los fallos de la primera vez son una dirección hecha a mano.

Prueba desde el recinto real, con la conexión real y a la hora real del día si el recinto se llena. Una red que va limpia a las nueve de la mañana y está saturada a las siete de la tarde es lo normal, no la excepción.

En el caso concreto de SRT, durante la prueba vigila los contadores de pérdida y retransmisión de tu codificador en lugar de mirar la imagen. La imagen se ve bien justo hasta que se agota el presupuesto de latencia, así que los contadores te avisan y la imagen no.

Y comprueba que la tarjeta del stream muestra señal, no solo que tu codificador aparece conectado. Son dos afirmaciones distintas, y el fallo del streamid de SRT del principio de este artículo es precisamente el caso en que la primera es verdad y la segunda es falsa.