CMCDv2: telemetría de streaming de video a otro nivel

Durante mis distintas funciones de ingeniería en la industria del streaming de video, mis colegas y yo hablábamos con frecuencia —y a veces nos lamentábamos— de la duplicación de esfuerzos y de cuánto de nuestro trabajo consistía, en la práctica, en desarrollar el mismo software por separado dentro de nuestras respectivas empresas.

Eso ha empezado a cambiar recientemente gracias a excelentes iniciativas para abrir y estandarizar los componentes más comunes del streaming. En Fastly, nos interesan especialmente las iniciativas relacionadas con el edge, como el control de acceso distribuido mediante Common Access Tokens y el análisis de cómo el rendimiento de la red afecta la experiencia del espectador mediante Common Media Client Data.

Con la reciente liberar de la versión 2 del estándar CMCD, pensamos que sería una buena ocasión para repasar qué hizo que la versión 1 tuviera tanto éxito y explorar las posibilidades que abre la nueva versión.

Breve historia de CMCD

La versión 1 de CMCD ofrece una solución elegante a un problema común en los servicios de streaming: los logs de los reproductores de video podían indicar cuándo un usuario experimentaba almacenamiento en búfer o caídas de calidad, y los logs de las redes de distribución de contenido podían indicar cuándo había problemas en la red o en el origen. Sin embargo, estos dos conjuntos de logs solían recopilarse en lugares muy distintos y no había una forma sencilla de correlacionarlos, sobre todo cuando intervenían varias redes de distribución de contenido y distintos dispositivos de reproducción. Para depurar los problemas de reproducción, a menudo había que intentar correlacionar los picos y las marcas de tiempo de distintas gráficas.

Antes de CMCD: los logs de los reproductores y de las redes de distribución de contenido por separado

Los dos conjuntos de logs solían estar en buckets diferentes o incluso con distintos proveedores de almacenamiento

CMCDv1 estandarizó un conjunto de pares clave/valor que podían incluirse en una solicitud HTTP de un manifiesto o segmento multimedia y luego parse y log junto con el resto de los datos de logging de la Red de distribución de contenido correspondientes a esa solicitud. Esto significa que ahora podemos tener una visión mucho más completa de las sesiones de los usuarios en toda la pila tecnológica e incluso examinar sesiones individuales si es necesario.

El formato exacto queda fuera del alcance de esta publicación, pero el proyecto de código abierto dash.js creó una página de demostración que te permite ver cómo se activan los eventos en tiempo real mientras ves un video de un conejo inusualmente grande. 

Esto nos permite rastrear toda la pila durante las sesiones de reproducción: ahora podemos ver qué ocurría en el reproductor y en el servidor en cualquier momento, y responder preguntas como:

• ¿El aumento de la latencia de origen provocó almacenamiento en búfer o una disminución de la calidad de reproducción?

• ¿La falta de datos en el búfer varía entre los puntos de presencia de la Red de distribución de contenido?

• ¿Algunos reproductores manejan mejor los picos de latencia?

• ¿Varía el rendimiento según el ASN?

También te permite indicar a la Red de distribución de contenido qué solicitudes podrían llegar después (ya sea de segmentos o de rangos de archivos) y acelerar las solicitudes posteriores mediante la obtención anticipada.

Como CMCD es un estándar abierto y ahora ampliamente adoptado, puedes conectar cualquier reproductor de video y herramienta de monitoreo populares en cada extremo y obtener observabilidad de inmediato.

Fastly es especialmente adecuado para servir de enlace en esta arquitectura, ya que nuestra capacidad de enviar logging en tiempo real con cualquier formato y valor definidos por el usuario a distintas plataformas permite a los operadores de streaming en vivo reaccionar de inmediato ante cualquier problema que surja durante sus eventos y diagnosticarlo.

Para ayudarte a empezar, preparamos este ejemplo de análisis de valores CMCD en VCL. 

Novedades de CMCDv2

Aunque forma parte del mismo protocolo, CMCDv2 representa un salto arquitectónico con el que se busca aprovechar el éxito del modo de solicitud para incorporar abundante telemetría del lado del cliente.

La versión 2 conserva la compatibilidad total con la incorporación de datos a las solicitudes de la red de distribución de contenido de la primera versión (que ahora denomina modo de solicitud), pero agrega dos modos nuevos: modo de respuesta y modo de evento. También permite enviar datos directamente desde el cliente a dominios de terceros (por ejemplo, a un agregador de métricas de Software como servicio), en lugar de obligar a que los datos de estos nuevos modos sigan la misma ruta que los datos de video.

Además de los dos modos nuevos, incorpora muchos más pares clave/valor al modo de solicitud, a partir de lo aprendido en despliegues reales de CMCDv1.

