Las experiencias de visualización personalizadas a un nivel 1:1 están transformando la experiencia de televisión. En lugar de un tamaño único, los espectadores obtienen publicidad personalizada y altamente relevante, contenido personalizado, recomendaciones para nuevos programas y gestión precisa de DRM/apagón, todo ello basado en el tipo de dispositivo, ubicación, historial, demografía y otros datos de sus espectadores.
Pero escalar las transmisiones de video personalizadas a millones de espectadores, especialmente para la programación en vivo como los deportes, es casi tan difícil como golpear para el ciclo en el béisbol. Los volúmenes de los espectadores pueden oscilar salvajemente, aumentando por cientos de miles en los momentos que hay que ver, como el inicio, las horas extras y durante los partidos cerrados. Supongamos que su infraestructura para soportar la personalización no es lo suficientemente adaptable y escalable. En ese caso, su experiencia personalizada se acabará, y todo su negocio podría estar en riesgo en el mundo de OTT.
El papel central del servidor de manifiesto en la personalización
La personalización OTT depende del rendimiento del servidor de manifiesto para generar una lista de reproducción única de contenido, anuncios e instrucciones de reproducción. El servidor MANIFEST tiene que lidiar con las siguientes dependencias:
- Latencia del servidor de anuncios: La comunicación con los servidores de anuncios puede agregar latencia que debe tenerse en cuenta en el flujo de trabajo, especialmente cuando hay varios saltos involucrados.
- Monetización/informes: Una vez que se reproduce el anuncio, se debe enviar una baliza al servidor de anuncios para medir las impresiones de los anuncios y habilitar la monetización.
- Aspectos sin estado de Internet: Para que los manifiestos personalizados funcionen a escala, el estado debe mantenerse a través de múltiples solicitudes para cada espectador.
- DRM/autenticación: El servidor de manifiesto debe controlar la gestión de derechos digitales (DRM), el cifrado a nivel de sesión y la autenticación.
- Derechos y restricciones de apagón/contenido: En función de la ubicación del usuario, el contenido de streaming puede estar sujeto a varias reglas de apagón, todas las cuales deben administrarse con precisión.
- Recomendaciones de contenido: Los espectadores en línea esperan que los conozca y personalice sus recomendaciones para ayudarlos a través del proceso de búsqueda y descubrimiento.
- Localización de contenido: Para eventos importantes, es fundamental proporcionar a los usuarios las variaciones regionales adecuadas, incluidas pistas de audio, subtítulos cerrados y subtítulos.
Personalización de streams en tiempo real
Como se describe en la Parte 1 de esta serie de blog, una fuente en vivo o VOD es ingerida, codificada y empaquetada por nuestra aplicación de software Slicer. Se pueden insertar límites de anuncios para permitir a los propietarios de contenido personalizar la experiencia del espectador. A medida que se ingieren los anuncios, también se procesan a través de un Slicer que se ejecuta en la nube para una experiencia de reproducción más parecida a la de la difusión.
Cuando el Slicer comienza a ingerir la transmisión en vivo o VOD, se comunica continuamente con nuestra infraestructura de backend, manteniendo la base de datos actualizada sobre cuántos segmentos hay disponibles. Los servidores MANIFEST utilizan esos datos para personalizar la experiencia de cada espectador. Cuando un reproductor solicita una secuencia, el servidor de manifiesto determina qué segmentos de vídeo y audio deben enumerarse en el archivo de manifiesto, que actúa como una lista de reproducción. La capacidad de cambiar dinámicamente o personalizar el manifiesto a un nivel por usuario hace posible adaptar la experiencia de visualización. En el caso del vídeo en vivo, se solicita un nuevo manifiesto cada pocos segundos, lo que permite que los servidores del manifiesto apliquen ajustes dinámicamente a medida que cambian las condiciones de visualización.
El papel central del servidor de manifiesto en la personalización de los flujos de vídeo
Como se muestra anteriormente, en el núcleo de la personalización manifiesta está la comunicación. Con la mayoría de los requisitos empresariales OTT, eso significa comunicaciones con servidores de anuncios para proporcionar anuncios personalizados y dirigidos en tiempo real. Los datos individuales, incluida la dirección IP, la ubicación y el tipo de dispositivo del espectador (esencialmente toda la información que podemos capturar sin dejar de cumplir las estrictas normas y regulaciones de PII) se proporcionan al sistema de decisión de anuncios. La solución resultante es lo suficientemente robusta como para saber qué es relevante para un espectador al entregar anuncios durante transmisiones en vivo. El sistema también es lo suficientemente robusto como para hacer frente a desafíos como la gestión de restricciones de bloqueo y derechos de contenido por usuario, al tiempo que admite importantes capacidades de personalización, como recomendaciones de contenido y otras localizaciones.
Arquitectura de la infraestructura de manifiesto a escala
En nuestra plataforma de video, el servidor de manifiesto es responsable de generar un manifiesto de streaming personalizado para cada espectador. También debe tener en cuenta otros requisitos mencionados anteriormente, como las restricciones de contenido y las recomendaciones. En este modelo, enviamos un flujo integrado, lo que significa que no hay problemas de “búfer wheel” mientras los clientes esperan que los anuncios se carguen en el medio de la transmisión.
Para crear un sistema de entrega de manifiestos resiliente, mantenemos clústeres de servidores de generación de manifiestos en la nube que se distribuyen en diferentes regiones geográficas de todo el mundo. En los Estados Unidos, por ejemplo, estos servidores están organizados en cinco regiones en todo el país. Cuando una solicitud de una nueva transmisión llega de un jugador con sede en los EE.UU., esa solicitud se enruta aleatoriamente a una de las zonas de los EE.UU..
El desafío del ‘rebaño trueno’
Esto puede parecer contrario a la intuición, pero se hace para evitar los modos de fallo en cascada. La mayoría de los espectadores estadounidenses se encuentran en las partes orientales del país. Si tuviéramos que enrutarlos a todos a la zona más cercana a ellos, y nuestro proveedor de nube experimentara un fallo en esa región, la mayoría de nuestros espectadores experimentarían ese fallo. Agravando el problema, si todos esos espectadores actualizan la transmisión, y ahora estamos dirigiendo a los espectadores a su próxima zona saludable más cercana, experimentaríamos un problema de “rebaño estruendoso” donde todos los espectadores de la zona fallida ahora cazan a la siguiente zona más cercana. El aumento inesperado del tráfico resultante podría causar un fallo secundario hasta que nuestros sistemas en la nueva zona puedan escalar para satisfacer la demanda adicional.
En cambio, distribuir aleatoriamente a nuestros espectadores en Estados Unidos ayuda a mitigar el efecto de cualquier fallo inicial y nos permite distribuir uniformemente el tráfico de conmutación por error al resto de las zonas saludables.
En nuestra plataforma de streaming, distribuimos la carga del servidor manifiesto a través de zonas. Esto evita sobrecargar cualquier zona específica durante los aumentos de audiencia, especialmente si los espectadores se desplazan repentinamente a una zona adyacente durante la conmutación por error.
Cada una de nuestras zonas tiene un almacén de datos separado dedicado a almacenar los datos de sesión asociados. Una vez que un visor se enruta a una zona, creamos una sesión para ese visor y la guardamos en el clúster de sesiones de la zona. La sesión es un montón de datos sobre el visor y los parámetros proporcionados por el cliente sobre cómo le gustaría personalizar la sesión para ese visor. Para superar el desafío que presenta la naturaleza sin estado de Internet, los servidores de manifiesto construyen URL para cada sesión incluida en el manifiesto devuelto al reproductor. Las solicitudes posteriores del jugador se dirigen directamente a la zona donde se creó y almacenó la sesión del espectador (en lugar de enrutarlas aleatoriamente a una de las otras zonas).
Como se muestra en los tres gráficos a continuación, diferentes eventos pueden tener muchos requisitos diferentes dependiendo del tamaño de la audiencia y si la audiencia es local o geográficamente dispersa. Eche un vistazo a los tres ejemplos que ilustran los desafíos de infraestructura a los que se enfrentan las emisoras para apoyar eventos en vivo.
En el primer escenario, presentamos un concurso de comida (sí, hemos transmitido en vivo uno de estos) porque ilustra un tamaño de audiencia distribuido pero pequeño. Tal vez llegue el día en que los concursos de comida se conviertan en la corriente principal, pero por ahora, siguen siendo un evento de nicho que atrae a un pequeño número de espectadores a través de una amplia geografía. La carga del servidor de manifiesto se distribuye fácilmente entre múltiples zonas y clústeres de servidor de manifiesto. Aquí es donde el valor de la personalización se vuelve obvio al facilitar la inserción de anuncios que sean apropiados para cada región y al mismo tiempo poder gestionar los derechos y los apagones.
El escenario cambia considerablemente para los campeonatos estatales de fútbol de Texas, donde un gran número de espectadores están en la misma geografía. Manejamos esto de un par de maneras. Como se discutió anteriormente, hemos encontrado que podemos asignar a los espectadores a servidores de manifiesto ubicados en zonas fuera de la geografía inmediata sin afectar la experiencia del espectador. Además de eso, tenemos un sistema que monitorea los niveles de visualización en cada zona y puede activar automáticamente los servidores de generación de manifiestos según sea necesario por zona.
Podemos pre-escalar en función de la audiencia esperada para grandes eventos como las Finales de la NBA. Aún así, hemos tenido múltiples eventos en los que nuestros sistemas de escalado automático manejaron casi un millón de espectadores sin requerir ningún pre-calentamiento. Además de aumentar la escalabilidad, la capacidad de distribuir instantáneamente la carga entre los servidores de manifiesto de una manera independiente de la zona mejora significativamente la confiabilidad y la redundancia en toda la red.
Solicitudes de jugadores y ad beaconing
Una serie de cambios y tendencias en toda la industria están haciendo que el escalado en la nube sea más importante que nunca. Un factor principal es el intervalo de reducción entre las peticiones del jugador. Nuestra solicitud de jugador lineal en vivo estándar de 8 segundos “What’s Next” está siendo conducida a 5 segundos y puede ser tan breve como cada 2 segundos para transmisiones donde la baja latencia es importante. Esto afecta mayormente a la utilización de la CPU porque el servidor tiene que responder a 4 veces más solicitudes (a intervalos de 2 segundos en comparación con intervalos de 8 segundos). Además, las recomendaciones de apagón y contenido ahora también deben revisarse con más frecuencia que en el pasado para evitar errores.
Del mismo modo, el mundo de la tecnología publicitaria se está volviendo más complejo y exigente. Por cada anuncio insertado en un flujo, un servidor de anuncios tendrá al menos cinco balizas utilizadas para fines de presentación de informes. Se requiere una solución de inserción de anuncios del lado del servidor (SSAI) para garantizar que envía esas balizas para que sus clientes reciban el pago de sus anunciantes. Mientras que cinco balizas son el mínimo, puede haber muchos más. De hecho, hemos visto casos en los que un solo anuncio tiene entre 30 y 100 balizas para informar.
Además, las redes complejas de servidores publicitarios se están volviendo más comunes en las campañas de nuestros clientes. Varios saltos de red publicitaria pueden comenzar a causar problemas de latencia. Por ejemplo, la red #1 podría decir: “Aquí está la lista de anuncios en este descanso”, solo para descubrir que el anuncio #2 en ese descanso requiere una solicitud a otra red. Ad #3 introduce dos saltos más, y así sucesivamente.
En el ejemplo anterior, los saltos de anuncio pueden duplicar o triplicar la utilización de la CPU. Las solicitudes de reproductores de vídeo en vivo pueden combinar este factor en un 10-30%.
Looking AHORA — microservicios y escalabilidad
Con el aumento de la complejidad, uno de los pasos que hemos tomado es separar las diferentes cargas de trabajo manejadas anteriormente por los servidores de manifiesto en microservicios más pequeños. El primer paso que hemos dado es mover las comunicaciones y balizas del servidor de anuncios a su propio servicio, ayudando a abordar el desafío de la latencia del servidor de anuncios. Este servicio de proxy de anuncios ofrece varias capacidades avanzadas que discutiremos con más profundidad en una próxima publicación de blog.
En el futuro, continuaremos desarrollando otros microservicios para eliminar más trabajo de los servidores de manifiesto y ofrecer un enfoque más específico para la escalabilidad. Pronto, agregaremos zonas de múltiples proveedores de nube para ser resilientes a los fallos de cualquiera de ellos.
Al combinar SSAI escalable con microservicios, podemos optimizar los costos del servidor, la estructura de nuestra base de código y otras características específicas del tráfico publicitario. Además, podemos superar varios desafíos clave, como la latencia del servidor de anuncios, las restricciones de apagón y la monetización. Al mismo tiempo, al distribuir la carga de procesamiento a través de múltiples zonas, nuestro servicio de transmisión de video en vivo puede escalar ampliamente y superar los desafíos clave, lo que nos permite entregar de forma confiable millones de transmisiones personalizadas simultáneas sin sobrecargar nuestra red de entrega.
