nor (Next Object Request) Key: This key has been upgraded to support an "inner list" based on RFC-9651 (Structured Fields). This allows a player to report multiple upcoming segments and their byte ranges in a single request, a massive improvement for startup efficiency compared to v1's single-object reporting. Also, nrr (Next Request Range) has been deprecated.

Bitrate Reporting: The specification now includes 8 distinct bitrate-related keys (such as tb - Top Encoded Bitrate, and lb - Lowest Encoded Bitrate) for much more detailed reporting.

Multi-Type Bitrate Support: A new inner list format with tokens (e.g., br=(500;v 320;a)) allows a single report to contain bitrate information for multiple media types (like video and audio) simultaneously. This solves a major limitation of v1 but is notably not backward-compatible.

The most significant change in v2 is the simplification and generalization of reporting. The separate State-Interval and Response modes have been merged into a single, unified "Event Mode". CMCD v2 now has just two modes:

• Request Mode: Unchanged from v1, used for sending data to the CDN on each object request.

• Event Mode: A flexible, generalized mode for sending data to any analytics endpoint, decoupled from the CDN

Furthermore, Event Mode supports multiple targets and event filtering, allowing a player to send, for example, only error events to a debugging platform and only ad events to an ad analytics server.

New Transmission Mode: CMCD Batch To handle the batching of events without introducing the complexity of a new JSON schema (which has been deferred to v3), v2 specifies a "CMCD Batch" transmission mode. This is a simple HTTP POST request with a content-type: “text/cmcd”, where the body contains multiple CMCD query strings separated by newline characters. The key advantage of this format is that it is streamable, allowing the player to send data chunks as they become available.

While the official CMCD v2 specification is exclusively focused on sending data from the client to the server, its new architecture—especially the Event Mode—opens the door for bidirectional communication. This concept, which is out of scope for the v2 spec but is a pattern enabled by it, can be thought of as a "Common Media Client Data Interface" or CMCDi.

Sending Custom Data from the Player (Client-to-Server)

The player can transmit custom information using two primary methods:

• Custom Keys (CMCD v1 & v2): This is the foundational method, supported since CMCD v1. Arbitrary custom keys can be appended to the CMCD data payload, allowing for flexible data transmission.

• Custom Events (CMCD v2): CMCD v2 introduces a standardized "Event Mode". To send a custom event, the player must:

  • Set the event key (ev) to ce (Custom Event).

  • Include a cen (Custom Event Name) key to define the specific event being reported.

Append any other relevant custom keys to provide context for that event.

Receiving Information from the Server (Server-to-Client)

While not officially part of the CMCD v2 specification, the presentation highlights two practical methods for a server to send data back to the player, leveraging existing player APIs that can intercept HTTP responses:

1. CMSD (Common Media Server Data) Headers: The server can include CMSD data within the HTTP response headers.

2. HTTP Response Body: When operating in "Event Mode," the server can return information in the body of the HTTP response.

This combined pattern (CMCD + CMSD / HTTP Body) enables powerful bidirectional communication, supporting use cases such as Content Steering (e.g., sending steering information in the response body) or synchronizing live players (e.g., sending wall clock time and latency targets).

CMCDi in action

An example of a CMCDi implementation can be found in the live sync open-source project

Client-Side & Tooling Implementations

To accelerate adoption, CMCD v2 draft implementations have been developed for several major open-source players. This work, supported by the Comcast Innovation Found, ensures that robust CMCD v2 capabilities are available to the community from an early stage.

Client-side support has been integrated into the following projects:

• Shaka Player

• dash.js

• a plugin for hls.js

• Common Media Library (CML)

Server-Side & Tooling Implementations

A CMCD Reference Toolkit is available as an open-source project to support server-side integration and analysis.

This toolkit provides reference tools to effectively collect and analyze CMCD v2 data. Its key features include:

• Examples for local environment setups.

• Examples for Google Cloud implementations.

• Pre-built Grafana dashboards for immediate data visualization.