Latencia glass-to-glass: el presupuesto que define el streaming

El streaming en vivo se decide sobre un solo número: cuánto tarda un fotograma en viajar desde la lente de la cámara hasta la pantalla del espectador. La industria lo llama latencia glass-to-glass. Ese número determina qué protocolo puede usarse, cuánto cuesta la infraestructura por espectador y qué tipo de interacción es posible entre el evento y la audiencia.

Este artículo desarma el presupuesto: qué etapas lo componen, en qué rangos se mueven hoy, cómo se mide y por qué un mismo evento puede entregarse en 25 segundos o en 400 milisegundos.

Qué es la latencia glass-to-glass

La latencia glass-to-glass es el tiempo transcurrido entre el instante en que un fotograma sale de la lente de la cámara y el instante en que ese mismo fotograma se renderiza en la pantalla del espectador.

La Streaming Video Technology Alliance, Mux, Cloudflare y la Especificación de Creación de HLS de Apple usan la misma definición. Algunos autores la llaman latencia de extremo a extremo (end-to-end latency), de captura a visualización (capture-to-display) o de cámara a pantalla (camera-to-screen); todos los términos significan lo mismo en contexto de streaming. Glass-to-glass (o glass to glass latency en inglés) es el más extendido por ser el menos ambiguo.

Conviene leer cualquier cifra con cuidado: muchos proveedores cotizan solo un tramo parcial del recorrido —latencia de protocolo, de contribución o de primera milla— y lo presentan como glass-to-glass. Qué tramos incluye realmente cada número es la pregunta a la que volveremos al final del artículo.

Ese número se traduce en requisitos muy distintos según el caso de uso.

Por qué importa: casos de uso por nivel de latencia

Diferentes aplicaciones exigen rangos de latencia muy diferentes. Estos son los presupuestos típicos que la industria considera viables hoy:

• Videoconferencias y chats de video. Requieren 150-300 ms de ida y vuelta para que la conversación se sienta natural. Cualquier valor más alto provoca que los participantes empiecen a hablar uno sobre otro.
• Livestreams interactivos. El co-anfitrión, las llamadas y “subir al escenario” a espectadores exigen 200-500 ms. La audiencia pasiva tolera más latencia si no interviene en directo.
• Compras en vivo y subastas. Las pujas en tiempo real y las demostraciones de producto necesitan 200-500 ms para que el chat y las compras estén sincronizados con lo que ocurre en pantalla. Cada décima extra se traduce en ventas perdidas y confusión del cliente.
• Casino en vivo. Las mesas con dealer real —ruleta, blackjack, baccarat— viven en el régimen de baja latencia: típicamente entre 0,5 y 2 segundos en despliegues globales, y por debajo del segundo (200-500 ms) en las configuraciones más optimizadas sobre WebRTC con servidores de borde cercanos al jugador. La interacción —apostar contra eventos que se renderizan en vivo— exige que la ventana de apuestas y el resultado del evento sigan temporalmente alineados con lo que ve el jugador; cualquier desfase rompe la confianza en la mecánica. Un ejemplo de implementación comercial es la sala de ruleta en vivo en Casino777, donde el flujo del croupier se entrega con latencia suficientemente baja como para sostener esa alineación durante toda la jugada.
• Telemedicina. Las consultas remotas necesitan 200-300 ms para una interacción natural entre médico y paciente. Aquí la estabilidad pesa más que el mínimo absoluto.
• Cloud gaming. Exige el presupuesto más estricto: 60-100 ms totales desde la entrada del mando hasta la pantalla. Los juegos de lucha y los shooters competitivos viven en el suelo de ese rango.

Otras aplicaciones interactivas viven en el mismo rango general de 200-500 ms: las aulas virtuales y tutorías, las sesiones de soporte al cliente con navegación compartida, las experiencias de watch party deportivo (donde el requisito real no es la latencia absoluta sino que todos los espectadores estén alineados entre sí) y los sistemas de vigilancia con audio bidireccional para emitir advertencias verbales. Todas comparten la misma curva: por encima de los 500 ms la interacción se rompe.

Tres niveles asoman: lo conversacional vive por debajo de 300 ms, lo interactivo tolera hasta 500 ms, y el cloud gaming y el audio bidireccional viven en presupuestos aún más estrictos. La pregunta de diseño previa a elegir cualquier protocolo es qué tipo de interacción tiene que soportar el producto.

