Operator-facing
Streamwake + CMCD

Streamwake + CMCD.
What the player SDK emits on every segment request — captured, classified.

Compatibility: Unverified

Verification evidence

  • Public capability claim

    The public CMCD page states the player-side signal capability Streamwake describes.

    Basis
    The page presents this statement as a public claim, separate from implementation and test evidence.
    Scope
    Public capability claim on /integrations/cmcd.
    Reference
    /integrations/cmcd
  • Source-inspected implementation

    The CMCD detail page includes a checked-out server-rendered field reference and source setup islands.

    Basis
    The checked-out CMCD page and its composed source islands were inspected for this surface.
    Scope
    Static source implementation represented by the public CMCD detail page.
    Reference
    src/app/(custom)/integrations/cmcd/page.tsx

CMCD is the CTA-5004-B signal bus the player SDK emits on every segment fetch: rendition, buffer length, startup time, status, session metadata. Streamwake captures four key families —CMCD-Object (asset / rendition metadata),CMCD-Request (segment-fetch context),CMCD-Status (response characteristics) and CMCD-Session (viewer session envelope) — and pairs them against the Bitmovin + Conviva + MediaTailor + CloudFront correlation surface the adjacent +X pages already name.

To enable, turn on the player SDK's CMCD reporting layer, point it at the Streamwake inbound at /api/cmcd/inbound, then load a sample asset. The status indicator below flips from Awaiting first sample to Configured · live the moment the player emits its first segment-side query, and the feed table beneath populates with captured time, sid, content type, rendition, buffer, startup, TTFB, and family values derived from the CMCD-Object + CMCD-Request families on the same sample.

CMCD is the player-side companion to the Bitmovin + Conviva viewer-side feedback loop the /integrations/conviva and /integrations/bitmovin pages describe. Both ride on the same player SDK, and on the same investigation timeline the merged panel reads.

Ingest standing state

Is the player SDK emitting,
and is the Streamwake ingest standing?

The status pill flips from Awaiting first sample to Configured · live the moment the player SDK emits its first segment-side CMCD query and Streamwake's typed ingest classifies the row. Polls /api/cmcd/status every 5 seconds.

Loading CMCD standing state…
Operator setup

Configure the source,
mint the router token, send a fixture.

Save the CMCD source card to mint a per-source routerToken, then copy the inbound URL into your player SDK's CMCD reporting layer (or click Send test fixture to seed deterministic rows tied to an incident). The recent- samples log beneath the webhook card lights the moment the first row lands.

Loading CMCD source…
CMCD webhook
Player-SDK push endpoint — the URL the player SDK POSTs CMCD samples to
Webhook not configured
No inbound push received yet

Save the CMCD source card above to mint the per-source routerToken. The player SDK appends it as ?token=<routerToken> on every CMCD push so the inbound route resolves your tenant.

Inbound URL
(empty)
Router token
(not configured)
Send test fixture

Seeds 4 deterministic CmcdEvidence rows (2 pre-incident low-buffer / low-bitrate, 2 post-recovery) tied to the selected incident, then runs the correlator. The viewerRecoveryStatus in the toast is the tri-state the correlations panel renders — viewer_confirmed only when post-incident rows show buffer > 4s AND bitrate > 800kbps.

Configure the source first — the inbound route resolves routerToken from that row.

Recent CMCD samples

0 shown

Loading…

Field reference — CMCD key families

Four families,
one chip per key the SDK emits.

The four-key-family posture CMCD's CTA-5004-B spec defines. Streamwake persists every key the SDK emits; the table below names the player-side field each key maps to and the dominant reason Streamwake's correlator surfaces that key.

cmcd_object

CMCD-Object

  • sidSession id — ties the request back to a viewer session envelope.
  • cidContent id — keys all four families to the same asset / manifest.
  • otObject type (v / a / s / m / i) — segment vs manifest vs init-segment.
  • dMedia-object playback duration in integer milliseconds; for a partial object, it describes that requested part.
  • stStream type (v / a / l / c) — VOD, live, low-latency, or chunked.
  • rtRequest type (h / i / s / o) — hit / init / segment / oob.
  • brEncoded bitrate (kbps) — top rendition the player is on for this object.
  • blBuffer length (s) — playback buffer at the moment of the request.
  • tblTop buffer length (s) — maximum buffer reached in the session so far.
  • dlDeadline (ms) — segment deadline the player computed.
cmcd_request

CMCD-Request

  • ttfbTime-to-first-byte (ms) — CDN edge round-trip on the segment fetch.
  • tsTimestamp of the segment request — paired with status-side st / rt.
  • rlRequested throughput (kbps) — minimum the player needs to keep up.
  • bsBuffer starvation (boolean) — `b=true` if the buffer was empty on this fetch.
  • mtpMeasured throughput (kbps) — last-window estimate the player observed.
cmcd_status

CMCD-Status

  • stStatus code — paired against the CMCD-Request `ts` for the same fetch.
  • rtResponse time (ms) — wall-clock total the CDN took to serve the segment.
  • ttfbServer-side TTFB (ms) — measured at the CDN, not at the player.
  • bsBuffer starvation flag from the player — propagated onto the server trace.
cmcd_session

CMCD-Session

  • sidSession id — keyed against CMCD-Object / CMCD-Request / CMCD-Status `sid`.
  • stStream type — pinned once per session, surfaces any mid-session stream-type flip.
  • sfStream format (h / d / o) — HLS / DASH / progressive.
  • sbStream bandwidth-class hint — coarse player SDK class.
  • rttRound-trip time (ms) — player-side network estimate.
