Context
apps/e2e/suites/drm drives all seven sandbox DRM sources against a real Widevine CDM and asserts the invariant the robustness ladder exists for: every requested capability names a tier, and Chromium logs no "robustness level should be specified" warning. It is green 7/7 on the final head.
It cannot run in CI. The drmContext fixture borrows the CDM from a local Google Chrome install and runs headed, because a CDM will not provision otherwise; where Chrome is absent the suite skips itself rather than failing, and it sits outside test:all. So the strongest DRM check in the repo runs only when someone remembers to run it.
Separately, the suite asserts negotiation, not decode. A configuration can negotiate and still fail to produce frames — which is precisely the risk on platforms where a hardware rung is accepted.
Scope
- A CI runner that can provision a CDM, so the suite runs automatically rather than on request.
- A decode assertion — frames actually advancing — on at least one cbcs and one cenc source, so the suite proves playback rather than negotiation.
Acceptance criteria
- The real-Widevine suite runs on CI without a developer invoking it.
- At least one cbcs and one cenc source assert decode, not only that negotiation was stamped.
- A regression in the no-unstamped-capability invariant fails CI rather than waiting for someone to run
pnpm test:e2e:drm.
Notes
- The
drmContext fixture already records the four simpler launch shapes that reach ClearKey only, so a second DRM test inherits a working CDM instead of rediscovering it.
- The bundled-Chromium ClearKey e2e (
engine-clearkey.test.ts) already runs on every PR and does assert decode, against a checked-in cenc fixture — that covers the pipeline, not the ladder, since ClearKey negotiates no robustness tiers.
- Related but distinct: Android Chrome on real L1 hardware is the one manual cell still unverified, and is the only place the ladder's leading
HW_SECURE_ALL rung negotiates. A CDM-capable runner does not close it; an emulator has no hardware CDM by construction.
Context
apps/e2e/suites/drmdrives all seven sandbox DRM sources against a real Widevine CDM and asserts the invariant the robustness ladder exists for: every requested capability names a tier, and Chromium logs no "robustness level should be specified" warning. It is green 7/7 on the final head.It cannot run in CI. The
drmContextfixture borrows the CDM from a local Google Chrome install and runs headed, because a CDM will not provision otherwise; where Chrome is absent the suite skips itself rather than failing, and it sits outsidetest:all. So the strongest DRM check in the repo runs only when someone remembers to run it.Separately, the suite asserts negotiation, not decode. A configuration can negotiate and still fail to produce frames — which is precisely the risk on platforms where a hardware rung is accepted.
Scope
Acceptance criteria
pnpm test:e2e:drm.Notes
drmContextfixture already records the four simpler launch shapes that reach ClearKey only, so a second DRM test inherits a working CDM instead of rediscovering it.engine-clearkey.test.ts) already runs on every PR and does assert decode, against a checked-in cenc fixture — that covers the pipeline, not the ladder, since ClearKey negotiates no robustness tiers.HW_SECURE_ALLrung negotiates. A CDM-capable runner does not close it; an emulator has no hardware CDM by construction.