Para entender por qué algunas aplicaciones lo logran y otras no, hay que ver dónde se acumula el tiempo en el recorrido del fotograma.

Dónde se acumula la latencia: los siete contribuyentes del presupuesto

La latencia glass-to-glass es un problema de suma. Empieza en la cámara, termina en la pantalla, y cada etapa retiene el fotograma un tiempo antes de pasarlo a la siguiente. Hay siete etapas que vale la pena nombrar; los rangos siguientes corresponden a mediciones de producción de 2026 reportadas por Bitmovin, Mux, Wowza, Cloudflare y AWS Elemental.

Cinco de los siete son relativamente pequeños: captura, codificador, contribución, CDN y decodificador suman típicamente 200-700 ms en cualquier pila razonable. La capa de red de contribución usa transporte UDP en los protocolos en tiempo real (WebRTC, SRT, RIST) precisamente porque TCP introduce head-of-line blocking —un solo paquete perdido bloquea la entrega de los siguientes hasta su retransmisión—, lo cual dificulta seriamente alcanzar latencias conversacionales.

Las dos etapas que dominan el presupuesto son el empaquetador y el búfer del reproductor.

Una configuración HLS clásica usa segmentos de 6 segundos, y el empaquetador no puede emitir un segmento hasta que el codificador haya producido seis segundos completos de video. Esa única decisión añade 6 segundos antes de que un solo byte salga del empaquetador.

HLS de baja latencia (LL-HLS, definido en la Especificación de Creación de HLS de Apple y en el draft draft-pantos-hls-rfc8216bis mediante EXT-X-PART-INF y PART-HOLD-BACK) y DASH de baja latencia (Modos de Baja Latencia de DASH-IF) resuelven esto emitiendo segmentos parciales o CMAF fragmentado de 200-500 ms. WebRTC, por su parte, no tiene empaquetador en este sentido: cada fotograma comprimido se trocea en paquetes RTP y se empuja a la red en cuanto el codificador termina.

El búfer del reproductor es el otro gran consumidor. HLS clásico recomienda mantener el cabezal de reproducción a una distancia de tres segmentos detrás del live edge (el último segmento disponible en la playlist) — con segmentos de 6 segundos, eso sitúa la reproducción 18 segundos por detrás del momento más reciente. Apple lo controla con el atributo HOLD-BACK en EXT-X-SERVER-CONTROL; el equivalente en DASH es MPD@suggestedPresentationDelay.

El búfer del reproductor de WebRTC, en cambio, es un búfer de fluctuación (jitter buffer) que NetEQ para audio y el jitter buffer de video mantienen típicamente entre 50 y 200 ms — dos órdenes de magnitud más pequeño.

Ese desglose explica por qué dos protocolos sobre la misma red pueden dar resultados que difieren en un orden de magnitud.

HLS vs WebRTC: por qué la brecha es de 60×

Un ejemplo aclara cuánto pesan esas dos etapas. Considérese una transmisión deportiva a 1080p que viaja de un estadio en Londres a un espectador en Berlín, sumando los siete contribuyentes para dos pilas distintas.

HLS clásico, segmentos de 6 s:

Cámara + ISP                      = 80 ms
Codificador H.264, 10 frames LA   = 333 ms
Empaquetador, segmento de 6 s     = 6.000 ms   ← espera por un segmento completo
Contribución (RTMP/SRT)           = 100 ms
CDN, borde cálido                 = 40 ms
Búfer del reproductor, 3 × 6 s    = 18.000 ms  ← seguridad de tres segmentos
Decodificador + pantalla 60 Hz    = 50 ms
─────────────────────────────────────────────
Total glass-to-glass              ≈ 24,6 s

WebRTC, jitter buffer por defecto:

Cámara + ISP                      = 80 ms
Codificador H.264, sin lookahead  = 100 ms
Sin empaquetador (paquetes RTP)   = 0 ms
Contribución (RTP/SRTP)           = 80 ms
Relay de medios / SFU             = 30 ms
Jitter buffer                     = 100 ms
Decodificador + pantalla 60 Hz    = 30 ms
─────────────────────────────────────────────
Total glass-to-glass              ≈ 0,42 s