`sid` + `cid` join CMCD-Object ↔ CMCD-Request ↔ CMCD-Status ↔ CMCD-Session

The session id (sid) and content id ( cid) keys are the join columns the CTA-5004-B spec requires to be stable per session / per asset — they are how Streamwake's correlator pairs a CMCD-Request rendition-step against the CMCD-Status response-time the same fetch saw against the CMCD-Object asset the rendition belongs to.

How it's wired

Wire the player SDK,
light the feed beneath.

The wire sequence an operator runs to attach CMCD to Streamwake as a player-side, segment-scoped streaming-domain source. No vendor-side SDK to install, no shared API key — the connection is a single SDK toggled reporting URL plus the typed classification pass Streamwake already runs.

  1. 1

    Enable CMCD on the player SDK

    In your player SDK (Shaka / hls.js / ExoPlayer / AVPlayer / Dash.js), enable the CMCD reporting layer and set the CMCD mode to “full” rather than “key-only” so Streamwake captures the complete CTA-5004-B key set on every segment request — not just the rendition / startup keys.

  2. 2

    Point the CMCD reporting URL at the Streamwake inbound

    Set the SDK’s `cmcd-reporting-url` (Shaka) or `cmcd.url` (hls.js) property to `https://<your-streamwake-host>/api/cmcd/inbound`. In CTA-5004-B query mode, each media request carries the case-sensitive `CMCD` query argument containing a URL-encoded concatenation of CMCD key/value pairs; successive pairs are comma-delimited before URL encoding, for example `CMCD=d%3D4000%2Cbr%3D2500%2Cbl%3D8`. Streamwake’s normalized ingest envelope is a separate app-specific bridge used by the verification player.

  3. 3

    Pair CMCD against the bitrate ladder + session-id the player SDK emits

    CMCD-Request rides on every segment fetch; CMCD-Object rides on the manifest fetch; CMCD-Session rides once per session. Configure the SDK to mint a stable `sid` (session id) + `cid` (content id) so the four families can be joined downstream on the same investigation frame Streamwake already pivots on.

  4. 4

    Mount the streaming-domain classification pass

    Streamwake’s typed correlator surfaces the four CMCD families against the Bitmovin + Conviva + MediaTailor + CloudFront + CloudWatch pairing the adjacent /integrations pages name. Each ingested CMCD row is classified into one of the streaming-native shapes (player_side_buffering / player_side_startup_regression / player_side_bitrate_step_down / player_side_ttfb_spike / player_side_session_quality).

  5. 5

    Verify the first sample lands

    Open the player SDK on a sample asset and load the manifest. The first segment-side CMCD row arrives on the feed island below within seconds. The status indicator flips from “Awaiting first sample” to “Configured · live”, and the table beneath it populates with sid / cid / rendition / buffer / startup / TTFB columns derived from the CMCD-Object / CMCD-Request families on the same sample.

Read-only on the operator side

CMCD is what the player emits — Streamwake does not call the SDK, does not require a vendor-side API key, does not echo CMCD rows back to a third party. The player SDK's reporting endpoint is the only integration surface, and it's an outbound HTTPS POST from the player.

Verify the loop in the browser

Once you've saved the source card above and minted a routerToken, open the verification player — a minimal hls.js instance with CMCD enabled that POSTs the parsed envelope to /api/cmcd/inbound?token=<routerToken> on every segment request. The feed mirror on the same page surfaces the row landing live.

Recent CMCD samples

Real samples as they land,
honest empty state otherwise.

The recent-samples feed underneath the player SDK. Polls /api/cmcd/feed?limit=20 every 5 seconds; renders the seven columns the four CMCD families collapse to (sid / cid / top rendition / buffer length / startup delay / TTFB / family) with an honest Awaiting first sample state until the player SDK emits its first segment-side CMCD query.

recent cmcd samples
Polling /api/cmcd/feed every 5s…
Data ownership

Every row on the feed is keyed on the signed-in operator's userId, with no cross-tenant leak. The typed contract parsers (CmcdEvidenceRow / CmcdStatus) guarantee the API route, the typed business stub, and the seven-column table on the page share one shape — schema drift surfaces at the boundary, not in the render.

What populates it: the next time a player SDK with CMCD enabled loads a segment of yours, the CMCD-Request sid + br + ttfb fields land as the row's primary columns; the CMCD-Object accompanying keys fill in cid + ot + d; the d value is the media-object playback duration in integer milliseconds, including the requested part when the object is partial. The feed is per-tenant cached for the duration of the session — not across requests.

See the loop run

Run the Free Stream Check,
catch CMCD samples in flight.

Paste a playback URL into /stream-check — five checks in under a minute, no login. Pair it with the Book-a-demo block below for a guided walkthrough of the player SDK's CMCD reporting toggle, the /api/cmcd/inbound URL pattern, and the typed streaming-domain classification pass Streamwake runs against the four CMCD key families.

Run the Free Stream CheckBook a demo
Talk to engineering

Book a 20-minute walkthrough on your player SDK's CMCD layer.

We're happy to walk through which player SDK to use for end-to-end CMCD capture, the four-family joint on sid + cid, the typed streaming-domain classification Streamwake adds on top, and the bitrate-step-down / TTFB-spike / buffer-starvation shapes the correlator surfaces against the Bitmovin + Conviva + CloudFront pairing the adjacent +X pages already name. Drop your details below and we'll follow up within 1 business day.