CMCDv2 : faire évoluer la télémétrie de votre streaming vidéo

Au fil de mes différents postes d'ingénieur dans le secteur du streaming vidéo, une conversation (et des problèmes partagés) avec mes pairs revenait souvent : la duplication des efforts et le fait qu'une grande partie de notre travail revenait en réalité à développer chacun de notre côté les mêmes logiciels, au sein de notre entreprise.

Depuis quelque temps maintenant, la situation tend à évoluer grâce à d'excellents projets visant à ouvrir et standardiser les pièces les plus courantes du puzzle du streaming. Chez Fastly, nous nous intéressons tout particulièrement aux projets qui impliquent la périphérie, comme le contrôle d'accès distribué avec les Common Access Tokens et la compréhension de l'impact des performances réseau sur l'expérience des spectateurs avec la norme Common Media Client Data.

La publication de la version 2 de la norme CMCD marque une excellente occasion de revenir sur ce qui a fait le succès de la version 1 et d'examiner les possibilités qu'ouvre la nouvelle version.

Zoom sur la norme CMCD

La version 1 de la norme CMCD est une solution élégante à un problème courant des services de streaming : les logs des lecteurs vidéo pouvaient indiquer quand l'utilisateur subissait une mise en mémoire tampon ou une baisse de qualité. De leur côté, les logs des CDN pouvaient signaler des problèmes au niveau du réseau ou du serveur d'origine. Le problème ? Ces deux ensembles de logs étaient souvent agrégés dans des endroits très différents et il n'existait aucun moyen simple de les corréler, en particulier sur plusieurs CDN et dispositifs de lecture différents. Le débogage des problèmes de lecture impliquait souvent de tenter de corréler les pics et les horodatages entre différents graphiques.

Avant la norme CMCD : les logs des lecteurs et ceux du CDN vivaient chacun de leur côté

Les deux ensembles de logs se retrouvaient souvent dans différents buckets, voire chez différents fournisseurs de stockage

La norme CMCDv1 a standardisé un ensemble de paires clé/valeur qui pouvaient être transmises dans une requête HTTP pour un manifeste ou un segment média, puis analysées et consignées avec le reste du logging CDN pour cette requête. Ainsi, nous obtenons une vision beaucoup plus complète des sessions utilisateur sur l'ensemble de la pile et pouvons même examiner chaque session en détail si nécessaire.

Le format exact dépasse le cadre de cet article, mais le projet open source dash.js a produit une excellente page de démonstration, sur laquelle vous pouvez voir les événements se déclencher en temps réel alors que vous regardez une vidéo d'un lapin exceptionnellement grand. 

Cela nous permet d'effectuer un traçage full-stack des sessions de lecture. Nous avons désormais une vue d'ensemble de ce qui se passait dans le lecteur et sur le serveur, à tout moment, et pouvons répondre à certaines questions :

• La hausse de la latence d'origine a-t-elle entraîné une mise en mémoire tampon ou une baisse de la qualité de lecture ?

• Le manque de mémoire tampon varie-t-il selon le POP du CDN ?

• Certains lecteurs gèrent-ils mieux les pics de latence ?

• Les performances varient-elles selon l'ASN ?

Cela vous permet également de fournir au CDN des indications sur les requêtes (de segments ou de plages de fichiers) susceptibles de suivre et d'accélérer les requêtes suivantes par le biais d'un préchargement.

Comme la CMCD est une norme ouverte désormais largement adoptée, vous pouvez connecter n'importe quel lecteur vidéo et outil de surveillance populaire, d'un côté ou de l'autre, et bénéficier d'une observabilité instantanée.

La solution Fastly est particulièrement bien adaptée pour jouer le rôle d'intermédiaire dans cette architecture, car notre capacité de logging en temps réel dans un format et avec des valeurs définis par l'utilisateur vers un large éventail de plateformes, dans le cadre du streaming en direct, permet aux opérateurs de réagir immédiatement à tout problème survenant pendant leurs événements et d'en établir le diagnostic.

Pour vous aider à bien vous lancer, nous avons préparé cet exemple d'analyse des valeurs CMCD en VCL. 

Nouveautés de la norme CMCDv2

Bien qu'elle soit dépendante du même protocole, la norme CMCDv2 représente en réalité une avancée architecturale qui vise à s'appuyer sur le succès du mode Requête pour intégrer une télémétrie enrichie côté client.

La version 2 est entièrement rétrocompatible avec l'enrichissement des requêtes CDN de la première version (qu'elle désigne désormais sous le nom de mode Requête), mais ajoute deux nouveaux modes : le mode Réponse et le mode Événement. Elle permet également d'envoyer directement depuis le client vers des domaines tiers (par exemple, vers un agrégateur de métriques SaaS), au lieu d'obliger ces nouveaux modes à emprunter le même chemin que les données vidéo.

En plus de ces deux nouveaux modes, la version apporte de nombreuses autres paires clé/valeur au mode Requête, en s'appuyant sur les enseignements tirés des déploiements réels de la CMCDv1.

