Home Artículos técnicos Codificación de vídeo en la nube para transmitir eventos en vivo a gran escala
Applications

Codificación de vídeo en la nube para transmitir eventos en vivo a gran escala

About The Author

Outline

A medida que los dólares publicitarios y los espectadores continúan alejándose de la televisión tradicional, los propietarios de contenido y las emisoras están buscando la transmisión en vivo de eventos respaldados por anuncios para atraer a nuevas audiencias y aumentar los ingresos a través de la transmisión Over-the-top (OTT). OTT ofrece nuevas oportunidades de distribución, que permiten a un editor transmitir y monetizar contenido licenciado que anteriormente no tenía cabida en la televisión. Pero antes de que un editor pueda comenzar a transmitir eventos en vivo, se deben considerar los obstáculos técnicos en el primer paso del flujo de trabajo de transmisión de video:

  • La calidad de la conexión y la disponibilidad de ancho de banda entre el lugar y el punto de ingesta pueden ser un eslabón débil en el flujo de trabajo. La redundancia y la fiabilidad deben incorporarse.
  • Las fuentes en vivo deben codificarse en varios formatos y protocolos de velocidad de bits adaptativos, como Apple HLS y MPEG-DASH, al tiempo que se minimiza la latencia.
  • Las soluciones de carga y codificación deben estar preparadas para el futuro, ser confiables y escalables para manejar la aparición de 4K y otros formatos de alta calidad.
  • El flujo de trabajo de video debe ser capaz de admitir la inserción de anuncios en el lado del servidor para la mejor experiencia de espectador y las estrategias de monetización más oportunas.

En este blog de tecnología, analizamos cómo hemos construido nuestra plataforma para permitir que un editor optimice el primer paso en el flujo de trabajo de transmisión de video, analizamos algunos de los desafíos involucrados y explicamos cómo codificamos la transmisión en vivo para permitir la transmisión en vivo de alto rendimiento, baja latencia y respaldada por anuncios.

‍Background: El Slicer

Antes de sumergirnos en las consideraciones técnicas de la codificación, necesitamos explicar nuestra tecnología llamada “Slicer”. Un potente cliente de software, The Slicer, lleva la transmisión en vivo de su lugar a nuestra plataforma de video en la nube. Simplifica una tarea extraordinariamente compleja sin sacrificar la flexibilidad y la funcionalidad. El Slicer es una razón clave por la que las emisoras con amplios recursos técnicos y las que no tienen ninguno pueden aprovechar nuestra plataforma para crear experiencias OTT poderosamente diferenciadas.

El Slicer prepara su contenido para la codificación, calcula la configuración de codificación ideal y administra los marcadores de inserción de anuncios. Puede ejecutar el Slicer en su hardware seguro o elegir el ahorro de costos y la escalabilidad de ubicaciones independientes de la nube que admiten varios formatos, incluidos SDI, video IP, RTP / FEC y RTMP.

The Slicer divide tu contenido en pequeños fragmentos y los cifra antes de enviarlos a nuestra pila de codificación en la nube certificada por ISO, dándote la tranquilidad que conlleva saber que tu contenido siempre está seguro. Ofrece una gama flexible de flujos de trabajo, desde configuraciones simples con un solo clic hasta scripts más avanzados en el lenguaje de programación de elección, hasta la escritura de funciones en la nube que activan flujos de trabajo para notificaciones, procesamiento de trabajos e integraciones de aprendizaje automático.

Nuestro “Live Slicer”, una versión del Slicer, está optimizado para la transmisión de eventos en vivo. Los feeds basados en HD-SDI o IP se ingieren rápidamente y se dividen en segmentos cifrados de 2 o 4 segundos a la velocidad de bits más alta deseada, lo que reduce los requisitos de ancho de banda a 3-5 Mbps para 1080p y alrededor de 15 Mbps para 4K. Nuestro proceso retiene automáticamente metadatos y mensajes dentro y fuera de banda para activar pausas de programas y anuncios o reemplazar contenido. Nuestra arquitectura de plugins le permite crear scripts personalizados que manejan sus requisitos únicos de eventos de señalización. Live Slicer también puede escuchar mensajes de SCTE 35 / 104 o recibir llamadas a la API para insertar saltos de anuncios, inicios de contenido o activadores de apagón.

Un flujo OTT se genera a partir de una alimentación lineal en vivo con una inversión inicial mínima y bajos requisitos de ancho de banda.

Minimizando el ancho de banda