La brecha de 60× casi no tiene nada que ver con la red y casi todo con dos decisiones: cómo el publicador empaqueta el flujo y cuánto búfer retiene el reproductor. Las contribuciones de codificador, contribución, CDN y decodificador están dentro de unos pocos cientos de milisegundos en ambas pilas. El empaquetador y el búfer del reproductor son elecciones de protocolo, no límites tecnológicos — y son los que escogen el régimen de latencia del producto.

Antes de elegir protocolo, hay que poder medir el número real, no el que cotiza el proveedor.

Cómo se mide el número real

Existen dos métodos pragmáticos para medir la latencia glass-to-glass en producción.

Timecode renderizado en el píxel. El publicador imprime un código de tiempo SMPTE (o un contador monotónico) en la esquina superior izquierda de cada fotograma. En el receptor, se aplica OCR al código visible en la pantalla y se compara con la hora del reloj de pared actual. Es repetible, automatizable mediante scripts y preciso al nivel de un fotograma. Para la mayoría de los equipos es la respuesta correcta: lo bastante simple como para integrarse en un pipeline de pruebas y lo bastante preciso como para depurar configuraciones reales.

Inyección de Producer Reference Time (prft). Para pilas HLS y DASH, el codificador puede inyectar una caja prft (Producer Reference Time, definida en ISO/IEC 14496-12) en cada fragmento CMAF, y el reproductor la compara con el reloj de pared al renderizar. La directriz de Modos de Baja Latencia de DASH-IF recomienda este enfoque para telemetría en producción. Es continuo, automático y constituye la base de los números de latencia por sesión que reportan herramientas como Mux Data y Conviva.

Tres métricas se confunden a menudo con la latencia y se miden distinto: el tiempo de inicio (cuánto tarda en aparecer el primer fotograma tras pulsar reproducir), la tasa de rebuferización (la fracción de tiempo de visualización pasada esperando un spinner) y el jitter (la variación temporal entre la llegada de paquetes sucesivos).

Las tres se mueven en curvas independientes: un sistema puede tener latencia bajísima y rebuferización inaceptable, o al revés. Leer una sin las otras dos es leer la mitad de la historia.

Con esos métodos ya se puede contrastar el número real contra los suelos teóricos que cotiza cada familia de protocolos.

Latencia de protocolos: tabla y trampas comunes al leer un número

La siguiente tabla resume el suelo de latencia que cada familia de protocolos alcanza en producción real en 2026, junto con las condiciones que exige.

Trampa habitual al leer una cifra. Los proveedores tienden a cotizar el suelo de latencia que su pila puede alcanzar, no la latencia que su cliente típico despliega en producción. El Low Latency mode de Twitch, por ejemplo, ronda los 2-5 segundos del lado del receptor, pero el tramo RTMP del transmisor que contribuye al sistema añade otros 2-5 segundos por encima — el verdadero glass-to-glass para alguien que está mirando el chat se acerca a 7 segundos. Cualquier número de marketing debería leerse con la misma pregunta: qué tramos del recorrido incluye, y cuáles deja fuera.

Referencias

• IETF RFC 8216 — HTTP Live Streaming (R. Pantos, W. May, 2017). Define el formato de lista de reproducción, EXT-X-TARGETDURATION y la regla original de retención de tres segmentos.
• IETF draft-pantos-hls-rfc8216bis — HTTP Live Streaming 2nd Edition (Internet-Draft en evolución). Define EXT-X-SERVER-CONTROL, HOLD-BACK, PART-HOLD-BACK y las extensiones de baja latencia.
• Apple HLS Authoring Specification (revisión 2025). Régimen de segmentos parciales LL-HLS y el límite PART-HOLD-BACK.
• ISO/IEC 23009-1:2022 — DASH Parte 1: Descripción de la presentación de medios y formatos de segmento. Define MPD@suggestedPresentationDelay.
• DASH-IF Low Latency Modes for DASH (CTA-5004). Mecanismo de emisión de CMAF fragmentado y caja prft para telemetría.
• W3C WebRTC 1.0: Real-Time Communication Between Browsers (Recommendation, enero 2021) + WebRTC Extensions (Working Draft). Modelo de jitter buffer del lado del receptor; RTCRtpReceiver.jitterBufferTarget se define en Extensions.