Home Artículos técnicos Transmisión en vivo de baja latencia con una CDN más rápida
Applications

Transmisión en vivo de baja latencia con una CDN más rápida

About The Author

Outline

Los deportes en vivo son emocionantes de ver. Especialmente durante momentos cruciales, como cuando un disparo sale de la nada para ganar el juego. Estos momentos también pueden ser emocionantes para el equipo técnico responsable de ofrecer una acción fluida y en tiempo real. Las transmisiones deportivas en vivo deben equilibrar varias consideraciones técnicas y compensaciones, con un promedio de unos 30 segundos por detrás del juego en vivo en el campo. ¿Por qué el retraso?

Si bien las redes de entrega de contenido son esenciales, no pueden reducir la latencia causada por otras partes del flujo de trabajo de vídeo. Por ejemplo, la latencia se agrega desde el momento de la ingesta cuando una imagen se convierte en una señal. La señal cruda debe ser convertida a un formato comprimido y transmitida al centro de procesamiento de video, generalmente fuera del sitio y a menudo en la nube, lo que puede verse afectado por el ancho de banda y la infraestructura disponibles. A continuación viene la transcodificación y el empaquetado del contenido para varios dispositivos y anchos de banda. Por último, a medida que se reproduce el flujo, la publicidad puede insertarse dinámicamente en el flujo justo antes de que se mueva a través de la última milla de Internet hasta el dispositivo del espectador. Aquí, los búferes del reproductor decodifican, descomprimen y renderizan el segmento final del video. Eso es un montón de pasos entre el objetivo ganador del juego del equipo y la red de entrega de contenido. Y pueden sumar, especialmente cuando tiene que suceder para millones de espectadores a la vez. Latencia en las transmisiones en vivo del Super Bowl, por ejemplo, promedio de 28 a 47 segundos.

Reducir la latencia se ha convertido en un foco para los proveedores de servicios de streaming. Para los deportes vinculados a las apuestas de juego de fracciones de segundo, como las carreras de caballos, las corrientes retrasadas ponen a los participantes remotos en una desventaja para los que están en el lugar. Los tweets en vivo de espectadores y locutores de noticias en el lugar pueden estropear momentos emocionantes para los fanáticos que lo ven en la televisión y en vivo. Y con más y más espectadores que usan una segunda pantalla mientras ven deportes en vivo, no es de extrañar que reducir el tiempo detrás del tiempo en vivo se esté convirtiendo en un requisito importante para mantenerse competitivo y ofrecer una gran experiencia de visualización.

Reducir la latencia es un área de enfoque para nosotros en Edgecast, ahora Edgio. Este esfuerzo implica investigar e implementar mejoras incrementales en cada paso de procesamiento y los otros factores involucrados en la entrega de transmisiones en vivo. En esta publicación, analizamos lo que está involucrado con un aspecto específico de la reducción de latencia: Cómo nuestra red de entrega de contenido maneja el aumento del volumen de solicitudes que resulta de una estrategia de baja latencia cada vez más popular: La reducción del tamaño del segmento.

En la búsqueda de reducir el tiempo detrás del tiempo en vivo, los proveedores de servicios de transmisión están empezando a adoptar el uso de HLS más cortos o la duración del segmento de DASH. Esto puede reducir significativamente la latencia, pero tiene compensaciones tales como gastos generales adicionales y un mayor riesgo de reamortiguación. Si estas compensaciones valen la pena depende enteramente de la prioridad dada a la latencia en comparación con otras consideraciones de QoE. En algunas situaciones, como se señaló anteriormente, la baja latencia es una prioridad, mientras que en otras, los niveles actuales de latencia pueden ser aceptables para ofrecer publicidad personalizada, programación 4K o para permitir la edición de contenido en vivo.

El papel del tamaño del segmento en la latencia

La industria de la transmisión de vídeo ha utilizado durante mucho tiempo tecnologías de velocidad de bits adaptativa (ABR) que dividen una transmisión en muchos segmentos de vídeo individuales o fragmentos. Cada segmento tiene la misma duración o tamaño, pero está codificado a diferentes niveles de calidad de video o velocidades de bits para que la secuencia pueda adaptarse al ancho de banda disponible del espectador a medida que se solicitan nuevos segmentos. Los dos protocolos principales de ABR, HLS y MPEG-DASH de Apple, proporcionan controles para ajustar el tamaño del segmento.

