Generic DRM playback layer for Emby clients (EME/Widevine, FairPlay, PlayReady) + DRM metadata in the Playback

[Meeko 35]

Quote

Emby clients can currently only play unencrypted media. I would like to request a **generic, provider-agnostic DRM playback layer**, conceptually similar to Kodi's InputStream Adaptive: the server (or a server plugin) describes *that* a stream is protected and *where* the license server lives, and each client hands the encrypted stream to the **DRM stack its platform already ships with**. No decryption keys ever touch Emby code - the platform CDM does all the work, exactly as the DRM vendors intend.

This is explicitly **not** a request to circumvent or strip DRM. It is a request to *play protected content the official way*, which every modern browser, every Android device and every Apple device already supports natively. Emby just doesn't pass the necessary information through.

## Motivation / Use cases

There is a growing class of **legitimate** sources that Emby currently cannot integrate at all, purely because the last mile (playback) is missing:

1. **Broadcaster catch-up services and public mediatheques.** Several European public and private broadcasters serve their catch-up catalogs as standard MPEG-DASH with Widevine/PlayReady (and HLS+FairPlay for Apple). Their APIs are documented or trivially accessible, plugins could be written today - but the resulting streams are unplayable in Emby.
2. **Licensed IPTV / TV Everywhere providers.** Operators increasingly protect their live channels with DRM even for paying subscribers. A subscriber with valid credentials cannot bring those channels into their Emby Live TV setup, while the same person can watch them in any browser via EME.
3. **Corporate / education video platforms.** Internal video libraries protected with off-the-shelf DRM (e.g. via common packagers like Shaka Packager + a license service) cannot be fronted by Emby.
4. **Future-proofing Live TV.** DVB and OTT distribution is moving toward CENC-encrypted delivery. Without a DRM path, Emby's Live TV story slowly erodes.

In all four cases the user *has the rights* and *has working credentials*. The only missing piece is that Emby players never learned to say "this stream is encrypted, here is the license endpoint".

## Current state (as far as I can tell)

- `MediaSourceInfo` / the `PlaybackInfo` response has no notion of content protection. There is no field a server plugin could use to signal DRM to a client.
- The web client plays via HTML5 `<video>` + MSE but never initializes EME (`requestMediaKeySystemAccess`), although every supported browser ships a Widevine CDM.
- The Android/FireTV clients use ExoPlayer, which has **complete, mature Widevine support built in** (`MediaDrm` via `DefaultDrmSessionManager` / `MediaItem.DrmConfiguration`). Emby simply never configures it.
- iOS/tvOS use AVFoundation, which supports FairPlay Streaming via `AVContentKeySession`. Again unused.
- There is no way for a plugin to participate in a license exchange.

So the platforms can all do it - the capability exists on every single Emby client platform, provided by the OS/browser vendor. What is missing is plumbing, not cryptography.

## Proposed design

### 1. DRM metadata in the API

Extend `MediaSourceInfo` (and the LiveTV/channel equivalents) with an optional block, e.g.:

```json
"DrmInfo": {
  "Systems": [
    {
      "Scheme": "widevine",
      "LicenseServerUrl": "https://license.example.com/wv",
      "RequestHeaders": { "Authorization": "Bearer ..." },
      "ServerCertificateBase64": "...",
      "PsshBase64": "..."          // optional, if not in the manifest
    },
    {
      "Scheme": "fairplay",
      "LicenseServerUrl": "https://license.example.com/fps",
      "CertificateUrl": "https://license.example.com/fps/cert"
    }
  ],
  "LicenseThroughServer": true      // see section 3
}
```

Clients pick the first scheme their platform supports (Widevine on Android/web/most TVs, FairPlay on Apple platforms, PlayReady on Xbox/Windows/Tizen). A `SupportedDrmSystems` capability field in the client's device profile would let the server transcode-or-reject sensibly, mirroring how codec negotiation already works today.

### 2. Client implementation per platform

