Los deportes en vivo son emocionantes de ver. Especialmente durante los momentos cruciales, como cuando un tiro 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 alrededor de 30 segundos 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 RAW 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 transcodificando y empaquetando el contenido para varios dispositivos y anchos de banda. Por último, a medida que la transmisión se está reproduciendo, la publicidad puede insertarse dinámicamente en la transmisión 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 descodifican, descomprime y renderiza el segmento de vídeo final. Eso es un montón de pasos entre el objetivo de ganar el 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 transmisiones retrasadas ponen a los participantes remotos en desventaja para los que están en el lugar. Los tweets en vivo de los televidentes y presentadores de noticias en el lugar pueden estropear momentos emocionantes para los fans que lo ven en la televisión y la transmisión 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 que se queda atrás en vivo se esté convirtiendo en un requisito importante para mantenerse competitivo y ofrecer una gran experiencia visual.
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 con la entrega de transmisiones en vivo. En esta publicación, analizamos lo que implica 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 de retraso en vivo, los proveedores de servicios de streaming están empezando a adoptar el uso de duraciones más cortas de segmentos HLS o DASH. Esto puede reducir significativamente la latencia, pero tiene compensaciones como gastos generales adicionales y un mayor riesgo de rebúfer. Si estas compensaciones valen la pena depende completamente 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 principal, mientras que en otras, los niveles de latencia actuales 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 del streaming de vídeo ha utilizado durante mucho tiempo tecnologías de tasa de bits adaptativa (ABR) que rompen una transmisión en muchos segmentos o fragmentos de vídeo individuales. Cada segmento tiene la misma duración o tamaño, pero está codificado a diferentes niveles de calidad de vídeo o velocidades de bits para que la transmisión pueda adaptarse al ancho de banda disponible del espectador a medida que se solicitan nuevos segmentos. Los dos protocolos ABR principales, 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 predeterminado de segmentos antes de que pueda comenzar a reproducir la transmisión en vivo. Esto se hace para que el reproductor de vídeo del cliente pueda almacenar suficiente vídeo para garantizar una reproducción de vídeo fluida sin rebúfer 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 vídeo incrustados en dispositivos iOS y navegadores web almacenan tres segmentos de vídeo antes de iniciar la reproducción. Si un segmento tiene cuatro segundos de duración y el jugador tiene que almacenar tres segmentos antes de que pueda comenzar a reproducirse, entonces el cliente ya está 12 segundos atrá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 reproductores y dispositivos DASH aún no han implementado esta funcionalidad.
Reduciendo 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 siguiente, al reducir el tamaño del segmento de cuatro segundos a dos segundos, el tiempo detrás de 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 rebuffers
Cuando se utilizan segmentos de tamaño más pequeño, 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:
Primero, al reducir el tamaño del segmento, el reproductor, que almacena un número fijo de segmentos, ahora está almacenando menos vídeo. Y dado que los segmentos más cortos significan más archivos, el flujo de trabajo de vídeo y, lo que es más importante, la red de distribución de contenido deben procesar y entregar el doble de solicitudes de archivos de los reproductores durante una duración de transmisión determinada. Debido a que hay menos búfer de video en el reproductor durante la congestión de la red, es más probable que la congestión pueda causar un rebúfer. 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 reciente artículo de tecnología, Optimizando el CDN para Live Streaming, es común en los deportes en vivo ver aumentos en los espectadores cuando comienzan eventos populares o cuando un partido cerrado se acerca a los minutos finales. A medida que aumenta el número de solicitudes de archivo, la CDN necesita acomodar más solicitudes de archivo en la misma cantidad de tiempo. Esta tarea se complementa con varios tipos de dispositivos y velocidades de conexión especificadas por parámetros de tasa de bits adaptativos.
Para ilustrar el aumento en el volumen de archivo, la Figura 2 muestra un segmento de video de 16 segundos entregado en segmentos de diferentes longitudes. 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 necesitan ser procesados a través de la CDN.
Mejore el rendimiento de entrega de segmentos con Hot Filing
Hemos creado una función llamada Hot Filing para hacer frente al 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 POP (punto de presencia), por lo que puede ser entregado a los espectadores tan rápidamente como la demanda aumenta rápidamente.
Al distribuir la carga a muchos servidores, Hot Filing evita que cualquier servidor se sienta abrumado 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 será lento para responder a las solicitudes de archivo, lo que podría conducir a la rebúfer 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 añadir latencia.
La Figura 3 muestra cómo Hot Filing (Fig. 3.b) mejora el rendimiento al evitar la sobrecarga del servidor. Sin Hot Filing (Fig. 3.A), todo el tráfico de un segmento va al servidor 1 (S1). A medida que aumenta la demanda de audiencia, el tráfico adicional fluye a 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, Hot Filing (figura 3.b) maneja esta carga adicional replicando archivos en dos servidores (S1 más S2) y redirigiendo las solicitudes de archivos al servidor recién disponible.
Identificación de archivos calientes más rápida
Recientemente hemos mejorado Hot Filing al disminuir el tiempo para mover archivos calientes a múltiples servidores en un segundo. Mejoramos el tiempo de reacción cambiando la forma en que los archivos calientes se identifican dentro de un POP. Utilizamos un proceso central para agregar solicitudes de archivos y recuentos 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 solucionar este problema, los servidores ahora escriben su solicitud y cuenta 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 eventos en vivo se muestra en la Figura 3.c, que ofrece una visión de 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 usuarios de 200 de forma rápida y eficiente y utilizar toda la capacidad de los servidores disponibles.
Hot archiving en múltiples puertos
Para eventos extremadamente populares, como los partidos de playoffs de fútbol profesional o los principales partidos internacionales de fútbol, los picos y aumentos en el tráfico pueden ser muy significativos. 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 sustancialmente el rendimiento de cada servidor 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 se maneja mediante hash del protocolo de enrutamiento de matrices de caché (CARP). Para el contenido regular, nuestro enfoque ha sido replicar los archivos a través de múltiples servidores, y usamos hashing de CARP para seleccionar un solo puerto de cada servidor. Hacemos esto para evitar que se envíen solicitudes duplicadas 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 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 servido por servidor y la cantidad de energía de la CPU disponible para procesar estas solicitudes.
Conclusión
A medida que los proveedores de servicios de streaming reducen el tamaño de los segmentos de vídeo para ofrecer una transmisión en vivo de menor latencia, las capacidades de archivo 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 los eventos deportivos populares.