El tamaño del segmento juega un papel importante en la latencia porque el jugador tiene que descargar un número preestablecido de segmentos antes de que pueda comenzar a reproducir la transmisión en vivo. Esto se hace para que el reproductor de vídeo cliente pueda almacenar suficiente cantidad de vídeo para garantizar una reproducción de vídeo sin rebuffering cuando hay congestión en la red. Sin embargo, esto también pone la corriente detrás en vivo desde el principio. En general, los reproductores de video incrustados en dispositivos iOS y navegadores web almacenan tres segmentos de video antes de comenzar la reproducción. Si un segmento tiene cuatro segundos de duración y el jugador tiene que búfer tres segmentos antes de que pueda comenzar a jugar, entonces el cliente ya está 12 segundos detrás en vivo. El protocolo DASH proporciona cierta flexibilidad al permitir que los archivos MANIFEST especifiquen cuánto de un archivo debe almacenarse en búfer. Aún así, muchos jugadores y dispositivos DASH aún no han implementado esta funcionalidad.

Reducir el tiempo detrás de vivir

Dado que el almacenamiento en búfer de tres segmentos es el estándar de facto, la técnica más popular para reducir el tiempo detrás de la vida es reducir el tamaño o la duración de cada segmento. En el ejemplo a continuación, al reducir el tamaño del segmento de cuatro segundos a dos segundos, el tiempo detrás del live se reduce a solo seis segundos, la mitad de lo que sería con los segmentos de cuatro segundos.

Los segmentos más pequeños pueden causar amortiguadores

Cuando se utilizan segmentos más pequeños, el flujo de trabajo de vídeo tiene que ser más receptivo para ofrecer una experiencia de transmisión de vídeo en vivo sin búfer. Esto se debe a dos factores:

En primer lugar, al reducir el tamaño del segmento, el reproductor, que almacena un número fijo de segmentos, ahora almacena menos video. Y dado que los tamaños de segmento más cortos significan más archivos, su flujo de trabajo de video y, lo más importante, la red de entrega de contenido debe procesar y entregar el doble de solicitudes de archivos de reproductores durante una duración de flujo dada. Debido a que hay menos almacenamiento en búfer de vídeo en el reproductor durante la congestión de la red, es más probable que la congestión pueda causar un rebuffer. El jugador es ahora más sensible a la congestión, incluso durante eventos de congestión más pequeños.

En segundo lugar, como explicamos en un artículo técnico reciente, Optimización de la CDN para transmisión en vivo, es común en los deportes en vivo ver aumentos en los espectadores cuando comienzan los eventos populares o cuando un juego cercano se acerca a los minutos finales. A medida que aumenta el número de solicitudes de archivos, la CDN necesita acomodar más solicitudes de archivos en la misma cantidad de tiempo. Esta tarea se complementa con varios tipos de dispositivos y velocidades de conexión especificadas por los parámetros de tasa de bits adaptativos.

Para ilustrar el aumento en el volumen de archivos, la Figura 2 muestra un segmento de video de 16 segundos entregado en diferentes segmentos de longitud. Con segmentos de cuatro segundos, solo se necesitan cuatro archivos para entregar el segmento de 16 segundos. Pero cuando pasamos a segmentos de dos segundos, necesitamos ocho archivos separados, el doble de archivos que deben procesarse a través de la CDN.

Mejore el rendimiento de entrega del segmento con Hot Filing

Hemos creado una función llamada Hot Filing para lidiar con el fenómeno llamado “flash crowd” cuando muchos espectadores en vivo se unen a una transmisión al mismo tiempo. Esta característica se refiere a replicar rápidamente un segmento popular o “archivo caliente” a servidores adicionales dentro de un punto de presencia, por lo que se puede entregar a los espectadores tan rápido como la demanda aumenta rápidamente.

Al extender la carga a muchos servidores, Hot Filing evita que cualquier servidor se agote a medida que las solicitudes de archivos aumentan repentinamente. Cuando un servidor se sobrecarga, similar a un ataque de denegación de servicio, el servidor tardará en responder a las solicitudes de archivos, lo que potencialmente llevará a la rebufferación en el reproductor cliente. Al identificar y replicar rápidamente los archivos calientes, el riesgo de sobrecargar un solo servidor es mucho menor. Los cambios repentinos en la demanda ahora se pueden satisfacer sin agregar latencia.

