DRM systems

Widevine, PlayReady, FairPlay and WisePlay do the same job for different manufacturers. These are the differences that will affect you.

Why you need more than one #

No DRM system works on every device, and it is not a technical problem waiting to be solved: each one belongs to a manufacturer who ships it in their own hardware and software. Apple does not put Widevine on an iPhone, and Google does not put FairPlay on Android.

Reaching everyone means encrypting the content so that several systems can open it, each with its own license. That is what the Common Encryption standard is for: one encrypted file, several protection headers, one per system.

Three of them cover almost everything

Widevine, PlayReady and FairPlay together reach nearly any screen in Western markets. WisePlay is only needed if you target the Huawei ecosystem.

In Airi that is the drmSystems list when you create a key. Each system you add produces its own protection data; the encryption key itself is shared.

At a glance #

	Widevine	PlayReady	FairPlay	WisePlay
Vendor	Google	Microsoft	Apple	Huawei
Where it plays	Android, Chrome, Firefox, Edge, Android TV, Chromecast, many TVs	Windows, Xbox, Edge, Samsung and LG TVs, set-top boxes	iPhone, iPad, Mac (Safari), Apple TV	Huawei and HarmonyOS devices
Streaming format	DASH and HLS	DASH and HLS	HLS only	DASH and HLS
Encryption schemes	`cenc` and `cbcs`	`cenc` and `cbcs` (since PlayReady 4)	`cbcs` only	`cenc` and `cbcs`
Signalling	`pssh` box	`pssh` box + protection header	`EXT-X-KEY` with a `skd://` URI — no pssh	`pssh` box
Security levels	L1 / L2 / L3	SL150 / SL2000 / SL3000	No named levels	Levels 1 to 3
HDCP control	Yes	Yes	Different (see below)	Yes

The encryption-scheme row causes the most trouble

FairPlay only understands cbcs. Package in cenc for Widevine and PlayReady and Apple devices will not play your content, whatever you do with licenses. See Encryption schemes.

Widevine #

Vendor: Google
System ID: edef8ba9-79d6-4ace-a3c8-27dcd51d21ed
In Airi: "widevine"

The widest reach: Android, Chromium-based desktop browsers, Firefox, most connected TVs and Chromecast. If you are only enabling one to start with, enable this.

L1, L2 and L3

Widevine grades devices by how much of the process happens inside a secure hardware environment (a TEE), out of reach of the operating system:

L1 — decryption and video decoding both happen inside secure hardware. This is what studios require for 4K and often for 1080p.
L2 — decryption in secure hardware, decoding outside it. Rare in practice.
L3 — everything in software. The device has no secure hardware, or does not expose it. This covers nearly every desktop browser.

Chrome on a computer is L3

This is the number one cause of “it does not work in the browser”. Demand hardware and you exclude the entire desktop. That is why our Strict level says so, and why 1080p and below are better served with more permissive rules.

What you configure in Airi

The policy field security_level runs from 1 to 5 and expresses what the device must satisfy to receive a license. It is not the same thing as the L1/L2/L3 label, although they roughly correspond:

`security_level`	What it demands	Roughly equivalent to
1	Software crypto	L3 — any device
2	Software crypto with the key protected
3	Crypto inside secure hardware	L1 territory
4	Plus decoding in secure hardware
5	The whole chain in hardware, through to video output	Strict L1

HDCP

HDCP protects the cable between device and screen, so the signal cannot be recorded with a capture card. It is set with hdcp:

HDCP_NONE — no requirement. What lets old monitors and virtual machines play.
HDCP_V1 — basic protection; almost any modern screen satisfies it.
HDCP_V2_2 — the usual bar for 4K. Rules out a fair number of pre-2015 TVs and adapters.
HDCP_NO_DIGITAL_OUTPUT — forbids any digital output. Built-in screen only.

You can also cut analogue output with disable_analog_output, and control license and offline playback lifetimes with license_duration_seconds, playback_duration_seconds and can_persist.

PlayReady #

Vendor: Microsoft
System ID: 9a04f079-9840-4286-ab92-e65be0885f95
In Airi: "playready"

Covers the Microsoft world — Windows, Xbox, Edge — and, more importantly, a large share of connected TVs and operator set-top boxes. Many Samsung and LG TVs ship PlayReady alongside, or instead of, Widevine.

Security levels

Level	What it is	When to use it
`150`	Development and testing only. Offers no real protection.	Never in production.
`2000`	Software implementation. The most widespread level.	The norm for SD and HD.
`3000`	Secure hardware implementation.	For 4K and whenever a studio requires it.

SL150 protects nothing

It exists so developers can test without certified hardware. Content served at SL150 is, for practical purposes, unprotected. Our presets never use it.

One quirk

Besides the pssh box, PlayReady returns a protection header (protectionHeader) that some packagers need separately. You will find it in the drmSystemsData field of the response, next to the pssh.

Mind the type too: in PlayReady the security level is a string ("2000"), not a number. That is the system’s own vocabulary and we keep it verbatim, so you can match any provider trace against what you configured.

FairPlay Streaming #

Vendor: Apple
System ID: 94ce86fb-07ff-4f43-adb8-93d2fa968ca2
In Airi: "fairplay"

The only route to iPhone, iPad, Mac with Safari and Apple TV. Also the odd one out of the four: when something behaves strangely in an integration, it is usually FairPlay.

