Streamwake + CMCD.
What the player SDK emits on every segment request — captured, classified.
CMCD is the CTA-5004 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 sid / cid / rendition / buffer / startup / TTFB / CSAT columns 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.
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.
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.
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.
(empty)(not configured)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 viewerRecoveryStatusin the toast is the tri-state the correlations panel renders — viewer_confirmed only when post-incident rows show buffer > 4s AND bitrate > 800kbps.
routerToken from that row.Recent CMCD samples
Loading…
Four families,
one chip per key the SDK emits.
The four-key-family posture CMCD's CTA-5004 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
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.dObject duration (s) — durability / TTL hint from the player.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
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
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.dDelivery duration (s) — server-side delivery window the CDN measured.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
sidSession id — keyed against CMCD-Object / CMCD-Request / CMCD-Status `sid`.stStream type — pinned once per session, surfaces any mid-session stream-type flip.dSession duration (s) — running tally the player maintains.sfStream format (h / d / o) — HLS / DASH / progressive.sbStream bandwidth-class hint — coarse player SDK class.cstCSAT — change-status token; v=1 → session flip; v=2 → session end.rttRound-trip time (ms) — player-side network estimate.
The session id (sid) and content id ( cid) keys are the join columns the CTA-5004 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.
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
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 key set on every segment request — not just the rendition / startup keys.
- 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`. The CMCD spec appends a base64-encoded JSON blob as a query parameter on every segment request; Streamwake parses it via the same type-safe zod envelope the contract exposes.
- 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
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
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.
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.
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.
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 / CSAT) with an honest Awaiting first sample state until the player SDK emits its first segment-side CMCD query.
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 + ttfbfields land as the row's primary columns; the CMCD-Object accompanying keys fill in cid + ot + d; the CMCD-Session cst token renders as the change-status column. The feed is per-tenant cached for the duration of the session — not across requests.
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.
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.