Multi-DRM
Multi-DRM is protecting the same video with several DRM systems, usually Widevine, FairPlay and PlayReady, so it plays securely on almost every phone, browser and TV. No single DRM system runs everywhere, so each device uses the one it supports. With common encryption (CENC), one set of encrypted files can serve all three systems. Each system still has its own license server, so a shared entitlement service decides who may watch and each license server delivers the same key in its own format.
Why is multi-DRM needed?
DRM is built into devices, not added by the app. Apple ships FairPlay in Safari, iOS and tvOS. Google ships Widevine in Chrome, Firefox and Android. Microsoft ships PlayReady in Edge, Windows and Xbox, and many smart TVs carry Widevine, PlayReady or both, depending on the model. A player cannot install a different DRM system on a device, so it must use the one that is already there.
That means any service with paying viewers on more than one kind of screen needs more than one DRM system. An OTT app reaching iPhones, Android phones, laptops and living room TVs needs all three. A mobile-only microdrama app may get by with FairPlay and Widevine. Studio and league contracts usually list the devices a title may play on and the protection required on each, which turns the device list into the DRM list.
How does multi-DRM work with one set of encrypted files?
Common encryption, defined in the CENC standard, separates encryption from the DRM system. The video is encrypted once with a content key, and the files carry signalling for every DRM system that can deliver that key: PSSH boxes, small headers each DRM reads, plus ContentProtection elements in DASH manifests and key tags in HLS playlists.
CENC has two encryption modes. The older cenc mode encrypts with AES-CTR. The cbcs mode encrypts with AES-CBC in a repeating pattern, and FairPlay requires it. For video, Apple's HLS authoring specification sets a 1:9 pattern: one 16-byte block encrypted, nine left clear, repeating. Current Widevine clients and PlayReady 4.0 and later accept cbcs too, so packaging once as CMAF in cbcs mode lets the same segments serve HLS, DASH and all three DRM systems. Older smart TVs and set-top boxes often accept only cenc mode, so a service that must reach them still stores and caches a second encrypted copy of every rendition.
What does a multi-DRM setup include?
A working multi-DRM stack has five parts, and each one is a place where playback can fail. The license servers are the most visible, but the entitlement service is where rules such as rental windows, device limits or offline rights must stay the same across all three systems, so a rental does not expire on Android a day before it expires on iPhone.
- A packager that encrypts once and writes signalling for each DRM system.
- A key service that stores content keys and rotates them for live streams.
- License servers for Widevine, FairPlay and PlayReady; FairPlay also needs credentials issued by Apple.
- An entitlement service that issues the token each license request carries.
- Players that drive EME in browsers, AVFoundation on Apple devices and MediaDrm on Android.
What commonly breaks in multi-DRM playback?
Most multi-DRM failures happen on one device class, not everywhere. A smart TV model with an old CDM, a browser that only offers a software security level, or a Safari version that rejects a license format will fail while every other screen plays. Rights rules make this sharper: a title licensed for 4K only on hardware-backed DRM will drop to a lower rendition, or fail, on devices that cannot meet that level.
License latency is the quiet problem. The license request sits between pressing play and the first frame, so a slow license server adds to startup time on every protected view. Live streams add key rotation, where the key changes during the broadcast and the player must fetch new licenses without a stall.
To the viewer, all of these look like a generic error. Recording the DRM system, device and OS on every view is what lets an engineer tell a license failure from a CDN problem.
How does FastPix handle multi-DRM?
On FastPix, DRM sits on the same API and the same bill as the encoder, storage, CDN and player, so protected playback is not stitched together from separate vendors. The DRM API supports Widevine, FairPlay and PlayReady.
The FastPix Player plays DRM streams through native SDKs for web, Android (built on Media3, including Android TV), iOS (built on AVPlayer, including tvOS) and Flutter, and the web SDK also reaches Samsung Tizen and LG webOS. A single playback ID serves every build, and each device asks for a license from the DRM system built into it. Titles that do not need DRM can run on JWT-signed playback IDs with an expiry instead.
Video Data records the DRM type on every view across 56 dimensions, so errors and startup failures can be broken down by DRM type, device model, OS, browser and player version. When one TV model or one Safari version fails on protected playback, it shows up as its own row rather than hiding inside an overall error rate. Alerts on error rate can be routed to PagerDuty, Slack or Opsgenie.
DRM is billed as a monthly platform fee plus a fee per license issued: VOD DRM is $99 a month plus $0.004 per license, and live DRM is $100 a month plus $0.006 per license. Start on the free plan, play a test title on an iPhone, an Android phone and a target TV, then turn on DRM.
By the numbers
- Apple's HLS authoring specification requires video encrypted with common encryption to use a 1:9 encrypt:skip pattern, meaning 10 percent partial encryption. (Apple Developer: HLS Authoring Specification for Apple Devices)
- Google states that Widevine uses industry standards including common encryption (CENC). (Google Widevine)
