CMCDv2: Die Videostreaming-Telemetrie verbessern

Während meiner verschiedenen Tätigkeiten im Engineering in der Videostreaming-Branche war ein häufiges Gesprächsthema (oder sogar Anlass zum gemeinsamen Klagen) mit meinen Kollegen die Doppelarbeit und die Frage, wie viel unserer Arbeit innerhalb unserer eigenen Unternehmenssilos effektiv darin bestand, dieselbe Software wie die anderen zu entwickeln.

In letzter Zeit hat sich dies jedoch allmählich geändert, da hervorragende Arbeit geleistet wurde, um die gängigsten Komponenten des Streaming-Puzzles zu öffnen und zu standardisieren. Bei Fastly interessieren wir uns besonders für das, was die Edge betrifft, wie etwa die verteilte Zugriffskontrolle mit Common Access Tokens und das Verständnis dafür, wie sich die Netzwerk-Performance auf das Zuschauererlebnis auswirkt, mit Common Media Client Data.

Anlässlich der kürzlich erfolgten Veröffentlichung von Version 2 des CMCD-Standards möchten wir die Gelegenheit nutzen, noch einmal darauf einzugehen, was Version 1 so erfolgreich gemacht hat, und einen Blick auf die Möglichkeiten zu werfen, die die neue Version eröffnet.

Ein kurzer Rückblick auf die Geschichte von CMCD

Version 1 von CMCD ist eine elegante Lösung für ein häufiges Problem bei Streaming-Services: Logs von Video-Playern konnten Aufschluss darüber geben, wann beim Nutzer Pufferungen oder Qualitätsverluste auftraten, und CDN-Logs konnten zeigen, wann Probleme im Netzwerk oder am Ursprung vorlagen. Allerdings wurden diese beiden Log-Sätze oft an ganz unterschiedlichen Orten aggregiert und es gab keine einfache Möglichkeit, sie zu korrelieren – insbesondere über mehrere verschiedene CDNs und Wiedergabegeräte hinweg. Das Debuggen von Wiedergabeproblemen lief oft darauf hinaus, Spitzen und Zeitstempel über verschiedene Graphen hinweg miteinander zu korrelieren.

Das Leben vor CMCD: Player-Protokolle und CDN-Protokolle wurden getrennt geführt

Die beiden Protokollsätze befanden sich oft an unterschiedlichen Stellen oder sogar bei unterschiedlichen Speicheranbietern

CMCDv1 standardisierte eine Reihe von Schlüssel/Wert-Paaren, die innerhalb einer HTTP-Anfrage für ein Manifest oder Mediensegment übergeben und dann zusammen mit dem restlichen CDN-Logging für diese Anfrage geparst und geloggt werden konnten. Das bedeutet, dass wir nun ein weitaus vollständigeres Bild von Nutzersitzungen über den gesamten Stack hinweg erhalten und bei Bedarf sogar detaillierte Analysen einzelner Sitzungen durchführen können.

Das genaue Format würde den Rahmen dieses Posts sprengen, aber das Open-Source-Projekt dash.js hat eine großartige Demoseite erstellt, auf der Sie in Echtzeit sehen können, wie Ereignisse ausgelöst werden, während Sie sich ein Video von einem ungewöhnlich großen Kaninchen ansehen. 

Damit erhalten wir im Grunde ein durchgängiges Full-Stack-Tracing über Wiedergabesitzungen hinweg – wir können nun nachvollziehen, was zu jedem beliebigen Zeitpunkt im Player und auf dem Server vor sich ging, und Fragen beantworten wie:

• Führte eine erhöhte Ursprungslatenz zu Puffern oder Einbußen bei der Wiedergabequalität?

• Variiert der Puffermangel je nach CDN-POP?

• Bewältigen bestimmte Player Latenzspitzen besser?

• Unterscheidet sich die Performance je nach ASN?

