Overview

What DRM is in C21 Live Control

Digital Rights Management (DRM) protects premium content by encrypting the stream at packaging time and gating playback through a license server. C21 Live Control supports a multi-DRM model: a single content stream is encrypted once and served with three license families so it plays on every major device ecosystem.

Live Control does not run the license server itself. It registers a DRM provider (the credentials catalogue entry pointing at an upstream multi-DRM service) and attaches that provider to a protected Destination. At packaging time the encoder requests keys from the provider's SPEKE endpoint, encrypts the segments and inserts the license URLs into the manifest.

The three DRM systems

A premium service that does not protect at least these three families will leak playback on a non-trivial share of devices.

The values are exposed by the DrmProvider.supported_systems enum. A Destination's drm.systems array picks which of these are advertised on the manifest. The OpenAPI spec emits the supported_systems values in UPPERCASE (WIDEVINE / FAIRPLAY / PLAYREADY); the UI and this doc use the human casing (Widevine, PlayReady, FairPlay) for readability.

Encryption modes: CENC and CBCS

Common Encryption (CENC) is the umbrella standard that lets the same encrypted segment be decrypted by Widevine, PlayReady or FairPlay clients with the right license. The Publishing.drm.encryption_mode enum exposes two values: cenc (AES-CTR — the historical default for DASH with Widevine and PlayReady) and cbcs (AES-CBC with subsample-based pattern encryption — required by FairPlay over HLS / CMAF).

encryption_mode is chosen per Destination. cenc carries Widevine and PlayReady; cbcs carries all three. When the request omits it, the server derives it — any FairPlay member gives cbcs, otherwise cenc. On update, omitting it keeps the Destination's current mode.

A single CMAF Destination set to cbcs can carry Widevine, PlayReady and FairPlay together: one packaging — one set of segments — serves every player through the DASH and HLS manifests. The trade-off is that devices that only support CENC (mainly PlayReady 2.0 televisions) cannot play cbcs; if your audience includes them, keep a separate cenc Destination for Widevine and PlayReady. Through the API, the three-system combination is accepted only when encryption_mode: cbcs is sent explicitly; FairPlay with cenc is always refused.

How Live Control fits in the workflow

The product's responsibilities are CRUD on DRM providers plus inline attachment of DRM to a Destination:

• Register a DRM provider (addDrmProvider) — the credentials catalogue entry pointing at an upstream multi-DRM service. Backed by the DrmProvider schema; provider_type is server-driven (today AXINOM, EZDRM). The UI shows these values with human casing (Axinom, EZDRM); the spec and API expect uppercase.
• Validate a provider (validateDrmProvider) — round-trip credentials against the upstream service and surface the result in validation_status (UNKNOWN / VALID / INVALID).
• Attach the provider to a Destination via the Destination's drm block (active, provider_id, contentid, systems[], encryption_mode).

Everything past the manifest's license URL is the provider's territory: certificate management, device entitlements and license issuance.

Cross-links

• Providers — DRM provider CRUD reference.
• Workflow — End-to-end operator flow.
• Widevine, PlayReady, FairPlay — Per-system notes for the registration form.

FAQ