Suscríbete para recibir notificaciones de nuevas publicaciones:

El video en vivo ahora es más directo: Presentamos la aceleración simultánea de streaming

2019-05-16

4 min de lectura
Esta publicación también está disponible en English, Français, Deutsch, 日本語 y 简体中文.

Hoy nos complace presentar la aceleración simultánea de streaming, una nueva técnica para reducir la latencia de un extremo a otro del video en vivo en la web cuando se usa Stream Delivery.

Examinemos en profundidad la latencia de streaming en vivo, por qué es importante y qué se ha hecho para optimizarla.

¿Hasta qué punto un video “en vivo” es “en vivo”?

El streaming en vivo constituye una parte cada vez mayor de los videos en la web. Ya sea una transmisión de televisión, un programa de juegos en vivo o un aula en línea, los usuarios esperan que el video llegue de manera rápida y sin inconvenientes. Y la promesa de todo lo que es “en vivo” tiene que ver con la idea de que el usuario está mirando los eventos al mismo tiempo en que estos ocurren. Pero, ¿hasta qué punto se puede decir que un video de internet es “en tiempo real”?

La transmisión de un video en vivo en internet sigue siendo difícil y tiene mucha latencia:

  1. El origen de contenido graba el video y lo envía a un servidor de codificación;

  2. El servidor de origen transforma este vídeo en un formato DASH, HLS o CMAF que se puede enviar a millones de dispositivos de manera eficiente;

  3. Una CDN se utiliza, por lo general, para transmitir un video codificado a todo el mundo

  4. Los reproductores del cliente decodifican el video y lo representan en la pantalla

Y todo este proceso tiene una restricción de tiempo, ya que debe llevarse a cabo en pocos segundos, de lo contrario, la experiencia de video se verá afectada. El retraso total entre el momento en que se graba el video y el que se puede ver en el dispositivo de un usuario final se conoce como “latencia de extremo a extremo” (piense en ello como el tiempo que transcurre desde la lente de la cámara hasta la pantalla de su teléfono).

Envío segmentado tradicional

Los formatos de video como DASH, HLS y CMAF dividen el video en archivos pequeños que se llaman “segmentos”. Por lo general, el segmento dura 6 segundos.

Si el reproductor de un cliente debe esperar 6 s para que se codifique un segmento completo, se envíe a través de una CDN y luego se decodifique, ¡la espera puede ser larga! Si usted quiere que el cliente cree un búfer de segmentos para proteger el envío contra interrupciones, lleva aún más tiempo. Un búfer de reproductor común para HLS es de 3 segmentos:

Es posible que los clientes tengan que almacenar en búfer tres fragmentos de 6 segundos, introduciendo al menos 18 s de latencia

Al considerar los retrasos de codificación, resulta fácil ver por qué la latencia de streaming en vivo en internet ha sido, por lo general, de unos 20-30 segundos. Podemos hacerlo mejor.

Latencia reducida con codificación de transferencia fragmentada

Una forma natural de resolver este problema es permitir que los reproductores del cliente comiencen a reproducir los fragmentos mientras se están descargando, o incluso mientras se están creando. Para que esto sea posible, se requiere una cooperación inteligente para codificar y enviar los archivos de una manera determinada que se conoce como “codificación fragmentada”. Esto implica la división de los segmentos en trozos más pequeños que se denominan “fragmentos”. La codificación fragmentada, por lo general, reduce la latencia en vivo a 5 o 10 segundos.

Esto puede resultar algo confuso, ya que la palabra “fragmento” puede significar dos cosas diferentes:

  1. Fragmentos CMAF o HLS, que son pequeños trozos de un segmento (por lo general de 1 s) que están alineados en fotogramas clave

  2. Fragmentos HTTP, que son solo una forma de enviar cualquier tipo de archivo en la web

La codificación fragmentada divide los segmentos en fragmentos más cortos

Los fragmentos HTTP son importantes porque los clientes web tienen una capacidad limitada para procesar flujos de datos. La mayoría de los clientes solo pueden trabajar con datos una vez que han recibido la respuesta HTTP completa, o al menos un fragmento HTTP completo. Mediante la codificación de transferencia fragmentada HTTP, permitimos que los reproductores de video comiencen a analizar y decodificar antes el video.

Los fragmentos del formato común de aplicaciones multimedia (CMAF) son importantes para que los decodificadores puedan reproducir los bits que realmente se encuentran en los fragmentos HTTP. Si el video no se codifica con cuidado, los decodificadores tendrían bits aleatorios de un archivo de vídeo que no se puede reproducir.

Las CDN pueden introducir almacenamiento en búfer adicional

Hoy, el uso de la codificación fragmentada con HLS y CMAF está creciendo en toda la web. Parte de la excelencia de esta técnica se debe a que la codificación fragmentada HTTP es ampliamente compatible con la CDN: ha formado parte de la especificación HTTP durante 20 años.

La compatibilidad con la CDN es fundamental, ya que permite que el video en vivo de baja latencia se escale y llegue a audiencias de miles o millones de espectadores simultáneos, algo que actualmente es muy difícil de lograr con otros protocolos no basados en HTTP.

Lamentablemente, incluso si usted activa la fragmentación para optimizar el envío, su CDN puede estar contrarrestando la tarea con el almacenamiento en búfer de todo el segmento. Para entender el por qué, considere lo que sucede cuando muchas personas solicitan un segmento en vivo al mismo tiempo:

Si el archivo ya está en caché, ¡excelente! Las CDN son excelentes para enviar archivos almacenados en caché a grandes audiencias. Pero, ¿qué sucede cuando el segmento aún no está almacenado en caché? Recuerde, este es el patrón de solicitud típico para el video en vivo.