Es ermöglicht Ihnen außerdem, dem CDN Hinweise dazu zu geben, welche Anfragen (entweder für Segmente oder Dateibereiche) als Nächstes erfolgen könnten, und nachfolgende Anfragen durch Vorabruf zu beschleunigen.

Da CMCD ein offener und inzwischen weithin verbreiteter Standard ist, können Sie an jedem Ende beliebige gängige Video-Player und Monitoring-Tools einbinden und erhalten sofortige Observability.

Fastly eignet sich besonders gut als Datenkanal innerhalb dieser Architektur, da wir Echtzeit-Logging in beliebigen nutzerdefinierten Formaten und mit nutzerdefinierten Werten an eine Reihe verschiedener Plattformen übertragen können. So können Betreiber bei Livestreams sofort auf Probleme reagieren und diese diagnostizieren, sobald sie während ihrer Events auftreten.

Um Ihnen den Einstieg zu erleichtern, haben wir dieses Beispiel zum Parsen von CMCD-Werten in VCL zusammengestellt. 

Neuerungen in CMCDv2

Obwohl es unter demselben Protokoll gebündelt ist, ist CMCDv2 tatsächlich ein architektonischer Sprung, der darauf abzielt, auf dem Erfolg des Anfragemodus aufzubauen und umfangreiche clientseitige Telemetrie ins Spiel zu bringen.

Version 2 ist vollständig abwärtskompatibel mit der CDN-Anfrageerweiterung der ersten Version (die nun als Anfragemodus bezeichnet wird), fügt jedoch zwei neue Modi hinzu: Antwortmodus und Ereignismodus. Außerdem ermöglicht sie es, Daten direkt vom Client an Domains von Drittanbietern (z. B. an einen Aggregator für SaaS-Metriken) zu senden, statt diese neuen Modi über denselben Pfad wie die Videodaten zu leiten.

Zusätzlich zu den beiden neuen Modi fügt sie dem Anfragemodus eine ganze Reihe weiterer Schlüssel/Wert-Paare hinzu, basierend auf Erkenntnissen aus realen Deployments mit CMCDv1.

Wieder einmal ist es zu viel, um alles in einem Blog-Post zu behandeln, aber einige der neuen Metriken, auf die wir uns am meisten freuen, sind:

• Zielpuffergröße: Ermöglicht es, in Ihrer Analyse die Puffergröße im Verhältnis zur idealen Größe zu bewerten, anstatt sie als abstrakte Zahl zu betrachten. Das ist wichtig, weil verschiedene Player-Implementierungen, Geräte und Inhaltstypen sehr unterschiedliche Zielpuffergrößen anstreben können. 

• Absolute/relative Degradationsmetriken: Ein einmaliges Stocken von 3 s in einem Video ist eine völlig andere User Experience als ein Stocken bei jedem einzelnen Segment. Viele der neuen Metriken konzentrieren sich darauf, besser zwischen diesen Arten von Fällen unterscheiden zu können

• Unterscheidung von Unterinhalten: Der Wechsel von Hauptinhalten zu Werbeunterbrechungen ist ein häufiger Zeitpunkt, an dem Wiedergabeprobleme auftreten. Mit CMCDv2 können Sie zwischen verschiedenen Inhaltstypen unterscheiden und genau nachvollziehen, wo Probleme auftreten.

Antwortmodus

Der Antwortmodus ergänzt die Daten, die mit der Medienanfrage im Anfragemodus übermittelt werden. Er wird ausgeführt, nachdem der Client den Video-/Audio-Datenblock vom CDN vollständig empfangen hat, und ermöglicht dem Client, Daten zu melden, die ihm zum Zeitpunkt der Anfrage noch nicht vorlagen, wie etwa Time To First Body Byte, Time To Last Byte und HTTP Response Code.

Obwohl viele dieser Felder in den CDN-Logs verfügbar wären, könnte es in Fällen wie einer Multi-CDN-Konfiguration hilfreich sein, sie im Player zu haben und direkt an einen externen Endpunkt zu senden, um Logs nicht normalisieren und aggregieren zu müssen, oder für den Fall, dass Sie es mit CDNs zu tun haben, die kein Echtzeit-Logging anbieten.

