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 de eventos en vivo respaldada 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 con licencia 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 del 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 transmisiones en vivo deben codificarse en varios formatos y protocolos de velocidad de bits adaptables, como Apple HLS y MPEG-DASH, mientras se minimiza la latencia.
- Las soluciones de subida 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 vídeo debe ser capaz de admitir la inserción de anuncios en el servidor para obtener la mejor experiencia del 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 a un editor optimizar el primer paso en el flujo de trabajo de streaming 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 soporte de anuncios.
Background: El cortador
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, pone en rampas la transmisión en vivo de su lugar a nuestra plataforma de video en la nube. Simplifica una tarea extraordinariamente compleja sin sacrificar flexibilidad y 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 el 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, vídeo IP, RTP/FEC y RTMP.
El 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, lo que te brinda la tranquilidad de 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 elegido hasta funciones de escritura 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 HD-SDI o basados en IP se ingieren rápidamente y se agruparon en segmentos cifrados de 2 o 4 segundos a la tasa de bits más alta deseada, reduciendo 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 saltos de programa y anuncios o reemplazar el 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 SCTE 35 / 104 o recibir llamadas a la API para insertar saltos de anuncio, inicio de contenido o desencadenadores 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 requisitos de ancho de banda bajos.
Minimizando el ancho de banda
Ahora que entiende el licer S, puede que se pregunte por qué iremos a desarrollar un componente de software front-end para mover transmisiones en vivo de eventos a la nube. ¿Por qué los editores no podían enviar un flujo RTMP (Real-Time Messaging Protocol), por ejemplo? (Puede hacer esto si lo desea, pero la mayoría de nuestros clientes aprovechan el Slicer.)La respuesta tiene tanto que ver con las expectativas de los consumidores para transmisiones en vivo de alta calidad como con trabajar en torno a los desafíos de ancho de banda en los lugares en vivo. Es cuestión de encontrar el equilibrio adecuado entre muchos factores competidores. Por un lado, es necesario conservar la mayor cantidad posible de la alimentación original, con la mirada puesta en 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 generales adicionales, como la publicidad personalizada. Encontrar el equilibrio adecuado es crítico para este paso del flujo de trabajo de video.
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 mayor 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 acumularse rápidamente. Si sus necesidades son tales que necesita un enlace ascendente por satélite, un camión de banda Ka, por ejemplo, se alquila 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 mientras se asegura de ofrecer una experiencia similar a la de transmisión a sus espectadores.
Codificación de obstáculos
Una vez que la fuente de vídeo en vivo abandona el lugar, el siguiente paso en el flujo de trabajo es la codificación. Aquí, un codificador de vídeo crea varias versiones o variantes del audio y el vídeo a diferentes velocidades de bits, resoluciones y niveles de calidad. A continuación, segmenta las variantes en pequeños archivos o segmentos de medios. Se deben realizar varios pasos adicionales, como crear una lista de reproducción multimedia 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 apropiada para el dispositivo y el ancho de banda medido o disponible actualmente.
Dos protocolos principales de transmisión de video se suman a la complejidad, y es posible que otros necesiten ser compatibles para cubrir la gran cantidad de dispositivos de reproducción potenciales. HLS es un protocolo de comunicación de streaming de medios basado en HTTP implementado por Apple. Ofrece soporte para todos los dispositivos Apple y la mayoría de los navegadores y dispositivos Google, Android, Linux y Microsoft. La mayoría, pero no todos. También necesita MPEG-DASH, un protocolo de transmisión multimedia basado en HTTP de la competencia. 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 más antiguos 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 soportan HLS y FairPlay, y CMAF CBC. Windows y Android más antiguos solo admiten CMAF CTR. Los nuevos Android, Windows e iOS deben 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 escala completa de codificación ABR 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 podría afectar en última instancia 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 streaming como Edgio, anteriormente Verizon Digital Media Services, el modelo de streaming a codificador 1:1, no ofrece la fiabilidad, flexibilidad y escalabilidad que necesitamos para satisfacer las expectativas de nuestros clientes.
En su lugar, hemos desarrollado un sofisticado sistema de intermediación que permite el uso de tantos codificadores como necesitamos, todos funcionando 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 trozos moviéndose a través del sistema hasta el almacenamiento y hacia los espectadores.
El proceso del broker escala nuestra infraestructura de codificadores en la nube sin problemas y, lo que es más importante, automáticamente.
En nuestra implementación, una instancia de broker actúa como un gestor que habla 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 nos volcamos con un millón de horas de contenido VOD que necesita ser codificado, podemos aumentar las instancias del servidor rápidamente y comenzar a procesar el contenido. También podemos reducirnos con la misma rapidez para conservar los recursos. Este proceso de broker gestiona toda nuestra infraestructura de nube sin problemas y, lo que es más importante, automáticamente.
Codificadores apátridas
Por supuesto, el sistema de intermediación tendría un valor limitado si todo lo que pudiera 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 encoders sin estado. En lugar de dedicar una sola máquina a todo el flujo, cada codificador solo recibe un segmento de vídeo 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 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 desde 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 note cualquier problema dentro de la transmisión.
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 de 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, y así sucesivamente. Luego, los trozos se entregaron sin problemas porque todos se completaron en un tiempo predecible. Como se muestra en el siguiente gráfico, este ejemplo daría como resultado una latencia detrás de vivo de 16-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 en vivo. Si desea configurar una infraestructura de codificación utilizando un modelo tradicional, tendrá que invertir en costosas máquinas de alto rendimiento o hardware especializado, cada una capaz de procesar todo el vídeo entrante sin asistencia en tiempo real. Al aprovechar la escalabilidad de la nube, reducimos significativamente los costes 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 alternativos en la nube, 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 el streaming en la nube pueden presentar obstáculos formidables. Te enfrentarás a varios problemas que van desde limitaciones de ancho de banda hasta preguntas complejas que rodean a codificadores y protocolos de streaming. 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 los flujos de alta calidad y baja latencia que esperan sus espectadores.