Por lo general, las CDN pueden “transmitir con error de caché” desde el origen. Eso se parece a lo que se muestra a continuación:

Pero una vez más, ¿qué sucede cuando varias personas solicitan el archivo al mismo tiempo? Las CDN, por lo general, necesitan llevar todo el archivo a la memoria caché antes de brindar servicio a más usuarios de visualizaciones:

Solo un usuario de visualizaciones puede transmitir el video, mientras que el resto de los clientes esperan que el segmento se almacene en el búfer en la CDN

Este comportamiento es comprensible. Los centros de datos de la CDN están formados por muchos servidores. Para evitar la sobrecarga de los orígenes, estos servidores, por lo general, se coordinan entre sí mediante un “bloqueo de caché” (mutex) que permite que solo un servidor solicite un archivo determinado desde el origen en un momento determinado. Esto genera un efecto secundario: mientras un archivo se lleva a la memoria caché, no se puede brindar servicio a ningún usuario que no sea el primero que emitió la solicitud. Lamentablemente, este bloqueo de caché también contrarresta el objetivo de usar codificación fragmentada.

Resumen de lo analizado hasta ahora:

  • La codificación fragmentada divide los segmentos de video en partes más pequeñas

  • Esto puede reducir la latencia de extremo a extremo, ya que permite que los reproductores obtengan y descodifiquen los fragmentos, incluso mientras los segmentos se generan en el servidor de origen

  • Algunas CDN neutralizan las ventajas de la codificación fragmentada mediante el almacenamiento en búfer de archivos completos en CDN antes de que se envíen a los clientes

Solución de Cloudflare: Aceleración simultánea de streaming

Como seguramente ha adivinado, creemos que podemos hacer mejor las cosas. En pocas palabras, ahora podemos enviar archivos sin almacenar en caché a varios clientes de manera simultánea cuando extraemos el archivo una vez desde el servidor de origen.

Aparentemente, esto es un simple cambio, sin embargo, se deben tener en cuenta muchas sutilezas para hacerlo de manera segura. Hemos realizado cambios profundos en nuestra infraestructura de almacenamiento en caché para eliminar el bloqueo de caché y permitir que varios clientes puedan hacer una lectura segura desde un único archivo mientras este se sigue escribiendo.

Y lo mejor es que ¡ahora todo Cloudflare funciona de esta manera! No es necesario adherirse ni hacer un cambio de configuración para obtener el beneficio.

Hemos lanzado esta función hace un par de meses y hasta ahora estamos muy satisfechos con los resultados. Medimos el éxito mediante el “tiempo de espera de bloqueo de caché”, es decir, cuánto tiempo debe esperar una solicitud para otras solicitudes, un componente directo del tiempo hasta el primer byte.  Un cliente de OTT observó que esta métrica cae de 1.5 s en P99 a casi 0, tal como se esperaba:

Esto se traduce directamente en una mejora de 1.5 segundos en la latencia de extremo a extremo. ¡El video en vivo ahora es más directo!

Conclusión

Las nuevas técnicas, como la codificación fragmentada, han revolucionado el envío en vivo, lo que permite a los editores ofrecer el envío de videos en vivo de baja latencia en proporción a la necesidad. La aceleración simultánea de streaming ayuda a desbloquear la potencia de esta técnica en su CDN, lo que podría ahorrar segundos valiosos de latencia de extremo a extremo.

Si le interesa usar Cloudflare para la transmisión de videos en vivo, comuníquese con nuestro equipo de ventas empresariales.

Y si le interesa trabajar en proyectos como este y ayudarnos a mejorar la transmisión de videos en vivo para toda la internet, únase a nuestro equipo de ingeniería.

Protegemos redes corporativas completas, ayudamos a los clientes a desarrollar aplicaciones web de forma eficiente, aceleramos cualquier sitio o aplicación web, prevenimos contra los ataques DDoS, mantenemos a raya a los hackers, y podemos ayudarte en tu recorrido hacia la seguridad Zero Trust.

Visita 1.1.1.1 desde cualquier dispositivo para empezar a usar nuestra aplicación gratuita y beneficiarte de una navegación más rápida y segura.

Para saber más sobre nuestra misión para ayudar a mejorar Internet, empieza aquí. Si estás buscando un nuevo rumbo profesional, consulta nuestras ofertas de empleo.
Speed Week (ES)Cloudflare StreamVideoVelocidad/fiabilidadNoticias de productos

Síguenos en X

Jon Levine|@jplevine
Cloudflare|@cloudflare

Publicaciones relacionadas

09 de octubre de 2024, 13:00

Improving platform resilience at Cloudflare through automation

We realized that we need a way to automatically heal our platform from an operations perspective, and designed and built a workflow orchestration platform to provide these self-healing capabilities across our global network. We explore how this has helped us to reduce the impact on our customers due to operational issues, and the rich variety of similar problems it has empowered us to solve....

08 de octubre de 2024, 13:00

Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One

The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. ...

27 de septiembre de 2024, 13:00

AI Everywhere with the WAF Rule Builder Assistant, Cloudflare Radar AI Insights, and updated AI bot protection

This year for Cloudflare’s birthday, we’ve extended our AI Assistant capabilities to help you build new WAF rules, added new AI bot & crawler traffic insights to Radar, and given customers new AI bot blocking capabilities...

26 de septiembre de 2024, 13:00

Zero-latency SQLite storage in every Durable Object

Traditional cloud storage is inherently slow because it is accessed over a network and must synchronize many clients. But what if we could instead put your application code deep into the storage layer, such that your code runs where the data is stored? Durable Objects with SQLite do just that. ...