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 server-derived from the active systems: if systems includes FairPlay, the mode is forced to cbcs; otherwise it is set to cenc. Clients may send the value explicitly on write; the server recomputes it either way.

If every client can handle cbcs, you can package once in cbcs and expose the result through two separate Destinations — one DASH/CMAF with systems = [Widevine, PlayReady] for Chrome / Android / Windows / Edge, and a separate HLS / CMAF Destination with systems = [FairPlay] for Safari / iOS / macOS. Combining FairPlay with Widevine or PlayReady on the same Destination is not permitted.

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