DRM packaging pipeline architecture

DRM packaging is the architecture that protects premium video — the layer that encrypts your content, manages keys across the three DRM majors (Widevine, FairPlay, PlayReady), and orchestrates license issuance to authenticated clients. It's the difference between "we host video" and "we host video that contractually obligates us to enforce viewing rights."

This document is the reference architecture for production DRM packaging on MpegFlow. Native DRM packaging ships in 2026 Q4. Until then, design partners pair MpegFlow with established license-server providers (Vualto, EZDRM, BuyDRM, Axinom) — the architecture below shows how the pieces fit together regardless of which license-server vendor you use.

#Use case in scope

You are running:

• Premium VOD with paid content — subscription streaming, transactional VOD, DTC services for premium catalog
• Broadcast post-production with contractual delivery requirements — studio masters, pre-release content, content with windowing or geo-restrictions
• Multi-platform delivery — web (Widevine), iOS/macOS (FairPlay), Android/smart TVs (Widevine), Microsoft devices (PlayReady), most platforms via CMAF + CENC

You also have or are willing to set up:

• A license-server vendor relationship (Vualto, EZDRM, BuyDRM, Axinom) OR your own license server (rare; only studios with in-house DRM teams)
• A KMS or HSM for content encryption keys (AWS KMS, Google Cloud KMS, hardware HSM, or vendor-provided key vault)
• A CMAF-aware packager (the packaging layer in this architecture)
• An authentication layer (your subscriber DB or entitlement service) that the license server can call to authorize requests

#Architecture overview

flowchart TB
    subgraph "Encoder output"
      ENC[Encoded mezzanine<br/>H.264 / HEVC<br/>multi-rendition ABR]
    end

    subgraph "DRM packaging stage"
      KMS[Content key generator<br/>AES-128 CTR/CBCS keys]
      PKG[CMAF + CENC packager<br/>cbcs encryption<br/>per-rendition unique keys]
      SPEKE[SPEKE bridge<br/>Common Encryption<br/>Key Exchange]
    end

    subgraph "Multi-DRM key management"
      LS_W[Widevine<br/>license server]
      LS_F[FairPlay<br/>license server]
      LS_P[PlayReady<br/>license server]
    end

    subgraph "Storage + delivery"
      ST[(Encrypted segments<br/>+ DRM-aware manifests)]
      CDN[CDN<br/>HLS + DASH manifests]
    end

    subgraph "Client + entitlement"
      AUTH[Entitlement service<br/>JWT validation]
      P[Player<br/>shaka-player / hls.js / native]
    end

    ENC --> PKG
    KMS -->|content keys| PKG
    KMS -->|key IDs + bytes| SPEKE
    SPEKE -->|key delivery via SPEKE-API| LS_W
    SPEKE -->|key delivery via SPEKE-API| LS_F
    SPEKE -->|key delivery via SPEKE-API| LS_P
    PKG -->|encrypted segments + manifest| ST
    ST --> CDN
    CDN -->|encrypted CMAF + manifest| P
    P -->|license request<br/>+ JWT auth token| AUTH
    AUTH -->|user authorized?| LS_W
    AUTH -->|user authorized?| LS_F
    AUTH -->|user authorized?| LS_P
    LS_W -->|Widevine license| P
    LS_F -->|FairPlay SPC/CKC| P
    LS_P -->|PlayReady license| P

    classDef enc fill:#1a1a1c,stroke:#ff6b35,stroke-width:1.5px,color:#f5f5f5
    classDef ls fill:#0a0a0c,stroke:#71717a,stroke-width:1.2px,color:#a1a1aa
    class ENC,PKG,KMS,SPEKE,ST enc
    class LS_W,LS_F,LS_P,AUTH,CDN,P ls

The shape: encoded mezzanine flows into a CMAF packager, which encrypts segments using AES-128 CTR or CBCS keys generated per-rendition. The SPEKE bridge delivers content keys to all three DRM license servers using the standard SPEKE API. Players request licenses at playback start, authenticated against your entitlement service, then decrypt segments with the issued license.

#Component walkthrough

#Content keys + KMS

Each rendition (sometimes each segment, depending on key-rotation strategy) is encrypted with a unique AES-128 content key. The key generator pulls keys from a KMS or HSM:

• AWS KMS — common for AWS-resident workflows. Keys never leave the KMS; signing operations happen via API.
• Google Cloud KMS — equivalent for GCP workflows.
• Hardware HSM — required for studio-level pre-release content with explicit MPA/TPN requirements.
• License-server-provided key vault — Vualto, EZDRM, BuyDRM, and Axinom all offer key generation as part of their managed service. Simpler operationally; the trade-off is the keys live in the vendor's vault.