Ahora que entiende el licer S, puede que se pregunte por qué vamos a desarrollar un componente de software front-end para mover las transmisiones en vivo de los eventos a la nube. ¿Por qué los editores no pueden enviar un flujo RTMP (Real-Time Messaging Protocol), por ejemplo? (Puedes hacer esto si quieres, pero la mayoría de nuestros clientes aprovechan el Slicer.) La respuesta tiene tanto que ver con las expectativas de los consumidores para las transmisiones en vivo de alta calidad como con trabajar en torno a los desafíos del ancho de banda en los lugares en vivo. Se trata de encontrar el equilibrio adecuado entre muchos factores que compiten. Por un lado, es necesario conservar la mayor cantidad posible de la alimentación original, con un ojo hacia formatos de mayor calidad y 4K. Por otro lado, debe optimizar el flujo para que pueda entregarse de manera eficiente sin quedar atascado por gastos adicionales, como la publicidad personalizada. Encontrar el equilibrio adecuado es fundamental para este paso del flujo de trabajo de vídeo.

Aquí es donde el Slicer es esencial. Como se señaló anteriormente, reduce significativamente el ancho de banda requerido para un feed dado al crear el perfil de tasa de bits más alto en el sitio y solo enviar ese perfil a la nube. En nuestra observación, basada en la transmisión de millones de horas de imágenes en vivo a miles de millones de espectadores en todo el mundo, el enfoque alternativo de enviar una transmisión RTMP significativamente más grande a la nube no resulta en un aumento apreciable en la calidad de la experiencia de visualización. Pero aumenta significativamente el ancho de banda, lo que aumenta los costos.

Los costos de backhaul pueden sumarse rápidamente. Si sus requisitos son tales que necesita un enlace ascendente satelital, un camión de banda Ka, por ejemplo, rentas por alrededor de $ 2.000 por día, y el ancho de banda cuesta alrededor de $ 400 por hora. Dadas las condiciones inconsistentes y limitadas por el ancho de banda en algunos lugares, como hoteles o centros de conferencias, o incluso lugares deportivos en todo el mundo, la conclusión es que siempre es una buena idea reducir los requisitos de ancho de banda de carga en la mayor medida posible, al tiempo que garantiza que brindes una experiencia similar a la de transmisión a tus espectadores.

Obstáculos de codificación

Una vez que la fuente de video en vivo sale del lugar, el siguiente paso en el flujo de trabajo es la codificación. Aquí, un codificador de vídeo crea múltiples versiones o variantes del audio y el vídeo a diferentes velocidades de bits, resoluciones y niveles de calidad. Luego segmenta las variantes en pequeños archivos o segmentos de medios. Se deben realizar varios pasos adicionales, como crear una lista de reproducción de medios para cada variante que contenga una lista de URL que apunten a los segmentos de medios de la variante. La lista de reproducción maestra resultante es la elección del jugador de la variante más adecuada para el dispositivo y el ancho de banda actualmente medido o disponible.

Dos protocolos principales de transmisión de video se suman a la complejidad, y otros pueden necesitar ser compatibles para cubrir la gran cantidad de dispositivos de reproducción potenciales. HLS es un protocolo de comunicaciones de transmisión de medios basado en HTTP implementado por Apple. Ofrece soporte para todos los dispositivos Apple y la mayoría de los navegadores y dispositivos de Google, Android, Linux y Microsoft. La mayoría, pero no todos. También necesita MPEG-DASH, un protocolo de transmisión de medios basado en HTTP competitivo. Es posible que también necesite agregar soporte para Microsoft Smooth Streaming para consolas de juegos.

DRM también puede complicar la codificación al requerir su propio conjunto de múltiples formatos para soportar los requisitos de gran audiencia. Por ejemplo, los jugadores mayores que no admiten DRM necesitan HLS y AES-128. Los dispositivos iOS más antiguos requieren HLS y FairPlay. Los dispositivos iOS más nuevos admiten HLS y FairPlay, y CMAF CBC. Windows y Android antiguos solo admiten CMAF CTR. Los nuevos Android, Windows e iOS deberían admitir todos los formatos CMAF. El contenido debe estar empaquetado en múltiples formatos para permitir la reproducción en todos los dispositivos.

Si esto suena como un montón de trabajo de codificación, tienes razón. A medida que aumentan las resoluciones y los códecs se vuelven más complejos, se hace más difícil codificar una escalera de codificación ABR completa en una sola máquina, ya sea en la nube o en las instalaciones. Si su hardware de codificación no está a la altura de la tarea de mantenerse al día con la transmisión en vivo, es posible que deba reducir el número de peldaños en la escalera de codificación, lo que en última instancia podría afectar la experiencia de su audiencia.

Para seguir el ritmo de los requisitos de codificación más complejos, el modelo tradicional significa que los productores deben invertir continuamente en nuevo hardware para mantener la velocidad y la calidad. En última instancia, para un servicio de transmisión como Edgio, anteriormente Verizon Digital Media Services, el modelo de transmisión a codificador 1:1 no ofrece la confiabilidad, flexibilidad y escalabilidad que necesitamos para satisfacer las expectativas de nuestros clientes.

