Las experiencias de visualización personalizadas a un nivel 1:1 están transformando la experiencia de la televisión. En lugar de un solo tamaño, los espectadores obtienen publicidad específica y altamente relevante, contenido personalizado, recomendaciones para nuevos programas y administración precisa de DRM/blackout, todo basado en el tipo de dispositivo, ubicación, historial, demografía y otros datos de los espectadores.
Pero escalar transmisiones de video personalizadas a millones de espectadores, especialmente para programación en vivo como 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 en cientos de miles en momentos imprescindibles como el inicio, el tiempo extra y durante partidos cercanos. Suponga que su infraestructura para apoyar la personalización no es lo suficientemente adaptable y escalable. En ese caso, su experiencia personalizada terminará el juego, y todo su negocio podría estar en riesgo en el mundo de OTT.
El papel central del servidor 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 de manifiesto 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 se trata de múltiples saltos.
- Monetización/presentación de informes : Una vez que se reproduce el anuncio, se debe enviar una baliza de nuevo al servidor o servidores de anuncios para medir las impresiones de anuncios y habilitar la monetización.
- Aspectos apátridas 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 manifiestos debe controlar la gestión de derechos digitales (DRM), el cifrado a nivel de sesión y la autenticación.
- Derechos y restricciones de blackout/contenido : En función de la ubicación del usuario, el contenido de streaming puede estar sujeto a varias reglas de blackout, todas las cuales deben administrarse con precisión.
- Recomendaciones de contenido : Los espectadores en línea esperan que los conozcas y personalices tus 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 variaciones regionales apropiadas, incluidas pistas de audio, subtítulos y subtítulos.
Personalización de flujos en tiempo real
Como se cubre en la parte 1 de esta serie de blogs, 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 transmisión.
Cuando el Slicer comienza a ingerir el flujo en vivo o VOD, se comunica continuamente con nuestra infraestructura de backend, manteniendo la base de datos actualizada sobre cuántos segmentos están disponibles. Los servidores de manifiesto utilizan esos datos para personalizar la experiencia para cada espectador. Cuando un reproductor solicita un flujo, el servidor de manifiesto determina qué segmentos de vídeo y audio deben aparecer en el archivo de manifiesto, que actúa como una lista de reproducción. La capacidad de cambiar o personalizar dinámicamente el manifiesto a nivel de usuario permite adaptar la experiencia de visualización. En el caso del video en vivo, se solicita un nuevo manifiesto cada pocos segundos, permitiendo que los ajustes sean aplicados dinámicamente por los servidores de manifiesto a medida que cambian las condiciones de visualización.
El papel central del servidor de manifiesto en la personalización de 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 personalizados 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 con las estrictas reglas y regulaciones de PII, se proporcionan al sistema de decisión de anuncios. La solución resultante es lo suficientemente robusta como para aprender lo que 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 apagón y derechos de contenido por usuario, al tiempo que admite importantes capacidades de personalización, como recomendaciones de contenido y otras localizaciones.
Arquitectura de infraestructura manifiesta 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 conocer 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 «rueda de búfer» mientras los clientes esperan que los anuncios se carguen en el medio del flujo.
Para construir 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 EE.UU., por ejemplo, estos servidores están organizados en cinco regiones en todo el país. Cuando una solicitud para una nueva transmisión llega de un jugador con sede en EE.UU., esa solicitud se dirige al azar a una de las zonas de EE.UU.
El desafío del “rebaño trueno”
Esto puede parecer contradictorio, pero se hace para evitar los modos de falla en cascada. La mayoría de los espectadores estadounidenses se encuentran en las partes orientales del país. Si tuviéramos que dirigirlos a todos a la zona más cercana a ellos, y nuestro proveedor de nube experimentara un fracaso en esa región, la mayoría de nuestros espectadores experimentarían ese fracaso. Para agravar el problema, si todos esos espectadores actualizan la transmisión, y ahora estamos dirigiendo a los espectadores a su siguiente zona saludable más cercana, experimentaríamos un problema de «rebaño de truenos» en el que todos los espectadores de la zona fallida ahora se dirigen 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 su lugar, distribuir al azar a nuestros espectadores en EE.UU. Ayuda a mitigar el efecto de cualquier fallo inicial y nos permite distribuir de manera uniforme 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 en todas las zonas. Esto evita la sobrecarga de cualquier zona específica durante las oleadas 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 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 espectador y parámetros proporcionados por el cliente sobre cómo le gustaría personalizar la sesión para ese espectador. Para superar el desafío presentado por la naturaleza sin estado de Internet, los servidores de manifiestos construyen URLs 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 enrutarla al azar 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 que 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 en una amplia geografía. La carga del servidor de manifiesto se distribuye fácilmente a través de múltiples zonas y clústeres de servidor de manifiesto. Aquí es donde el valor de la personalización se hace evidente al facilitar la inserción de anuncios que son apropiados para cada región y también ser capaz de gestionar derechos y bloqueos.
El escenario cambia considerablemente para los campeonatos estatales de fútbol de Texas, donde un gran número de espectadores se encuentran en la misma geografía. Manejamos esto de un par de maneras. Como se mencionó anteriormente, hemos encontrado que podemos asignar 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 audiencia 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 base a 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 autoescalado manejaron casi un millón de espectadores sin requerir ningún precalentamiento. 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.
Peticiones de los jugadores y ad beaconing
Una serie de cambios y tendencias en toda la industria están haciendo que el escalamiento de la nube sea más importante que nunca. Un conductor importante es el intervalo de reducción entre las solicitudes del jugador. Nuestra petición de jugador lineal en vivo de 8 segundos “lo que sigue” se está llevando a 5 segundos y puede ser tan breve como cada 2 segundos para las transmisiones donde la baja latencia es importante. Esto afecta principalmente 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 contenido y apagón 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 generación de informes. Se requiere una solución de inserción de anuncios en el lado del servidor (SSAI) para garantizar que envíe 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 complejas redes de servidores de anuncios son cada vez más comunes en las campañas de nuestros clientes. Múltiples saltos de red de anuncios 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 anuncios pueden duplicar o triplicar la utilización de la CPU. Las solicitudes de reproductores de video en vivo pueden aumentar este factor entre un 10 y un 30%.
Looking Ahead — Microservicios y escalabilidad
Con el aumento de la complejidad, uno de los pasos que hemos tomado es separar las diferentes cargas de trabajo previamente manejadas por los servidores de manifiesto en microservicios más pequeños. El primer paso que hemos dado es mover las comunicaciones y beaconing de los servidores de anuncios a su propio servicio, lo que ayuda a abordar el desafío de la latencia de los servidores 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.
Al acoplar 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 en múltiples zonas, nuestro servicio de transmisión de video en vivo puede escalar ampliamente y superar desafíos clave, lo que nos permite entregar de manera confiable millones de transmisiones personalizadas simultáneas sin forzar nuestra red de entrega.
