RTMP y SRT llevan los dos tu imagen y tu sonido por internet. La diferencia está en cómo se las arreglan con una red mala. RTMP va sobre TCP y espera cada paquete hasta que todo se atasca. SRT va sobre UDP, reenvía de forma selectiva los paquetes perdidos y, pasado un tiempo fijado, se rinde en lugar de detener todo el directo.
La respuesta corta para la práctica: SRT para el camino de ti al estudio, RTMP(S) para el camino a la plataforma.
RTMP en pocas palabras
RTMP es el protocolo con el que Twitch, YouTube, Kick y casi todas las demás plataformas reciben directos. RTMPS es lo mismo con cifrado. Pones una dirección de servidor y un stream key, y funciona.
Debajo está TCP. TCP garantiza que todos los datos llegan completos y en el orden correcto. Para una página web es justo lo que hace falta. Para vídeo en directo tiene una pega: si se pierde un paquete, todo lo que va detrás espera hasta que se haya repuesto. Con una conexión estable en casa no se nota. En la red móvil el directo se atasca, la app no da abasto para enviar y al final la plataforma cierra la conexión. Lo que pasa entonces lo describe Por qué tu directo de Twitch se queda offline en una zona sin cobertura.
SRT en pocas palabras
SRT significa «Secure Reliable Transport». Es un protocolo abierto, desarrollado por Haivision y de código abierto desde 2017. Se hizo justo para los trayectos en los que RTMP sufre: red móvil, wifis saturados, caminos largos por el internet público.
SRT va sobre UDP. UDP no garantiza nada, simplemente echa los paquetes a andar. La fiabilidad la trae el propio SRT: el receptor nota qué paquete falta y vuelve a pedir justo ese. Para eso hay una ventana de tiempo, la latencia. Si el paquete llega dentro de ese tiempo, nadie nota nada. Si no llega, se salta, y el directo sigue. Cómo funciona en detalle lo explica ¿Qué es SRT?.
La comparación
| RTMP(S) | SRT | |
|---|---|---|
| Transporte | TCP | UDP |
| Paquete perdido | todo lo que va detrás espera | se reenvía de forma selectiva |
| Si el reenvío llega tarde | atasco, al final corte | el paquete se salta, breve fallo de imagen |
| Retardo | crece sin control cuando la red es mala | ventana de tiempo fija, que ajustas tú |
| Plataformas como destino | prácticamente en todas partes | pocas veces |
| En redes con restricciones | pasa casi siempre | fracasa si la red bloquea UDP |
| Configuración | dirección de servidor y stream key | dirección con puerto, a menudo con stream ID |
| Uso típico | del estudio o del PC a la plataforma | de la cámara, el móvil o el encoder al estudio |
Dos filas merecen una explicación.
Retardo. En SRT fijas tú cuánto se espera a un paquete que falta. Ese valor es la latencia, y vale para todo el directo. Un valor mayor aguanta redes peores y a cambio cuesta algo más de retardo. En RTMP no hay un control así. El retardo es pequeño con buena red y crece con mala, sin que puedas influir en ello.
Redes con restricciones. Muchos wifis de hoteles, de empresas y públicos bloquean o limitan UDP. Entonces SRT no pasa, aunque la red funcione para lo demás. La salida son los datos móviles del teléfono o compartir su conexión. Más en UDP bloqueado en el wifi del hotel.
¿Por qué no SRT hasta la plataforma y listo?
Porque las plataformas esperan RTMP(S). No es una desventaja: el trayecto de un centro de datos a la plataforma es estable, y ahí RTMP hace lo que debe. Lo difícil es solo el primer tramo, de ti hasta internet. Para ese tramo se hizo SRT.
De ahí sale el montaje habitual para directos desde la calle:
- La cámara, el móvil o el encoder envían por SRT a una estación en el centro de datos.
- La estación envía por RTMP(S) a la plataforma.
Esa estación puede ser un servidor propio, un relay, un OBS alquilado o un estudio en la nube. Las diferencias están en Relay, OBS en la nube o estudio en la nube.
PGM.STUDIO trabaja exactamente así. Tu estudio recibe hasta ocho fuentes por SRT y envía el programa terminado por RTMP(S) a hasta ocho destinos. Si una fuente se cae, la conexión con la plataforma se mantiene.
Cuándo RTMP basta de sobra
Si haces directo desde casa por fibra o cable y envías directamente a una plataforma, no necesitas SRT. La conexión es estable, y RTMP es más fácil de configurar. SRT merece la pena en cuanto uno de los trayectos se vuelve inseguro: red móvil, wifi ajeno, una cámara en otro lugar.
Conclusión
- De ti al estudio: SRT. Aguanta las pérdidas de paquetes, y tú decides cuánto retardo das a cambio.
- Del estudio a la plataforma: RTMP(S). Es lo que aceptan las plataformas, y en ese trayecto no hay nada que reparar.