En cambio, hemos desarrollado un sofisticado sistema de brokering que permite el uso de tantos codificadores como necesitemos, todos ejecutándose en una infraestructura basada en la nube. El sistema de intermediación recibe los fragmentos de contenido de las instancias de Slicer y los mueve al codificador más óptimo. Esta acción evita que los procesos de codificación sobrecarguen una máquina específica y mantiene los fragmentos en movimiento a través del sistema para el almacenamiento y hacia los espectadores.

El proceso de bróker amplía nuestra infraestructura de codificadores en la nube sin problemas y, lo que es más importante, de forma automática.

En nuestra implementación, una instancia de bróker actúa como un gerente hablando entre el Slicer y los codificadores. El broker se asegura de que cualquier nuevo Slicer tenga sus datos enrutados al codificador adecuado y verifica que el codificador pueda manejar la carga de trabajo. Además, tenemos una infraestructura de escalado muy capaz. Si de repente recibimos un millón de horas de contenido VOD que necesita ser codificado, podemos aumentar rápidamente las instancias del servidor y comenzar a procesar contenido. También podemos reducir la escala con la misma rapidez para conservar los recursos. Este proceso de bróker gestiona toda nuestra infraestructura en la nube de forma fluida y, lo que es más importante, de forma automática.

Codificadores apátridas

Por supuesto, el sistema de corretaje sería de valor limitado si todo lo que podría hacer es apuntar un Slicer a un solo codificador que puede o no ser capaz de mantenerse al día con las demandas de la transmisión en vivo, un problema serio con 4K. La solución que desarrollamos implica el uso de codificadores sin estado. En lugar de dedicar una sola máquina a todo el flujo, cada codificador solo recibe un solo segmento de video de 2 o 4 segundos a la vez. Cada segmento incluye suficiente información para preparar el codificador para que pueda codificar ese segmento y descartar cualquier cosa innecesaria para los primings, como la información de entrada y salida. En este punto, el segmento completo se completa y está listo para funcionar, liberando el codificador para que pueda comenzar a codificar otra pieza de contenido de otro canal o cualquier otra cosa.

Este modelo también tiene una cantidad considerable de redundancia incorporada en el sistema. Por ejemplo, si un codificador se bloquea mientras procesa un segmento, el mismo segmento se inicia en otra máquina y se realiza a tiempo antes de que se noten problemas dentro del flujo.

Este enfoque también permite el uso de hardware más rentable. Por ejemplo, si sabemos que una máquina más lenta puede tardar 8 segundos en procesar un archivo de 4 segundos desde un Slicer, podemos distribuir la carga de trabajo entre varios codificadores como se muestra a continuación: El servidor A obtiene el segmento 1, el servidor B obtiene el segmento 2, etc. Luego, los trozos se entregaron sin problemas porque todos se completaron en un momento predecible. Como se muestra en el gráfico de abajo, este ejemplo resultaría en una latencia detrás de la vida de 16 a 20 segundos.

El uso de múltiples codificadores en la nube minimiza la latencia y permite el uso de servidores que de otro modo no serían capaces de mantenerse al día con un feed en vivo.

En última instancia, el volumen de servidores en la nube, incluso si los servidores individuales son más lentos, significa que los procesos de codificación siempre pueden mantenerse al día con las demandas reales. Si desea configurar una infraestructura de codificación utilizando un modelo tradicional, deberá invertir en costosas máquinas de alto rendimiento o hardware especializado, cada una capaz de procesar todo el video entrante sin asistencia en tiempo real. Al aprovechar la escalabilidad de la nube, reducimos significativamente los costos de codificación.

Otra ventaja de la codificación en la nube sin estado es que podemos mover fácilmente las cargas de trabajo a proveedores de nube alternativos, ya que no tenemos requisitos de servidor especializados. Con una red de más de 250 Tbps de capacidad, un enfoque multi-nube ofrece ventajas inherentes.

Transmisión en vivo rentable

Para los productores de contenido en vivo, las consideraciones técnicas para preparar el video en vivo para la transmisión en la nube pueden presentar obstáculos formidables. Se enfrentará a varios problemas que van desde limitaciones de ancho de banda del lugar hasta preguntas complejas en torno a codificadores y protocolos de transmisión. Aunque no elimina la necesidad de cierta conectividad en el lugar, un flujo de trabajo simplificado con requisitos de ancho de banda reducidos en el front-end puede reducir drásticamente los gastos iniciales y continuos, al tiempo que ofrece flujos de alta calidad y baja latencia que sus espectadores esperan.