CMCDv2: la telemetría del streaming de vídeo pasa al siguiente nivel

Durante mi trayectoria en distintos puestos de ingeniería en el sector del streaming de vídeo, un tema recurrente de conversación —y a veces de lamento compartido— con mis colegas era la duplicación de esfuerzos: gran parte de nuestro trabajo consistía, en la práctica, en desarrollar el mismo software por separado dentro de nuestras respectivas empresas.

Últimamente, esto ha empezado a cambiar gracias a iniciativas excelentes para abrir y estandarizar los componentes más habituales 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 afecta el rendimiento de la red a la experiencia del espectador mediante Common Media Client Data.

Con el reciente lanzamiento de la versión 2 del estándar CMCD, nos ha parecido una buena ocasión para repasar qué hizo que la versión 1 tuviera tanto éxito y analizar 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 habitual de los servicios de streaming: los registros de los reproductores de vídeo podían indicar cuándo un usuario sufría interrupciones por almacenar en búfer o bajadas de calidad, y los registros de las redes de distribución de contenidos podían indicar cuándo había problemas en la red o en el origen. Sin embargo, estos dos conjuntos de registros solían agregarse en lugares muy distintos y no había una forma sencilla de correlacionarlos, especialmente cuando intervenían varias redes de distribución de contenidos y distintos dispositivos de reproducción. Para depurar problemas de reproducción, a menudo había que intentar correlacionar picos y marcas de tiempo entre distintos gráficos.

Antes de CMCD: los registros de los actores y de las redes de distribución de contenidos por separado

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

CMCDv1 estandarizó un conjunto de pares clave-valor que podían incluirse en una petición HTTP de un manifiesto o un segmento multimedia y, después, análisis y registro junto con el resto de la creación de registros de la red de distribución de contenidos correspondientes a esa petición. Esto significa que ahora podemos obtener 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 este artículo, pero el proyecto de código abierto dash.js ha creado una excelente página de demostración que te permite ver cómo se activan los eventos en tiempo real mientras ves un vídeo de un conejo inusualmente grande. 

Esto nos permite, en la práctica, seguir las trazas de toda la pila tecnológica a lo largo de las sesiones de reproducción: ahora podemos ver qué ocurría en el actor y en el servidor en cualquier momento y responder a preguntas como estas:

• ¿El aumento de la latencia de origen provocó interrupciones para almacenar en búfer o caídas en la calidad de reproducción?

• ¿Varía el agotamiento del búfer según el punto de presencia de la red de distribución de contenidos?

• ¿Gestionan algunos actores 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 contenidos qué peticiones podrían llegar después, ya sean de segmentos o de rangos de archivos, y acelerar las peticiones posteriores mediante la precarga.

Como CMCD es un estándar abierto y ya ampliamente adoptado, puedes conectar cualquier actor de vídeo y herramienta de monitorización populares en cada extremo y obtener observabilidad al instante.

Fastly resulta especialmente adecuado para actuar como intermediario en esta arquitectura: nuestra capacidad para enviar creación de registros en tiempo real con cualquier formato y valor definidos por el usuario a diversas 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, hemos preparado este ejemplo de análisis de valores de CMCD en Varnish Configuration Language. 

Novedades de CMCDv2

Aunque se engloba en el mismo protocolo, CMCDv2 supone en realidad un salto arquitectónico que busca aprovechar el éxito del modo de petición para incorporar una telemetría detallada del lado del cliente.

La versión 2 mantiene la compatibilidad total con la ampliación de las peticiones a la red de distribución de contenidos de la primera versión (que ahora denomina modo de petición), pero añade dos modos nuevos: modo de respuesta y modo de eventos. También permite enviar datos directamente desde el cliente a dominios de terceros (por ejemplo, a un agregador de métricas Saas), en lugar de obligar a estos nuevos modos a seguir la misma ruta que los datos de vídeo.

Además de incorporar los dos nuevos modos, añade muchos más pares clave-valor al modo de petición a partir de lo aprendido con despliegues reales de CMCDv1.