Une fois encore, il y a trop à couvrir dans un seul article, mais voici quelques-uns des nouveaux indicateurs que nous avons déjà hâte d'utiliser :

• Taille cible de la mise en mémoire tampon : permet à votre analyse de déterminer la taille de mise en mémoire tampon par rapport à sa taille idéale, plutôt que de la considérer comme un nombre abstrait. C'est important, car les différentes implémentations de lecteurs, dispositifs et types de contenus peuvent viser des tailles de mise en mémoire tampon cibles très différentes. 

• Indicateurs de dégradation absolue/relative : subir un blocage de 3 s une seule fois au cours d'une vidéo représente une expérience utilisateur très différente d'un blocage à chaque segment. Plusieurs nouveaux indicateurs visent à mieux différencier ces types de cas.

• Différenciation des sous-contenus : le passage du contenu principal aux pauses publicitaires est un moment fréquent où apparaissent des problèmes de lecture. La CMCDv2 vous permet de distinguer les différents types de contenus et de comprendre exactement où les problèmes surviennent.

Mode Réponse

Le mode Réponse complète les données transmises avec la requête média en mode Requête. Il s'exécute après que le client a fini de recevoir le segment de données vidéo/audio du CDN et lui permet de communiquer des données dont il ne disposait pas au moment de la requête, comme le temps jusqu'au premier octet, le temps jusqu'au dernier octet et le code de réponse HTTP.

Bien que bon nombre de ces champs soient disponibles dans les logs du CDN, les avoir dans le lecteur et les envoyer directement à un point de terminaison externe pourrait être utile dans des cas tels qu'une configuration multi-CDN, afin d'éviter d'avoir à normaliser et à agréger les logs, ou lorsque vous pourriez avoir affaire à des CDN qui ne proposent pas de logging en temps réel.

Mode Événement

Le mode Événement est celui dans lequel s'est déroulée la majeure partie des nouveautés et qui vise à résoudre l'une des principales limites de la version originale : celle-ci était liée à l'enregistrement des informations conjointement aux requêtes multimédias, alors que de nombreux éléments pertinents (mise en pause, lecture en arrière-plan, changement manuel de qualité) peuvent se produire de manière asynchrone au cours d'une session de lecture. Ce nouveau mode vous permet de capturer non seulement ces événements (ainsi que des événements définis librement par l'utilisateur), mais aussi le moment exact où ils se produisent, au lieu d'être tributaire du timing des requêtes HTTP.

Traditionnellement, ces événements auraient été consignés par des indicateurs définis par le lecteur, mais ils auraient des noms et des paramètres propres à chaque lecteur que vous utilisiez et seraient difficiles à relier à vos indicateurs CDN. Si vous avez suivi les raisons qui ont motivé la CMCDv1, cela devrait commencer à vous sembler très familier !

Si vous souhaitez essayer ce nouveau mode mais que vous avez des inquiétudes concernant le nombre de nouveaux événements qui atteignent votre serveur d'origine ou la mise en place d'un nouveau pipeline de données pour les ingérer, alors Beacon Termination de Fastly est une excellente option : elle vous permettra d'absorber cette nouvelle charge, de filtrer les événements et de les transférer vers les outils tiers de traitement des données que vous utilisez.

Devrais-je commencer à utiliser la norme CMCDv2 ?

C'est un peu plus compliqué que ça ! Vous pouvez tout à fait l'utiliser, mais voici quelques points à garder à l'esprit :

• C'est encore un ajout majeur et relativement récent à la norme, et la prise en charge des lecteurs et de la supervision est toujours en cours de développement. La CML de la SVTA la prend en charge et continue d'évoluer activement, ce qui signifie que les bibliothèques de lecteurs comme hls.js et dash.js en bénéficient par défaut.

• Le « mode Événement » pourrait ajouter beaucoup plus de données et une complexité sémantique dont il faudrait tenter de dégager des informations exploitables. Vous devrez peut-être repenser vos pipelines de logging et de données, envisager l'échantillonnage si vous ne le faites pas déjà ou, à tout le moins, choisir méticuleusement les événements que vous capturez.

• Lorsque vous utilisez le mode Événement avec des indicateurs envoyés directement vers un point de terminaison de collecte tiers, vos indicateurs risquent davantage d'être bloqués par des bloqueurs de publicité, ce qui peut fausser vos données ou créer des lacunes.

Si vous souhaitez vous faire une meilleure idée avant de vous engager, consultez cette page de démonstration, que nous avons créée pour vous montrer les types d'événements en mode Événement déclenchés pendant une session de lecture. 

Envie d'intégrer CMCDv2 à votre pile de streaming ? Le mode Événement consiste à sélectionner ce que vous capturez et soulève de nouvelles questions sur l'endroit où ces données aboutissent et la manière dont vous les acheminez. Contactez notre équipe pour en savoir plus sur le logging, la terminaison des balises et la normalisation multi-CDN pour votre configuration.