The decision: KMS-managed keys give you full custody and easier audit. License-server-managed keys give you operational simplicity at the cost of vendor lock-in on key custody. For most operators the license-server-managed path is fine; for operators with explicit content-protection contracts (studio relationships, particularly pre-release), KMS-managed is non-negotiable.

#CMAF + CENC packager

The packager consumes the encoded mezzanine and emits CMAF (Common Media Application Format) segments encrypted with CENC (Common Encryption). CMAF + CENC is the unification that lets one set of encrypted segments serve all three DRMs — without it, you'd encode and encrypt three times (once for HLS+FairPlay, once for DASH+Widevine, once for Smooth+PlayReady).

The encryption mode matters:

• cbcs (CBC with Subsamples) — supported by Widevine + FairPlay + PlayReady. The unified mode for multi-DRM. Standard for new deployments.
• cenc (CTR mode) — supported by Widevine + PlayReady only. FairPlay does NOT support cenc. Legacy mode; avoid for new deployments.

For multi-DRM with FairPlay support, cbcs is required. The packager configures this per-rendition; once set, all three DRMs work from the same encrypted segments.

#SPEKE bridge

SPEKE (Secure Packager Encoder Key Exchange) is the AWS-standardized API between packagers and license servers. It's the abstraction that lets you swap license-server vendors without changing packager configuration.

The flow:

1. Packager generates a content key (or pulls from KMS).
2. Packager makes a SPEKE request to each license-server endpoint, passing the key ID + content type.
3. License servers store the content key indexed by key ID.
4. Packager encrypts segments with the content key and embeds key ID references in the manifest.
5. Player parses manifest, identifies DRM scheme + key ID, requests license from license server.
6. License server returns license containing the decryption key (wrapped per-DRM-spec).

SPEKE is the reason the architecture supports vendor-neutral integration. Vualto, EZDRM, BuyDRM, and Axinom all expose SPEKE endpoints; switching between them is a packager-config change, not an architectural rewrite.

#License servers (Widevine, FairPlay, PlayReady)

You have three license servers running, one per DRM scheme. Each handles license issuance to clients of its DRM type:

• Widevine — Google's DRM, supported in Chrome, Edge, Firefox, Android, smart TVs (most), and Chromecast.
• FairPlay Streaming — Apple's DRM, the only path for native iOS, macOS, and tvOS playback.
• PlayReady — Microsoft's DRM, required for Xbox, some smart TVs, Edge legacy, and certain enterprise scenarios.

For a typical premium VOD service:

• Web playback uses Widevine in Chrome/Edge/Firefox (~70% of web).
• iOS native + Safari uses FairPlay (~25% of web on Safari, plus 100% of native iOS).
• PlayReady covers the long tail (~5% — Xbox, certain TVs, legacy enterprise).

Skipping any of the three has consequences: skipping Widevine = no Android, no Chromecast, no most smart TVs. Skipping FairPlay = no native iOS, no Apple TV. Skipping PlayReady = no Xbox, no Windows native legacy.

#Entitlement service

The entitlement service is the layer between your user database and the license server. When a player requests a license, the request includes an authentication token (typically a JWT signed by your service). The license server forwards the token to the entitlement service, which:

• Verifies the JWT signature
• Checks subscription status (is this user paid?)
• Checks geo-restrictions (is this user in an authorized region?)
• Checks device count (is this user under their device limit?)
• Returns yes/no to the license server with optional restrictions (output protection, persistent license validity, etc.)

The entitlement service is yours to build (or buy from your license-server vendor — most include it). It's the policy layer; the license server is the enforcement layer.

#Player + authentication flow

The player-side flow:

1. Player loads manifest from CDN.
2. Player parses manifest, identifies DRM scheme + key ID + license server URL.
3. Player generates a license request (CDM-specific format per DRM).
4. Player attaches authentication token (usually a JWT in HTTP header).
5. Player POSTs license request to license server.
6. License server validates token (via entitlement service), looks up content key, generates license, returns to player.
7. Player passes license to platform CDM (Content Decryption Module).
8. CDM decrypts segments inline as they're received from CDN.

The CDM is platform-specific: Chrome's Widevine CDM, Apple's CoreMedia (FairPlay), Edge/Windows's PlayReady CDM. The browser/OS handles the actual decryption; your app provides the license.

#Multi-DRM packaging strategies

Three real strategies, with different trade-offs:

#Strategy 1: CMAF + CENC `cbcs` (recommended for new deployments)

One set of encrypted segments serves all three DRMs. Manifest references three license-server endpoints (one per DRM) with a single content-key ID. Player picks the DRM the platform supports and decrypts.

Pros: Simplest packaging, smallest storage footprint, easiest to operate. Cons: Requires modern players that support CMAF + cbcs. Legacy players (older Smart TVs, certain enterprise scenarios) may not.