FairPlay returns no pssh, and that is not an error

The other three signal protection with a pssh box inside the video. FairPlay does not use that mechanism: signalling lives in the HLS manifest’s EXT-X-KEY tag, with a skd:// URI. That is why our response carries uriExtXKey instead of pssh. It is exactly what your packager expects.

Three constraints worth knowing up front

HLS only. FairPlay does not work over DASH. Publish DASH alone and Apple devices are out.
cbcs only. It does not accept cenc. This is the main reason cbcs is the recommended packaging today.
You need an Apple certificate. A FairPlay license server requires a certificate issued by Apple to your developer account. You request it from Apple Developer and your DRM provider configures it.

What you can configure

FairPlay has no numbered security levels like Widevine or PlayReady; its output protection model is handled by the operating system itself. What you do control is durations and persistence:

rental_duration_seconds — how long the license is worth from issuance.
playback_duration_seconds — how long the window lasts once playback starts.
persistence_is_allowed — whether downloading for offline viewing is permitted.
lease_duration — for lease-style licenses.

WisePlay #

Vendor: Huawei
System ID: 3d5e6d35-9b9a-41e8-b843-dd3c6e72c42c
In Airi: "wiseplay"

Huawei’s system, present on their HMS phones, on HarmonyOS and on their TVs. It matters mainly in the Chinese market and wherever Huawei devices carry weight, because those devices ship without Google services and therefore without Widevine.

If your audience is in Europe or the Americas you very likely do not need it. Enable it only when you know you do: adding a system costs no extra money — pricing is per key, not per system — but it is one more moving part to maintain and debug.

It is configured with security_level (1 to 3), license_type (ONLINE or PERSISTENT) and license_duration_seconds. Internally it works with absolute begin and expiry dates, which we compute for you from the duration.

Encryption schemes: cenc and cbcs #

This is the technical decision that costs the most to get wrong, because changing it means re-encrypting the whole catalogue.

Common Encryption defines two ways of encrypting the same video bytes:

	`cenc`	`cbcs`
How it encrypts	AES in CTR mode, the full sample	AES in CBC mode, in patterns (one block in every ten)
Widevine	Yes	Yes
PlayReady	Yes	Since PlayReady 4
FairPlay	No	Yes
WisePlay	Yes	Yes

A cenc-encrypted file cannot be opened by FairPlay

It is not a licensing or configuration matter: the bytes are encrypted in a way the Apple device cannot decrypt. The only way out is repackaging in cbcs, or keeping two encrypted copies of the catalogue.

PlayReady in a browser usually accepts `cenc` only

That a system *can* do cbcs does not mean the client in front of you does. Measured on Edge on Windows: EME accepts robustness 3000, and the client still does not support cbcs. The server issues the correct licence, the player receives it, and cannot decrypt. Check your own machine on the demo. And there is a bigger trap underneath: Windows has two PlayReady clients, not one, and the key system name decides which one answers you. Plain com.microsoft.playready gets the software client, whose certificate reads SecurityLevel: 2000 however capable the machine is. The hardware client answers only when named: com.microsoft.playready.recommendation.3000. Measured on the same machine on the same day: through the first, the server refuses the SL3000 key; through the second, it grants it and 1080p plays. Ask for hardware with the software client and the refusal you get describes the messenger, not the device — and in Shaka the name is changed with drm.keySystemsMapping, not preferredKeySystems.

And a second reason, which has nothing to do with the browser

The protection header the provider issues for PlayReady always declares ALGID=AESCTR — CTR mode — even when the content is packaged in cbcs, which is CBC. We asked for it every way there is and it does not change. A PlayReady client that *could* read cbcs would still be handed a header telling it the video is CTR. If you need PlayReady, package in cenc: it is not only an Edge limitation, it is also the only thing the header can describe.

Which to choose

It depends on whether you need PlayReady and Apple at the same time, and the honest answer is that one set of files does not always cover both.

Your case	What to package
Web and Android, no Apple or PlayReady	`cbcs` or `cenc`, either. Widevine does both.
You need Apple	`cbcs`, required for the HLS that serves FairPlay.
You need PlayReady in a browser	`cenc`, because many Edge clients cannot read `cbcs`.
You need both	Two packagings: DASH in `cenc` for Widevine and PlayReady, HLS in `cbcs` for FairPlay. This is what the large services do.

The keys are the same across both packagings: you request once and encrypt twice. What doubles is storage, not the cost of keys or licences.

The choice does not go through Airi

You pick the scheme in your packager, not when requesting a key: the same key serves both. We neither see nor constrain that step.

Choosing for your case #

An ordinary catalogue, Western audience

Widevine, PlayReady and FairPlay, packaged in cbcs. Balanced for 1080p and below, Strict only if you serve 4K or a studio requires it.

Web only, no Apple

Widevine and PlayReady are enough. Bear in mind that reaching Safari or iPhone later would mean repackaging, so choosing cbcs now is a cheap precaution.

Studio-licensed content

The contract decides: it usually requires hardware for 4K and sometimes for 1080p. Set one key per quality and apply the level they ask for to each — this is exactly the case per-quality keys exist for.

Chinese market or Huawei devices

Add WisePlay to the three above. Recent Huawei hardware has no Widevine.