Verify the CMCD loop — in the browser, end-to-end.
Verification evidence
- Public capability claim
The public page describes the planned browser verification capability for the CMCD loop.
- Basis
- The page labels this surface as operator verification and describes its intended browser flow.
- Scope
- Public capability claim on /integrations/cmcd/player.
- Reference
- /integrations/cmcd/player
A minimal hls.js player with CMCD enabled loads a public HLS test asset, exercises CTA-5004-B query-mode CMCD on its media requests, and POSTs a separate normalized JSON bridge envelope to /api/cmcd/inbound?token=<routerToken> (throttled to 1 push / 2s). The feed mirror below polls /api/cmcd/feed every 5s so you watch the row land on the same surface the public /integrations/cmcd page renders.
The loop the player page exercises separates the wire format from the app bridge: hls.js enables CTA-5004-B query-mode CMCD in full mode on media requests, while the browser island POSTs a normalized JSON envelope to /api/cmcd/inbound?token=<routerToken>. That JSON bridge is Streamwake-specific, not the CMCD query encoding. The typed ingest classifies the row into one of the four CMCD families the investigation timeline reads. The correlations panel on /app/incidents/[id] surfaces the viewerRecoveryStatus badge the moment a post-incident bucket shows buffer > 4s AND bitrate > 800kbps — never claiming viewer recovery on infrastructure-only signals.