Una vez más, hay demasiado que contar en una sola publicación de blog, pero estas son algunas de las nuevas métricas que más nos entusiasman:

• Tamaño objetivo del búfer: permite que tus herramientas de analítica comparen el tamaño del búfer con su tamaño ideal, en lugar de tratarlo como un número abstracto. Esto es importante porque las distintas implementaciones de reproductores, dispositivos y tipos de contenido pueden tener tamaños objetivo del búfer muy diferentes. 

• Métricas absolutas/relativas de degradación: que la reproducción se interrumpa durante 3 s una sola vez en un video supone una experiencia del usuario muy distinta a que se interrumpa una vez en cada segmento. Muchas de las nuevas métricas se centran en distinguir mejor entre estos tipos de casos

• Diferenciación de subcontenidos: Es común que aparezcan problemas de reproducción al pasar del contenido principal a las pausas publicitarias. CMCDv2 te permite distinguir entre distintos tipos de contenido y saber exactamente dónde ocurren los problemas.

Modo de respuesta

El modo de respuesta complementa los datos que se envían con la solicitud de contenido multimedia en el modo de solicitud. Se ejecuta después de que el cliente termina de recibir el fragmento de datos de video/audio de la red de distribución de contenido y le permite informar datos de los que no disponía al momento de la solicitud, como el tiempo hasta el primer byte del cuerpo, el tiempo hasta el último byte y el código de respuesta HTTP.

Aunque muchos de estos campos estarían disponibles en los logs de la red de distribución de contenido, tenerlos en el reproductor y enviarlos directamente a un endpoint externo podría ser útil en casos como una configuración con varias redes de distribución de contenido, para evitar tener que normalizar y agregar logs, o cuando se trabaja con redes de distribución de contenido que no ofrecen logging en tiempo real.

Modo de eventos

El modo de eventos concentra la mayor parte del trabajo nuevo y busca resolver una de las principales limitaciones de la versión original: el registro de información estaba ligado a las solicitudes de contenido multimedia, aunque durante una sesión de reproducción pueden ocurrir de forma asíncrona muchas acciones relevantes (pausar, pasar a segundo plano o cambiar manualmente la calidad). Este nuevo modo te permite capturar estos eventos (y cualquier otro definido por el usuario) junto con el momento exacto en que ocurren, sin depender del momento en que se realizan las solicitudes HTTP.

Tradicionalmente, estos eventos se registraban en métricas definidas por el reproductor. Pero esas métricas tendrían nombres y parámetros propios de cada reproductor, y no sería fácil relacionarlas con las métricas de la Red de distribución de contenido. Si seguiste los motivos que dieron lugar a CMCDv1, ¡esto debería empezar a sonarte muy familiar!

Si quieres probar este nuevo modo, pero te preocupa la cantidad de eventos nuevos que llegarán a tu origen o tener que crear una nueva canalización de datos para ingerirlos, Fastly’s Beacon Termination es una excelente opción para absorber la nueva carga, filtrar los eventos y reenviarlos a las herramientas de datos de terceros que utilices.

Entonces, ¿debería empezar a usar CMCDv2?

¡Eso es un poco más complicado! Se puede utilizar perfectamente, pero hay que tener en cuenta lo siguiente:

• Sigue siendo una incorporación importante y relativamente reciente al estándar, por lo que aún se está desarrollando la compatibilidad nativa con reproductores y sistemas de monitoreo. Sin embargo, la biblioteca de medios comunes de SVTA ya lo admite y sigue mejorándose activamente, lo que significa que las bibliotecas de reproductores como hls.js y dash.js cuentan con compatibilidad de forma predeterminada.

• “Event Mode” podría añadir muchos más datos y complejidad semántica a la tarea de extraer información útil. Quizá tengas que replantear tus procesos de logging y tus canalizaciones de datos, considerar el muestreo si aún no lo haces o, al menos, elegir con cuidado qué eventos capturar.

• Cuando usas el modo de eventos y envías las métricas directamente a un endpoint de recopilación de terceros, es más probable que los bloqueadores de anuncios las bloqueen, lo que podría sesgar los datos o dejar lagunas en ellos.

Si quieres conocerlo mejor antes de comprometerte a usarlo, consulta esta página de demostración que preparamos para mostrar los tipos de eventos del Modo de eventos que se activan durante una sesión de reproducción. 

¿Todo listo para incorporar CMCDv2 a tu infraestructura de streaming? El modo de eventos implica elegir qué capturar y plantea nuevas preguntas sobre a dónde llegan esos datos y cómo los diriges. Comunícate con nuestro equipo para obtener ayuda al evaluar el logging, la terminación de beacons y la normalización entre varias redes de distribución de contenido para tu configuración.