During my various engineering roles in the video streaming industry, a frequent topic of conversation (or even commiseration) with my peers was duplication of effort and how much of our work was effectively building the same software as each other within our own company silos.
Recently that’s begun to change with some excellent work on opening up and standardising the most common pieces of the streaming puzzle. At Fastly, we’re particularly interested in those that involve the edge, such as distributed access control with Common Access Tokens and understanding how network performance is impacting viewer experience with Common Media Client Data.
With the recent release of Version 2 of the CMCD standard, we thought we’d take the chance to revisit what made Version 1 so successful and look at the possibilities that the new version opens up.
A Quick CMCD History Lesson
Version 1 of CMCD is an elegant solution to a common problem in streaming services: logs from video players could tell you when the user experienced buffering or quality drops and CDN logs could tell you when there are network or origin issues, but these two sets of logs often got aggregated in very different places and there was no easy way to correlate them, particularly across multiple different CDNs and playback devices. Playback issue debugging often ended up involving trying to correlate spikes and timestamps across different graphs.
Life Before CMCD: Player Logs and CDN Logs Living Separately
The two sets of logs would often live across different buckets or even storage providers
CMCDv1 standardised a set of key/value pairs that could be passed along inside an HTTP request for a manifest or media segment and then parsed and logged along with the rest of the CDN logging for that request. This means that we can now have a much more complete picture of user sessions across the entire stack and can even drill down into individual ones if needed.
The exact format is beyond the scope of this post, but the dash.js open-source project produced a great demo page, allowing you to see the events firing in real time while you watch a video of an unusually large rabbit.
This effectively gives us full-stack tracing across playback sessions - we now have a picture of what was going on in the player and on the server at any given point in time and can answer questions like:
Did increased origin latency lead to buffering or drops in playback quality?
Does buffer starvation vary by CDN POP?
Do certain players handle latency spikes better?
Is there varying performance by ASN?
It also allows you to provide hints to the CDN about which requests (either for segments or ranges of files) might come next and speed up subsequent requests through pre-fetching.
Because CMCD is an open and now widely adopted standard, you can plug in any popular video player and monitoring tool at either end and get instant observability.
Fastly is particularly well-suited to being the conduit in this architecture, since our ability to push real-time logging with any user-defined format and values into an array of different platforms means that for live streaming, operators can immediately react to and diagnose any issues that occur during their events.
To help you get started, we put together this example of parsing CMCD values in VCL.
What’s New in CMCDv2
Although it’s bundled under the same protocol, CMCDv2 is really an architectural leap to try and take the success of Request Mode to bring rich client-side telemetry into the picture.
Version 2 is fully backwards-compatible with the CDN request augmentation from the first version (which it now refers to as Request Mode), but adds two new modes: Response Mode and Event Mode. It also adds the ability to push directly from the client to third-party domains (e.g., to a SaaS metrics aggregator), rather than forcing these new modes to go via the same path as the video data.
In addition to adding the two new modes, it adds a bunch more key/value pairs to Request Mode, based on learnings from real-world deployments on CMCDv1.
There’s once again too much to cover in one blog post, but some of the new metrics we’re most excited about are:
Buffer Target Size: Allows your analytics to reason about buffer size versus what it ideally should be, rather than as an abstract number. This is important because different player implementations, devices and content types can aim for very different target buffer sizes.
Absolute / Relative Degradation Metrics: stalling for 3s once in a video is a very different user experience to stalling once every segment. Lots of the new metrics focus on being able to better differentiate between these types of cases
Sub-Content Differentiation: Switching from primary content to ad-breaks is a common time for playback issues to show up. CMCDv2 lets you differentiate between different content types and understand exactly where issues are occurring.
Response Mode
Response Mode acts as a rounding out of the data that’s passed with the media request in Request Mode. It runs after the client finishes receiving the chunk of video/audio data back from the CDN and allows the client to report data that it didn’t have at request time such as Time To First Body Byte, Time To Last Byte and HTTP Response Code.
While a lot of these fields would be available in the CDN logs, having them in the player and sending directly to an external endpoint could help in cases such as a multi-CDN setup, to avoid having to normalise and aggregate logs or where you might be dealing with CDNs that don’t offer real-time logging.
Event Mode
Event Mode is where the bulk of the new work has taken place and attempts to solve one of the main limitations of the original version, which is that it was bound to recording information along with media requests despite there being lots of relevant things (pausing, backgrounding, manual quality switching) that can happen asynchronously during a playback session. This new mode lets you not only capture these (and arbitrary user-defined) events, along with the exact moment they happen, rather than being tied to the timing of HTTP requests.
Traditionally, these events would be recorded in player-defined metrics. But those metrics would be uniquely named and parameterised depending on which player you were using and wouldn’t be easily connectable with your CDN metrics. If you followed along with the motivations for CMCDv1 then this should be starting to sound very familiar!
If you’d like to try this new mode but have concerns about the number of new events hitting your origin or spinning up a new data pipeline to ingest them then Fastly’s Beacon Termination is a great option to absorb the new load, filter and forward events on to whichever third-party data tooling you use.
So should I start using CMCDv2?
That’s a little more complicated! It’s very much usable, but things to bear in mind are:
It’s still a major and relatively new addition to the standard and so out-of-the-box player and monitoring support is still developing. SVTA’s common-media-library supports it and is being actively iterated on though, which means that player libraries like hls.js and dash.js get support by default.
“Event Mode” potentially adds a lot more data and semantic complexity to try and derive actionable meaning from. You might have to rethink your logging and data pipelines, consider sampling if you weren’t already or at least be judicious with which events you capture.
When using Event Mode with metrics going directly into a third-party collection endpoint, your metrics are more likely to be caught by adblockers, which might skew or leave holes in your data.
If you’d like to get a better feel for it before committing then take a look at this demo page we’ve put together to show the types of Event Mode events that are fired during a playback session.
Ready to bring CMCDv2 into your streaming stack? Event mode means being selective about what you capture, plus new questions about where that data lands and how you route it. Get in touch with our team for help as you think through logging, beacon termination, and multi-CDN normalization for your setup.