RTMP vs HLS: diferencias y cuándo usar cada uno

Si vas a transmitir audio o video por internet, tarde o temprano te topas con dos siglas que parecen hacer lo mismo pero no lo hacen: RTMP y HLS. La confusión es normal, porque ambos aparecen cuando montas una transmisión. Entender en qué se diferencian te ahorra dolores de cabeza con la latencia, la compatibilidad y el costo. En esta guía te explico qué es cada uno, cómo funcionan por dentro y cuándo conviene usar uno u otro.

Qué es RTMP

RTMP (Real-Time Messaging Protocol) nació con Flash a principios de los 2000 para enviar audio y video con poca demora. Funciona sobre TCP y mantiene una conexión persistente entre quien emite y el servidor. Esa conexión continua es la clave de su principal virtud: una latencia muy baja, normalmente de 2 a 5 segundos.

Hoy casi nadie reproduce RTMP directamente en el navegador, porque dependía de Flash y Flash dejó de existir en 2020. Pero RTMP sigue siendo el rey de la ingesta (el tramo desde tu equipo hasta el servidor): es el protocolo que usan OBS Studio, vMix, Streamlabs y casi todos los codificadores de hardware para mandar tu señal desde la computadora o la cámara hasta el servidor de streaming.

• Transporte: TCP, conexión abierta y constante.
• Latencia: baja (2-5 s).
• Uso típico: subir la señal (ingest/contribution).
• Debilidad: no se reproduce nativo en navegadores ni móviles; no tiene bitrate adaptativo por sí solo.

Qué es HLS

HLS (HTTP Live Streaming), creado por Apple, toma un camino distinto. En vez de una conexión continua, parte el video en segmentos cortos (archivos .ts o fMP4 de entre 2 y 10 segundos) y publica una lista de reproducción .m3u8 que le dice al reproductor qué segmentos descargar y en qué orden.

Como viaja sobre HTTP, aprovecha cualquier servidor web, CDN y caché que ya exista en internet. Eso lo hace barato de distribuir y muy tolerante a redes imperfectas. Además soporta bitrate adaptativo (ABR): ofreces varias calidades y el reproductor salta entre ellas según la conexión de cada espectador. La contra histórica es la latencia: de 15 a 30 segundos en su versión clásica, porque el reproductor acumula varios segmentos antes de empezar. La variante LL-HLS (Low-Latency HLS) la baja a 2-5 segundos usando fragmentos parciales y entrega anticipada.

• Transporte: HTTP, por segmentos independientes.
• Latencia: alta en clásico (15-30 s); baja con LL-HLS.
• Uso típico: entregar la señal al público (delivery/playback).
• Fortaleza: se reproduce en casi todo, escala con CDN y se adapta a la red.

Diferencias clave en resumen

1. Dónde vive cada uno: RTMP brilla subiendo la señal; HLS brilla repartiéndola a miles de personas.
2. Compatibilidad: HLS funciona en iPhone, Android, navegadores modernos y Smart TVs sin plugins. RTMP necesita software especial para reproducirse.
3. Escalabilidad: como HLS son simples archivos HTTP, una CDN los cachea y sirve a una audiencia enorme sin sobrecargar tu servidor. RTMP mantiene una conexión por espectador, mucho más pesada de escalar.
4. Calidad adaptativa: HLS ajusta la resolución si al usuario le baja el internet; RTMP entrega una sola calidad.
5. Latencia: RTMP es naturalmente más inmediato; HLS clásico se demora, pero LL-HLS casi empata.

Cuándo usar cada uno

La regla práctica es sencilla: RTMP para entrar, HLS para salir.

• Usa RTMP cuando estás configurando el codificador (OBS, cámara IP, mezclador) que envía tu programa al servidor. Es estable, lo soporta todo equipo de transmisión y mantiene la demora mínima en ese primer tramo.
• Usa HLS para que el público vea la transmisión en tu web, en el celular o en cualquier dispositivo, sin pedirles instalar nada y aguantando picos de audiencia.
• Si tu caso exige conversación en tiempo casi real (subastas, clases interactivas, apuestas), evalúa LL-HLS o incluso WebRTC, que baja la latencia por debajo de un segundo a cambio de más complejidad.

La arquitectura más común: los dos juntos

En la práctica no eliges uno "contra" el otro, sino que los encadenas. El flujo típico de una emisora o de un canal en vivo es así:

1. Tu codificador envía por RTMP hacia un servidor de medios (Wowza, nginx con el módulo RTMP, o un panel ya armado).
2. El servidor transcodifica esa señal en varias calidades (por ejemplo 1080p, 720p y 480p).
3. Genera los segmentos y las listas .m3u8 de HLS.
4. Una CDN distribuye esos segmentos a los espectadores por todo el mundo.

Así aprovechas lo mejor de cada protocolo: la inmediatez de RTMP al subir y la compatibilidad y escala de HLS al bajar. En gurztechnology este encadenamiento RTMP a HLS viene ya configurado en los planes de live streaming, así que no tienes que montar el servidor de medios desde cero.

Errores comunes

• Querer reproducir RTMP en el navegador: ya no es viable sin Flash. Convierte a HLS para el público.
• Esperar latencia de RTMP con HLS clásico: si necesitas pocos segundos de demora, activa LL-HLS; no basta con acortar los segmentos a lo loco, porque fragmentos demasiado cortos aumentan las peticiones HTTP.
• Olvidar el keyframe: el intervalo de keyframes (GOP) del codificador debe cuadrar con el tamaño del segmento HLS, normalmente cada 2 segundos, o el reproductor mostrará cortes.

Conclusión

RTMP y HLS no compiten: se complementan. Piensa en RTMP como la tubería que mete tu señal al servidor con poca demora, y en HLS como la red de reparto que la lleva, adaptada y sin plugins, a toda tu audiencia. Para una transmisión estable y que aguante crecer, lo ideal es usar los dos en cadena. Define primero cuánta latencia toleras y a cuánta gente vas a llegar, y la elección de protocolos se vuelve obvia.