Una vez más, hay demasiado que contar en un solo artículo, pero estas son algunas de las nuevas métricas que más nos entusiasman:

• Tamaño objetivo del búfer: permite que las herramientas de análisis evalúen el tamaño del búfer en relación con el tamaño ideal, en lugar de tratarlo como una cifra abstracta. Esto es importante porque las distintas implementaciones de actores, los dispositivos y los tipos de contenido pueden tener tamaños objetivo de búfer muy diferentes. 

• Métricas absolutas/relativas de degradación: sufrir un parón de 3 s una sola vez durante un vídeo ofrece una experiencia de usuario muy distinta a sufrir un parón en cada segmento. Muchas de las nuevas métricas se centran en permitir distinguir mejor entre estos tipos de casos

• Diferenciación de subcontenidos: El paso del contenido principal a las pausas publicitarias es un momento en el que suelen aparecer problemas de reproducción. CMCDv2 permite distinguir entre distintos tipos de contenido y saber exactamente dónde se producen los problemas.

Modo de respuesta

El modo de respuesta complementa los datos que se envían con la petición de contenido multimedia en el modo de petición. Se ejecuta después de que el cliente termina de recibir el fragmento de datos de vídeo o audio de la red de distribución de contenidos y permite comunicar datos de los que no disponía en el momento de la petición, 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 registros de la red de distribución de contenidos, disponer de ellos en el actor y enviarlos directamente a un punto de conexión externo podría resultar útil, por ejemplo, en una configuración con varias redes de distribución de contenidos, para evitar tener que normalizar y agregar registros, o si trabajas con redes de distribución de contenidos que no ofrecen creación de registros 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 peticiones de contenido multimedia, aunque durante una sesión de reproducción pueden producirse de forma asíncrona muchos eventos relevantes (pausas, paso a segundo plano y cambios manuales de calidad). Este nuevo modo permite registrar tanto estos eventos como otros definidos libremente por el usuario, junto con el momento exacto en que se producen, sin depender del momento en que se realizan las petición HTTP.

Tradicionalmente, estos eventos se registraban en métricas definidas por el actor. Pero los nombres y parámetros de esas métricas variaban según el actor que utilizaras, y no era fácil relacionarlas con las métricas de la red de distribución de contenidos. Si has seguido las razones que motivaron CMCDv1, ¡esto ya debería empezar a sonarte!

Si quieres probar este nuevo modo, pero te preocupa la cantidad de eventos nuevos que llegarán al origen o tener que poner en marcha una nueva canalización de datos para incorporarlos, Beacon Termination de Fastly 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?

¡La respuesta es un poco más complicada! Es perfectamente utilizable, pero hay que tener en cuenta lo siguiente:

• Sigue siendo una incorporación importante y relativamente reciente al estándar, por lo que la compatibilidad nativa en los actores y las herramientas de monitorización aún está en desarrollo. Sin embargo, biblioteca de medios comunes de SVTA ya lo admite y se sigue mejorando activamente, lo que significa que bibliotecas de actores como hls.js y dash.js lo admiten de forma predeterminada.

• El «modo de eventos» puede añadir muchos más datos y una mayor complejidad semántica a la hora de extraer conclusiones prácticas. Quizá tengas que replantearte los procesos de creación de registros y las canalizaciones de datos, plantearte el muestreo si aún no lo utilizabas o, como mínimo, seleccionar cuidadosamente qué eventos capturas.

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

Si quieres conocerlo mejor antes de confirmar, echa un vistazo a esta página de demostración que hemos preparado para mostrar los tipos de eventos del modo Evento que se activan durante una sesión de reproducción. 

¿Todo listo para incorporar CMCDv2 a tu infraestructura de streaming? El modo de eventos exige seleccionar qué eventos se capturan y plantea nuevas preguntas sobre dónde se almacenan esos datos y cómo se encaminan. Ponte en contacto con nuestro equipo si necesitas ayuda para planificar la creación de registros, la terminación de balizas y la normalización entre varias redes de distribución de contenidos en tu entorno.