DRM Providers

Overview

Protección multi-DRM en C21 Live Control con Widevine, PlayReady y FairPlay y empaquetado CENC y CBCS.

Qué es DRM en C21 Live Control

Digital Rights Management (DRM) protege el contenido premium cifrando el stream al empaquetar y controlando la reproducción mediante un servidor de licencias. C21 Live Control soporta un modelo multi-DRM: un único stream de contenido se cifra una vez y se sirve con tres familias de licencia para reproducirse en todos los principales ecosistemas de dispositivos.

Live Control no ejecuta el servidor de licencias en sí. Registra un DRM provider (el registro de catálogo de credenciales que apunta a un servicio multi-DRM upstream) y asocia ese proveedor a un Destination protegido. En el empaquetado, el encoder pide claves al endpoint SPEKE del proveedor, cifra los segmentos e inserta las URLs de licencia en el manifest.

Los tres sistemas DRM

SistemaCustodiado porAlcanza
WidevineGoogleChrome, Edge, Android, Chromecast, Android TV.
PlayReadyMicrosoftWindows, Edge (legacy), Xbox, muchas smart TVs y set-top boxes.
FairPlayAppleSafari, iOS, iPadOS, tvOS, macOS.

Un servicio premium que no proteja al menos estas tres familias no podrá reproducirse en una parte no trivial de los dispositivos.

Los valores se exponen en el enum DrmProvider.supported_systems. El array drm.systems de un Destination elige cuáles se anuncian en el manifest. La spec OpenAPI emite los valores de supported_systems en mayúsculas (WIDEVINE / FAIRPLAY / PLAYREADY); la UI y este documento usan el casing humano (Widevine, PlayReady, FairPlay) para legibilidad.

Modos de cifrado: CENC y CBCS

Common Encryption (CENC) es el estándar paraguas que permite que el mismo segmento cifrado lo descifren clientes Widevine, PlayReady o FairPlay con la licencia correcta. El enum Publishing.drm.encryption_mode expone dos valores: cenc (AES-CTR — el default histórico para DASH con Widevine y PlayReady) y cbcs (AES-CBC con cifrado por patrón basado en subsamples — requerido por FairPlay sobre HLS / CMAF).

encryption_mode lo deriva el servidor de los systems activos: si systems incluye FairPlay, el modo se fija a cbcs; en otro caso se fija a cenc. Los clientes pueden enviar el valor explícitamente al guardar; el servidor lo recalcula igualmente.

Si cada cliente puede manejar cbcs, puedes empaquetar una sola vez en cbcs y exponer el resultado por dos Destinations distintos — uno DASH/CMAF con systems = [Widevine, PlayReady] para Chrome / Android / Windows / Edge, y un Destination HLS / CMAF separado con systems = [FairPlay] para Safari / iOS / macOS. Combinar FairPlay con Widevine o PlayReady en el mismo Destination no está permitido.

Cómo encaja Live Control en el flujo

Las responsabilidades del producto son CRUD sobre DRM providers más la asociación inline de DRM a un Destination:

  • Registrar un DRM provider (addDrmProvider) — el registro de catálogo de credenciales que apunta al servicio multi-DRM upstream. Respaldado por el esquema DrmProvider; provider_type lo dirige el servidor (hoy AXINOM, EZDRM). La UI muestra los valores con casing humanizado (Axinom, EZDRM); el spec y la API esperan mayúsculas.
  • Validar un proveedor (validateDrmProvider) — viaje de ida y vuelta de credenciales contra el servicio upstream y expone el resultado en validation_status (UNKNOWN / VALID / INVALID).
  • Asociar el proveedor a un Destination mediante el bloque drm del Destination (active, provider_id, contentid, systems[], encryption_mode).

Todo lo que ocurre tras la URL de licencia del manifest es territorio del proveedor: gestión de certificados, entitlements por dispositivo y emisión de licencias.

FAQ

Copyright © 2026