Confidentiality note: this case study is intentionally anonymized. It omits the client name, service URL, names of commercial products, and any functional detail covered by the contractor’s NDA. It describes only the approach, methodology, and engineering takeaways.
Context
The client runs a Polish video platform operating in a hybrid model — live streaming combined with VOD, available both as a subscription and through open access. The platform is built on a popular CMS extended with dedicated plugins.
The engagement had three goals:
- replace the existing web video player with a modern one supporting adaptive streaming (HLS, MPEG-DASH)
- make the playback layer independent of CMS and template updates — so routine plugin / template upgrades do not require touching the player
- prepare the player for DRM and wire it into a commercial key-management system (KMS)
Work was structured in two stages:
- Stage 1 — playback layer, CMS integration, cross-device testing
- Stage 2 — end-to-end DRM configuration
Engineering challenges
1. Independence from the CMS layer
"Code independent of updates" sounds trivial as a requirement but in practice meant designing the player as a standalone, injected JS/CSS module that talks to the CMS only through a defined contract — DOM element IDs plus a minimal data layer — never through plugin hooks. The goal: survive template refactors and automatic plugin updates untouched.
2. Fitting one player to many content sources
The player had to uniformly handle:
- static files (MP4 and similar)
- adaptive HLS and MPEG-DASH streams
- multiple audio tracks (file and stream)
- multiple resolutions / ABR
- subtitles (sidecar + in-manifest)
- a graphic watermark (logo overlay)
- a full cross-browser matrix: Chrome / Firefox / Edge / Safari × Windows / macOS / Android / iOS × smart TV / smartphone / tablet / desktop
The real trap wasn’t functionality — it was the differences in EME (Encrypted Media Extensions) and codec support between browsers, particularly iOS/Safari vs. Chromium-based engines.
3. External KMS integration and provider migrations
The central thread of stage 2. During the engagement the KMS provider was swapped several times on the client side — each one came with a different license tokenization model, different CPIX requirements, different parameter formats in the license request headers, and different expectations around ticket-auth. Every DRM provider change forced:
- reconfiguring the license proxy that sits between the player and the KMS
- re-mapping asset identifiers to DRM keys
- rebuilding the license-request authentication layer
- re-testing the Widevine and PlayReady flows (and, in the agreed scope, FairPlay for Safari/iOS)
4. External blocker outside the contractor’s control
The biggest practical problem in stage 2 turned out to be an infrastructure blocker on the client side: the DRM module used in the client’s streaming stack did not support the ticket-auth mechanism required by the chosen KMS, and the third-party vendor’s technical support failed to deliver a fix for several weeks. Everything deliverable on my side (DRM proxy, KMS configuration, player DRM setup, API tests) was ready; end-to-end integration was halted for reasons outside the contractor’s control.
5. Out-of-scope work absorbed into the engagement
Along the way, additional items landed outside the original scope: image scaling
fixes (object-fit), overlapping z-index layers at menu level, a login
popup, role-based playback blocking for restricted content, dynamic subscription
package descriptions, and a CTA routing users to access purchase. These were
delivered as goodwill, not billed on top of the fixed fee.
Approach
- Player built on a mature open-source JS library with native MSE/EME, HLS, and MPEG-DASH support — which meant full control over the license flow and no vendor lock-in on the playback layer itself.
- License proxy layer — a custom intermediary normalizing the differences between successive KMS providers. Migrating a provider did not touch the player; it required only a proxy reconfiguration.
- Separation of concerns between the CMS and the playback layer — the CMS delivered only content identifiers and metadata; all playback, token, and license logic lived outside of it.
- Cross-browser test matrix — systematic coverage of the main browser × OS × device combinations, with a separate test track for Apple devices (FairPlay).
- Change documentation — every KMS provider swap was captured in a dedicated summary, which made it possible to quickly restore context after any break in the work.
Lessons for similar projects
- The DRM provider must be locked down before integration work begins. Changing provider mid-project is equivalent to partially rewriting the license layer — not a "small configuration tweak."
- Streaming-server compatibility with the chosen KMS must be verified empirically, not on the basis of a marketing compatibility matrix. License-token authentication in particular is often implemented in ways that de facto rule out certain combinations.
- Invest in a license proxy from day one — even when starting with a single KMS. The cost of writing one is small, and on the first migration it saves weeks.
- Scope, acceptance criteria, and an escalation path for external blockers must be written down before the project starts. A project whose critical dependency (DRM plugin of the streaming server, vendor support response) lies outside the contractor’s control must define a mechanism for pausing work and shifting deadlines — otherwise the risk flows asymmetrically onto the contractor.
- A browser test matrix is not optional. A player that works flawlessly on Chrome/Windows can fail in three different places on Safari/iOS — from the codec, through EME behaviour, to WebKit-specific event-loop quirks.
Result
- The new web player fully replaced the previous solution while preserving CMS integration, and — thanks to the standalone module design — without requiring intervention after CMS / plugin updates.
- The DRM integration layer on the contractor side was prepared and tested; closing the end-to-end integration was blocked on the client’s external server infrastructure (vendor support, independent of the contractor).
- After the client later swapped the streaming layer for a different stack, the project is continuing under a separate, new scope of work.
Own write-up. Contains no information covered by the confidentiality clause toward the client.