#Strategy 2: Separate HLS+FairPlay vs DASH+Widevine+PlayReady

HLS for Apple platforms (FairPlay), DASH for everyone else (Widevine + PlayReady multi-key in DASH manifest). Two sets of packaged outputs, two-times the storage.

Pros: Player compatibility is broader; works with older HLS players that don't speak CMAF. Cons: 2× storage, 2× packaging compute, manifest manipulation more complex.

This was the standard pattern pre-2020 and is still common in legacy deployments. New deployments should default to strategy 1.

#Strategy 3: Per-rendition key rotation

Each rendition (or each segment, for paranoid deployments) uses a different content key. Compromise of one key reveals one rendition's content; the rest stay protected.

Pros: Limits blast radius of key compromise. Required for some studio agreements. Cons: Packaging compute grows linearly with rendition count; license-server load grows with key count; manifest size grows.

For most operators, single-key-per-asset is sufficient. Per-rendition rotation is for studio pre-release content where a single key compromise would be a nine-figure problem. Per-segment rotation is rare; we've seen it on exactly one workflow in three years.

#Failure modes and what they cost you

Failure	Frequency	Customer-visible impact
License-server outage (single DRM)	Rare per-vendor	Players on that platform can't start playback; running playback continues to segment end
Key-rotation race (during scheduled rotation)	During key-rotation events	Brief playback hiccup if license refresh fails; CDM falls back to last valid key
Entitlement service slow response	During traffic spikes	License-request latency adds to playback start time; users perceive slow start
Manifest tampering attempt	Constant low-level	Player rejects unexpected key IDs; legitimate playback unaffected
Output-protection mismatch (HDCP)	Per-device, per-content	Player shows error message, won't play premium content on non-HDCP outputs

The failure modes that cost the most are the ones that look like normal product errors to users. License-server slowness is usually misdiagnosed as "playback is slow" when the actual issue is license-issuance latency. Investing in license-server response-time monitoring pays back across many incident triages.

#Vendor relationships in MpegFlow's beta

For design-partner deployments today, we pair MpegFlow's encoding + workflow orchestration with one of these license-server vendors:

• Vualto — independent multi-DRM provider, strong EU presence, SPEKE-compatible.
• EZDRM — US-based multi-DRM, popular for North American OTT.
• BuyDRM (KeyOS) — long-standing studio-grade DRM with strong PlayReady heritage.
• Axinom — full-stack content protection including studio workflow integration.

The integration pattern is identical across vendors thanks to SPEKE. We've helped beta partners stand up the integration in under a week.

#Companion architectures

• Broadcast-grade VOD transcoding — the primary VOD pipeline this DRM packaging extends. The encoded mezzanine output of that pipeline is the input to this one.
• Live ingest + low-latency packaging — DRM packaging works in live too. The flow is similar but with continuous packager output and key-rotation per segment.
• Strict-broker security — content-key handling integrates with the broker pattern: workers receive keys via signed presigned URLs, never store them.
• Multi-region failover — DRM packaging in multi-region requires license-server failover between regions; covered there.

#Scope and companion architectures

This pattern covers DRM packaging for VOD and live, with multi-DRM (Widevine + FairPlay + PlayReady) via SPEKE. Adjacent concerns:

• Forensic watermarking — invisible per-user watermarks for piracy tracing. Different layer; integrates with the packager via vendors like NexGuard, Witbe, or Verimatrix. Out of scope here.
• Geo-restriction enforcement — handled by the entitlement service or the CDN edge; not a packager concern.
• Concurrent-stream limiting — handled by the entitlement service.
• Output protection (HDCP) — declared in the license; CDMs enforce it. Not a packager concern, but the license must request it for compliant workflows.
• Persistent licenses (offline downloads) — supported by all three DRMs but with significant additional complexity. The license server handles persistence and revocation; the packager just emits encrypted segments. Out of scope here.

#Honest scope: where we are vs where we're going

Native DRM packaging ships in MpegFlow's 2026 Q4 release. Today's beta supports unencrypted output. For design-partner deployments needing DRM today, we wire in one of the four license-server vendors above and operate the integration jointly during onboarding.

The honest reason DRM ships later than VOD encoding: DRM is a vendor-integration story more than a code story. The encoding + packaging pipeline is well-understood territory; the SPEKE integrations, license-server compatibility testing, and player-side validation across the three DRMs is the work. We chose to ship the encoder + orchestration depth first, then add native DRM packaging once we have direct customer use cases driving the vendor selection.

If you're evaluating DRM-protected video infrastructure now, the platform evaluation framework extends naturally — most of the seven questions get more important when DRM is in scope.

If your team is at the volume where DRM packaging is on the year-one roadmap, the design partner program is the path. We can scope the license-server integration as part of onboarding.