La Figura 3 muestra cómo el archivo en caliente (Fig. 3.b) mejora el rendimiento al evitar la sobrecarga del servidor. Sin la presentación en caliente (figura 3.a), todo el tráfico de un segmento va al servidor 1 (S1). A medida que aumenta la demanda de la audiencia, el tráfico adicional fluye hacia S1, lo que lo empuja por encima de su capacidad de 100 usuarios. La situación continúa empeorando ya que S1 atiende a 200 espectadores en el pico. Por el contrario, el archivo en caliente (figura 3.b) maneja esta carga adicional replicando archivos en dos servidores (S1 más S2) y reenrutando las solicitudes de archivos al servidor recién disponible.

Identificación de archivos calientes más rápida

Recientemente mejoramos el Hot Filing al reducir el tiempo para mover archivos calientes a varios servidores en un segundo. Mejoramos el tiempo de reacción cambiando cómo se identifican los archivos calientes dentro de un pop. Utilizamos un proceso central para agregar solicitudes de archivos y conteos de bytes para el análisis. Anteriormente, los datos se extraían del proceso del servidor web en cada servidor. Si bien esto funcionó bien, descubrimos que un servidor web lento podría ralentizar la agregación de datos de archivos calientes. Para resolver este problema, los servidores ahora escriben sus solicitudes y cuentas de bytes en el disco cada segundo. Como resultado, cuando el proceso central extrae datos, no tiene que esperar en los procesos del servidor web, ya que los datos ya están escritos en un disco de estado sólido. Este cambio por sí solo es suficiente para acomodar la carga para la mayoría de los eventos en vivo.

La importancia crítica de un tiempo de reacción rápido para los eventos en vivo se muestra en la Figura 3.c, que ofrece información sobre cómo funciona el proceso de presentación en caliente para reclutar recursos adicionales. En el ejemplo que se muestra en la Figura 3.c, como el servidor S1 excede su capacidad de 100 usuarios, los archivos se mueven rápidamente a S2 a medida que alcanza su capacidad. Esto permite al sistema acomodar a todos los 200 usuarios de forma rápida y eficiente y utilizar toda la capacidad de los servidores disponibles.

Hot Filing en múltiples puertos

Para eventos extremadamente populares, como los partidos de playoffs de fútbol profesional o los principales partidos de fútbol internacional, los picos y las subidas en el tráfico pueden ser muy importantes. Satisfacer este nivel de demanda también requiere cambiar la forma en que se replican los segmentos de archivos para aumentar la capacidad del servidor. Anteriormente, la red de entrega de contenido se limitaba a replicar segmentos a un puerto por servidor. Pero ahora, podemos replicar archivos en varios puertos en cada servidor. Esto aumenta el rendimiento de cada servidor sustancialmente para que cada pop pueda manejar más solicitudes y, por lo tanto, eventos en vivo mucho más grandes que antes.

En nuestro sistema, el balanceo de carga es manejado por el hashing de Protocolo de enrutamiento de matriz de caché (CARP). Para el contenido regular, nuestro enfoque ha sido replicar los archivos en varios servidores, y usamos el hash CARP para seleccionar un solo puerto de cada servidor. Hacemos esto para evitar que las solicitudes duplicadas se envíen al servidor de origen y para limitar la comunicación entre procesos.

Cuando un archivo se calienta lo suficiente, CARP comienza a seleccionar varios puertos por servidor para admitir aún más solicitudes. Este enfoque funciona bien para los archivos calientes, ya que son una pequeña fracción de los archivos únicos servidos por un servidor. El número de puertos abiertos depende de la demanda de un archivo hot. Este enfoque aumenta el volumen de datos servidos por servidor y la cantidad de potencia de la CPU disponible para procesar estas solicitudes.

Conclusión

A medida que los proveedores de servicios de transmisión reducen el tamaño de los segmentos de vídeo para ofrecer una transmisión en vivo de menor latencia, las capacidades de presentación en caliente de la plataforma de Edgio ayudan a la red de distribución de contenido a gestionar el aumento de las solicitudes de archivos de vídeo, especialmente a medida que aumenta el tamaño de la audiencia para eventos deportivos populares.