SRT es un protocolo de transmisión para vídeo en directo hecho para redes malas. Envía imagen y sonido sobre UDP y manda otra vez, dentro de una ventana de tiempo corta, los paquetes que se pierden por el camino. Así un directo se mantiene limpio aunque la red móvil se trague datos de vez en cuando.
El nombre significa «Secure Reliable Transport». Lo desarrolló la empresa Haivision, y es de código abierto desde 2017. Hoy lo envían muchísimos programas y aparatos: OBS, apps de streaming para el móvil, encoders de hardware, software de producción.
Por qué UDP
En internet hay dos maneras básicas de enviar datos. TCP se asegura de que todo llegue completo y en el orden correcto, y para eso espera si hace falta. UDP echa los paquetes a andar y no se ocupa de nada más.
Para vídeo en directo, esperar es el problema. Una imagen que llega dos segundos tarde no vale nada, y todo lo que va detrás se retrasa con ella. Por eso SRT se construye sobre UDP y decide él mismo qué se reenvía y qué no. La comparación directa con RTMP, que se basa en TCP, la encuentras en SRT o RTMP.
Reenviar: cómo repara SRT las pérdidas
Cada paquete lleva un número correlativo. Con él, el receptor ve al momento cuándo falta uno: después del número 41 llega el 43, así que falta el 42. Se lo comunica al emisor, y este envía otra vez justo ese paquete. Todos los demás paquetes siguen circulando con normalidad mientras tanto.
Si el paquete reenviado llega a tiempo, se coloca en su sitio. En la imagen no se ve nada.
La ventana de latencia
«A tiempo» es en SRT un número: la latencia. El receptor retiene el directo ese tiempo antes de pasarlo adelante. En ese búfer hay sitio para rellenar huecos.
- Una latencia pequeña significa poco retardo, pero poco tiempo para reenviar. En una buena conexión basta.
- Una latencia grande da más tiempo a la red. El directo aguanta más pérdidas y, a cambio, llega otro tanto más tarde.
Si un paquete no lo consigue ni siquiera dentro de la ventana, se salta. El resultado es un breve fallo de imagen o un hueco en el sonido, pero el directo sigue y no se atasca.
La latencia la ajustas en tu app. En PGM.STUDIO, el estudio guarda en búfer 200 ms de forma predeterminada; si tu app pide más, vale el valor mayor. Cómo encontrar el adecuado está en Ajustar la latencia SRT.
Caller y listener
En una conexión SRT hay dos papeles, que solo describen quién establece la conexión:
- El listener espera una conexión en una dirección fija.
- El caller llama a esa dirección.
Eso no tiene nada que ver con quién envía el vídeo. En la práctica, el servidor es el listener, porque tiene una dirección fija y accesible públicamente. Tu móvil o tu encoder es el caller, porque puede llamar desde cualquier red. Muchas apps lo llaman modo «Caller», otras ni lo preguntan y solo quieren una dirección.
En PGM.STUDIO, tu estudio es el listener y tu app el caller.
El stream ID
Una dirección SRT se compone de host y puerto. A menudo lleva además un stream ID:
srt://<host>:<port>?streamid=<id>
El stream ID es un texto corto que el caller envía al establecer la conexión. Con él, el servidor reconoce a qué entrada pertenece la conexión. Así varias cámaras pueden enviar al mismo puerto y aun así cada una acaba en su sitio.
Algunas apps aceptan la dirección entera en un campo, otras quieren host, puerto y stream ID por separado. El contenido es el mismo. En tu estudio, la dirección de cada entrada está en la pestaña «Entradas». Normalmente es la misma para todos los directos, así que la configuras una vez.
Lo que transporta SRT
SRT es solo el camino de transporte. Lo que va dentro es casi siempre un flujo MPEG-TS con vídeo y sonido, como el que genera cualquier app de SRT. PGM.STUDIO acepta en él vídeo H.264 o H.265 y sonido AAC. Cuándo compensa cada códec lo explica ¿H.264 o H.265 para el camino al estudio?.
SRT también puede cifrar el directo; para eso muchas apps tienen un campo para una passphrase. Si lo necesitas depende del otro extremo. En PGM.STUDIO ese campo se queda vacío.
Dónde SRT llega a sus límites
- UDP bloqueado. Muchos wifis de hoteles, de empresas y públicos bloquean o limitan UDP. Entonces SRT no pasa. La salida son los datos móviles o compartir la conexión del móvil; consulta UDP bloqueado en el wifi del hotel.
- Muy poco ancho de banda. Reenviar cuesta datos adicionales. Si la conexión ya está llena con el propio directo, no queda nada para eso. Entonces un bitrate más bajo ayuda más que una latencia más alta; consulta Qué bitrate para directos IRL.
- Una red que desaparece del todo. SRT repara huecos, no salva minutos sin cobertura. Para eso hace falta otro extremo que sostenga mientras tanto el directo hacia la plataforma. Más en Por qué tu directo de Twitch se queda offline en una zona sin cobertura.
Una extensión llamada SRTLA agrupa varias conexiones móviles en una. PGM.STUDIO todavía no la acepta hoy; una conexión SRT sencilla desde las mismas apps funciona.