La baja latencia en la transmisión se ha convertido en un requisito indispensable en cualquier licitación y concurso para la construcción de estaciones principales y redes de entrega de contenido (CDN).
Los operadores exigen a los proveedores baja latencia en todas partes: transmisión de noticias, conciertos, entrevistas, programas de entrevistas, competiciones de eSports y juegos de azar.
En este punto, muchos jugadores buscan opciones como 1xBet casino sin complicaciones, donde la navegación es estable y rápida, donde cada milisegundo marca la diferencia.
Tabla de Contenido
¿Qué es la latencia en la transmisión?
Es la diferencia de tiempo entre la captura de un cuadro de video por un dispositivo (cámara, servidor de play-out, codificador) y su reproducción en la pantalla del usuario final.
La baja latencia no debe reducir la calidad de la señal. Se requiere una mínima búferización durante codificación y multiplexación, manteniendo una imagen fluida y nítida en cualquier dispositivo.
Otra condición es la entrega garantizada: los paquetes perdidos deben recuperarse y las redes públicas no deben causar problemas.
Las empresas migran cada vez más servicios a la nube para ahorrar en alquileres, electricidad y equipos. Esto aumenta los requisitos de baja latencia, con un tiempo de ida y vuelta (RTT) prolongado. Es especialmente relevante en transmisiones de video HD y UHD, por ejemplo, entre un servidor en EE. UU. y un consumidor en Europa.
Protocolo UDP
La primera tecnología usada en teledifusión moderna para baja latencia fue el tráfico multicast con contenido MPEG Transport Stream sobre UDP.
Se utilizaba en redes cerradas con baja carga, donde la pérdida de paquetes era mínima.
Ejemplo: transmisión desde un codificador a un modulador en la estación principal o IPTV sobre línea dedicada.
Las grandes empresas lograron latencias de hasta 80 ms con 25 cuadros/s en redes Ethernet. En grandes eventos como la Copa Confederaciones 2017 o la Copa Mundial FIFA 2022, la latencia total fue de 220–240 ms.
En redes externas, aparecen problemas: interferencias, shaping, tráfico elevado, fallos de equipo, cables dañados, errores de software. Allí, además de baja latencia, se necesita reenvío de paquetes.
En UDP, la corrección de errores FEC maneja esto, aunque incrementa ancho de banda, redundancia y latencia. El porcentaje de paquetes recuperados siempre es limitado, por lo que a largas distancias se necesita añadir tráfico redundante.
Protocolo TCP
Con TCP, si la suma de comprobación no coincide, se reenvía el paquete. Sin soporte de SACK, se reenvía toda la cadena desde el paquete perdido, lo que aumenta la latencia.
Antes se evitaba TCP en transmisiones en vivo, ya que la latencia crecía por verificaciones, reenvíos, saludo de tres vías, arranque lento y prevención de congestión.
La latencia antes del inicio de transmisión podía ser hasta cinco veces el RTT. Aumentar ancho de banda apenas reducía esa latencia.
Las aplicaciones sobre TCP tampoco reciben retroalimentación completa sobre la conexión, y protocolos superiores no pueden ajustarlo.
Por ello, se han desarrollado protocolos sobre UDP más eficientes incluso en redes públicas. De TCP analizaremos RTMP, HLS y CMAF. De UDP, WebRTC y SRT.
Protocolo RTMP
Originalmente de Macromedia (luego Adobe), RTMP fue popular con Flash. Divide flujos en fragmentos y soporta multiplexación de audio y video.
Aunque muchas CDN ya no lo soportan, sigue siendo usado en servidores como Nginx y en transmisiones hacia plataformas como YouTube y Facebook (RTMPS).
Su desventaja: no es compatible con HTML5 ni navegadores actuales. Depende de plugins de Flash y presenta latencias mínimas de 2 segundos en un flujo completo.
Protocolo CMAF
CMAF fue creado por Apple y Microsoft para transmisión adaptativa sobre HTTP. Combina lo mejor de HLS y MPEG DASH.
Por defecto no es de baja latencia, pero existe Low Latency CMAF. Usa chunk encoding y chunked transfer encoding para reducir la latencia a menos de 3 segundos.
Sus ventajas: escalabilidad en CDN, cifrado, compatibilidad con HEVC y WebVTT. Su reto: los reproductores deben soportar LL CMAF.
Protocolo Low Latency HLS
Apple presentó LL HLS en 2019. Usa segmentos parciales de hasta 200 ms y listas de reproducción diferenciales.
Con soporte completo en CDN y reproductores, logra latencias menores a 3 segundos. Mantiene compatibilidad con HLS estándar y es altamente escalable.
Protocolo WebRTC
Creado por Google en 2011, usado en Google Hangouts, Slack y YouTube Live. Implementa cifrado DTLS-SRTP en conexiones peer-to-peer.
Funciona sobre UDP, atravesando cortafuegos sin pérdida de calidad. Usa servidores STUN y TURN para establecer conexiones y soporta códecs como Opus y VP8.
- Ventajas: latencia declarada por Google menor a 1 segundo.
- Limitaciones: difícil de escalar, escaso soporte en CDN, máxima resolución 720p y 30 fps.
Protocolo SRT
Desarrollado en 2012, basado en UDT. Usa ARQ para recuperación de paquetes y admite cifrado AES de 128 y 256 bits.
Reenvía solo el paquete perdido, no toda la cadena. Esto reduce la latencia frente a TCP. Puede alcanzar latencias de 120 ms en redes cerradas, recomendándose 3–4 veces el RTT para estabilidad.
Es bidireccional, soporta multiplexación y control de congestión. Ha demostrado mejor rendimiento que RTMP en largas distancias y con alto bitrate.
En 2017, su código se abrió y se creó la SRT Alliance (Open-source SRT), con cientos de miembros.
Resumen
Los protocolos abiertos y bien documentados crecen rápido. WebRTC y SRT tienen futuro prometedor, superando a transmisiones adaptativas HTTP en latencia y fiabilidad.
RTMP, en cambio, pierde terreno por falta de soporte nativo en navegadores. El protocolo RIST aparece como alternativa emergente, pero ese es tema para otro análisis.