- **Web:** MSE + **EME**. This is the cheapest win. The established open-source players (Shaka Player, dash.js, hls.js + eme-controller) all implement the hard parts already and are Apache/BSD licensed. Even without swapping the player, wiring `navigator.requestMediaKeySystemAccess` + a license `fetch` into the existing playback path is a well-trodden road.
- **Android / Android TV / FireTV:** ExoPlayer `MediaItem.DrmConfiguration` (scheme UUID, license URL, headers). This is nearly configuration, not code - ExoPlayer handles provisioning, key rotation and renewal on its own.
- **iOS / tvOS:** `AVContentKeySession` with the FairPlay application certificate + SPC/CKC exchange against the license URL. More work than Android, but a standard, well-documented pattern.
- **Windows / Xbox / Samsung / LG:** EME as well (these clients are web-based), with PlayReady as the key system where Widevine is unavailable.

### 3. License proxying through the server (the plugin hook)

Many real-world license servers require provider-specific authentication: session tokens, signed requests, device registration. Clients should not need to know any of that. Proposal:

- New endpoint, e.g. `POST /Items/{id}/DrmLicense`, which forwards the raw license challenge to the license server and returns the response.
- Server plugins get a hook (analogous to existing `IServerEntryPoint`/HTTP handler patterns) to **enrich or wrap** that exchange: add auth headers, refresh tokens, unwrap provider-specific envelopes.
- Result: *all* provider logic lives in one server-side plugin; every client just POSTs opaque bytes. No client updates are ever needed for a new provider.

This mirrors exactly how Kodi splits the work between a Python addon (auth, manifests) and InputStream Adaptive (playback), and it is the piece that would make Emby's plugin ecosystem genuinely extensible here.

### 4. Manifest handling

For DASH this is mostly free (the PSSH lives in the manifest/init segments). For HLS, `EXT-X-KEY`/`EXT-X-SESSION-KEY` with `SAMPLE-AES` + FairPlay attributes need to be passed through untouched by any server-side proxying/remuxing. A "direct play only when DRM present" rule would be a sane v1 constraint (transcoding encrypted content is impossible by design anyway - which also keeps this feature honest: the server never sees plaintext media).

## Prior art

- **Kodi InputStream Adaptive**: exactly this split (generic client-side DRM layer + per-provider addons), proven for years.
- **Shaka Player / dash.js / hls.js**: production-grade EME implementations, permissively licensed.
- **ExoPlayer / AVContentKeySession**: first-party DRM stacks on the two biggest client platforms, already shipped inside Emby's own apps, just not wired up.

## What this request is NOT

- Not a request to decrypt, re-stream, or strip DRM from anything - the opposite: content stays encrypted end-to-end and is only ever decrypted inside the platform CDM, per the DRM vendors' own model.
- Not tied to any specific streaming service. Services that only certify their own first-party clients would remain out of reach regardless - that is their business decision and not solvable by Emby. The target is the long tail of standards-based, legitimately accessible DRM sources.

Happy to provide more technical detail, test streams (there are public Widevine/FairPlay demo endpoints, e.g. the Shaka and Axinom demo assets), or help testing early builds.

 

Edited 42 minutes ago by Meeko

[Luke 42960]

Hi, what do you want to play with it?

[Meeko 35]

2 minutes ago, Luke said:

Hi, what do you want to play with it?

 

## Motivation / Use cases

There is a growing class of **legitimate** sources that Emby currently cannot integrate at all, purely because the last mile (playback) is missing:

1. **Broadcaster catch-up services and public mediatheques.** Several European public and private broadcasters serve their catch-up catalogs as standard MPEG-DASH with Widevine/PlayReady (and HLS+FairPlay for Apple). Their APIs are documented or trivially accessible, plugins could be written today - but the resulting streams are unplayable in Emby.
2. **Licensed IPTV / TV Everywhere providers.** Operators increasingly protect their live channels with DRM even for paying subscribers. A subscriber with valid credentials cannot bring those channels into their Emby Live TV setup, while the same person can watch them in any browser via EME.
3. **Corporate / education video platforms.** Internal video libraries protected with off-the-shelf DRM (e.g. via common packagers like Shaka Packager + a license service) cannot be fronted by Emby.
4. **Future-proofing Live TV.** DVB and OTT distribution is moving toward CENC-encrypted delivery. Without a DRM path, Emby's Live TV story slowly erodes.

In all four cases the user *has the rights* and *has working credentials*. The only missing piece is that Emby players never learned to say "this stream is encrypted, here is the license endpoint".