Ereignismodus

Der Großteil der Arbeit ist in den Ereignismodus eingeflossen und dieser versucht, eine der wesentlichen Einschränkungen der ursprünglichen Version zu beheben: Er war zwangsläufig darauf ausgelegt, Informationen zusammen mit Medienanfragen aufzuzeichnen, obwohl es viele relevante Vorgänge (Pausieren, in den Hintergrund verschieben, manuelles Umschalten der Qualität) gibt, die während einer Wiedergabesitzung asynchron ablaufen können. Mit diesem neuen Modus können Sie nicht nur diese (und beliebige benutzerdefinierte) Ereignisse zusammen mit dem genauen Zeitpunkt ihres Auftretens erfassen, anstatt an den Zeitablauf von HTTP-Anfragen gebunden zu sein.

Üblicherweise wurden diese Ereignisse in vom Player definierten Metriken erfasst. Doch diese Metriken hatten je nachdem, welchen Player Sie verwendeten, einzigartige Namen und waren unterschiedlich parametrisiert. Sie ließen sich nicht ohne Weiteres mit Ihren CDN-Metriken verknüpfen. Wenn Sie den Beweggründen für CMCDv1 gefolgt sind, dürfte Ihnen das langsam sehr bekannt vorkommen!

Wenn Sie diesen neuen Modus ausprobieren möchten, aber Bedenken wegen der Anzahl neuer Ereignisse haben, die bei Ihrem Ursprung eingehen, oder wegen des Aufsetzens einer neuen Datenpipeline zu deren Aufnahme, ist Beacon Termination von Fastly eine hervorragende Möglichkeit, die neue Last abzufangen, Ereignisse zu filtern und an beliebige Daten-Tools von Drittanbietern weiterzuleiten, die Sie verwenden.

Sollte ich also anfangen, CMCDv2 zu verwenden?

Das ist etwas komplizierter! Es ist durchaus gut verwendbar, aber Folgendes ist zu beachten:

• Es handelt sich nach wie vor um eine wesentliche und relativ neue Ergänzung des Standards, weshalb sich die standardmäßige Unterstützung für Player und Monitoring noch in der Entwicklung befindet. Die common-media-library von SVTA unterstützt dies jedoch und wird aktiv weiterentwickelt, was bedeutet, dass Player-Bibliotheken wie hls.js und dash.js standardmäßig unterstützt werden.

• Der Ereignismodus kann möglicherweise viel mehr Daten und semantische Komplexität mit sich bringen, aus denen sich umsetzbare Erkenntnisse ableiten lassen. Möglicherweise müssen Sie Ihre Logging- und Datenpipelines überdenken, Sampling in Betracht ziehen, falls Sie dies nicht bereits tun, oder zumindest sorgfältig abwägen, welche Ereignisse Sie erfassen.

• Wenn Sie den Ereignismodus verwenden und Metriken direkt an einen Erfassungsendpunkt eines Drittanbieters gesendet werden, werden Ihre Metriken eher von Adblockern abgefangen, was Ihre Daten verfälschen oder Lücken darin hinterlassen könnte.

Wenn Sie sich vor dem Committen einen besseren Eindruck davon verschaffen möchten, sehen Sie sich diese Demoseite an, die wir zusammengestellt haben, um die Arten von Ereignissen im Ereignismodus zu zeigen, die während einer Wiedergabesitzung ausgelöst werden. 

Sind Sie bereit, CMCDv2 in Ihren Streaming-Stack zu integrieren? Der Ereignismodus bedeutet, bei der Erfassung selektiv vorzugehen, und wirft zudem neue Fragen dazu auf, wo diese Daten landen und wie Sie sie weiterleiten. Nehmen Sie Kontakt mit unserem Team auf, um Unterstützung bei der Planung von Logging, Beacon Termination und Multi-CDN-Normalisierung für Ihr Setup zu erhalten.