CENC vs CBCS: Common Encryption for Streaming

Why this matters

If you are a founder, product manager, or first-time streaming CTO, this is the single most consequential technical decision in your whole content-protection setup, and it is one line in a packaging config: which encryption scheme you choose. Get it right and one encrypted copy of your catalog plays on every screen on earth; get it wrong and you either pay to store and encrypt your catalog twice, or you ship a library that shows a black screen on every Apple device and only discover it after launch. You do not need to implement any of this yourself — a multi-DRM service or packager does the cryptography — but you do need to understand the choice well enough to set it correctly, read a vendor's spec sheet, and pass a studio's security review. By the end of this article you can explain why "encrypt once, license many" is physically possible, say out loud the difference between cenc and cbcs, and know why your packaging should standardize on cbcs.

This article is the technical heart of our content-protection block. It is the deep layer beneath multi-DRM: one workflow, every device, which showed you the encrypt-once pipeline from a thousand feet; here we open up the encryption box and look at the gears. It assumes you already know the device reality from the three DRM systems: Widevine, PlayReady, FairPlay. You do not need a cryptography background — every term is built up from scratch.

The one problem Common Encryption solves

Start with the problem, because the design only makes sense once you feel the pain it removes. Content protection is not one technology but three competing ones, each owned by a platform company and welded into its own devices: Google's Widevine, Microsoft's PlayReady, and Apple's FairPlay. They use different license formats and different handshakes, and none of them reaches every screen. A platform that wants to play on Apple devices, Android phones, Windows laptops, and the dozen brands of smart TV has to satisfy all three. (The device-to-system map is the subject of the three DRM systems; here we take it as given.)

The naive way to satisfy three systems would be to encrypt your catalog three times — once in each vendor's private format. That triples your encoding compute, triples your storage, and triples your operational headache, for protection that is no stronger. The standard that makes the triple unnecessary is called Common Encryption, abbreviated CENC and specified in ISO/IEC 23001-7. Its job, in the words of the standard itself, is to specify "encryption and key mapping methods that enable decryption of the same file using different Digital Rights Management (DRM) and key management systems."

Read that again, because it is the whole point: the same file, decrypted by different DRM systems. Common Encryption is not itself a DRM. It does not issue licenses, hold keys, or enforce rules — it deliberately "leaves the details of rights mappings, key acquisition and storage, DRM content protection compliance rules, etc., up to the DRM system." What it standardizes is only the scrambling of the bytes and the small set of labels that tell any compliant DRM where the locked door is. Picture a shipping container with a standardized lock fitting: three different security companies can each fit their own padlock to the same hasp. Common Encryption is the standardized hasp. The padlocks are Widevine, PlayReady, and FairPlay.

Figure 1. One file, three DRM systems. A single cbcs-encrypted CMAF asset carries the scheme label (schm), the default key identifier and encryption defaults (tenc), the per-sample initialization vectors (senc), and one protection-system header (pssh) per DRM. Widevine, PlayReady, and FairPlay each find their own header and unlock the same bytes.

Two layers, one more time: scrambling versus licensing

Before the mechanics, lock in the split that the rest of this article depends on, because almost every confused article about DRM blurs it. A protected stream has two separate layers.

The encryption layer is the scrambling of the actual video and audio bytes with a key. This layer is shared — all three DRM systems can read from the same scrambled files, provided those files use a scheme all three accept. This is the layer Common Encryption standardizes, and the layer this article is about.

The license layer is the small message, issued live at playback, that hands a specific device the key to unscramble the video, wrapped so only that device's trusted hardware can open it. This layer is per system — each vendor has its own license format and handshake, and they are not interchangeable. How a license server actually delivers that key is the subject of license servers and key delivery.

Everything below concerns the first layer only. When we say one file serves three DRMs, we mean the scrambled bytes are shared. The keys still arrive per device, per play. Hold that line and nothing here will confuse you.

AES in plain language: keys and 16-byte blocks

The scrambling itself uses the Advanced Encryption Standard, or AES — the same workhorse cipher that protects bank traffic and password vaults. You do not need its internals, only three facts.

First, AES works on blocks: fixed chunks of exactly 16 bytes. The Common Encryption spec defines a block precisely as a "16-byte extent of sample data that may be encrypted or decrypted by AES-128 block cipher." Your video is a long river of bytes; AES chops the protected parts into 16-byte blocks and scrambles them one block at a time.

Second, AES needs a key — a secret number, here 128 bits long (the "128" in AES-128). The same key locks and unlocks. The entire game of DRM is getting that key to the right device and nowhere else; the encryption itself is the easy, standardized part.

Third, a raw block cipher needs a mode of operation — a rule for how the individual 16-byte blocks relate to each other as you work down the river. If you naively encrypted every block with the same key and nothing else, two identical blocks of video would scramble to identical output, leaking patterns. The mode prevents that, and the choice of mode is exactly where cenc and cbcs part ways. There are two modes in play, and the difference between them is the central fact of this whole article.

CTR versus CBC: the two modes that split the schemes

Here are the two modes, each with a plain-language picture. Take them slowly — one idea each.

Counter mode, written AES-CTR. Counter mode does not encrypt your video directly. Instead it encrypts a running counter — 1, 2, 3, and so on, combined with a per-sample starting number called the initialization vector (IV), a value (8 or 16 bytes) that makes each stream's keystream unique. Encrypting the counter produces a pseudo-random stream of bytes called a keystream, and the video is scrambled by combining it with that keystream. The useful property: because each block depends only on its own counter value, you can jump straight to block number 5,000 and decrypt it without touching the 4,999 before it. That random access and the ability to decrypt blocks in parallel is why counter mode was the original choice for MPEG-DASH delivery. The scheme built on it is cenc.

Cipher-block-chaining mode, written AES-CBC. Chaining mode encrypts the video blocks directly, but each block is first mixed with the encrypted result of the previous block — the blocks are chained, like a line of climbers roped together. The first block is mixed with the initialization vector; every block after it is mixed with the one before. The property that matters: you cannot decrypt block 5,000 without having walked the chain up to it, so chaining is sequential, not random-access. Apple's streaming used CBC from the start, for reasons we come to shortly. The modern scheme built on chaining is cbcs.

The single takeaway: counter mode (CTR) and chaining mode (CBC) produce completely different scrambled bytes from the same video and the same key. A device that only knows how to walk a CBC chain cannot read CTR-scrambled bytes, and vice versa. That incompatibility is not a bug; it is simply two different math recipes. It is also the reason a platform cannot ignore the scheme choice: pick the recipe a device cannot read and the device shows a black screen, every time.

Figure 2. The two AES modes. In counter mode (AES-CTR, the cenc scheme) the key encrypts a counter plus the initialization vector to make a keystream, combined with the video — any block is independently decryptable. In chaining mode (AES-CBC, the cbcs scheme) each block is mixed with the encrypted previous block, so decryption is sequential.

Full-sample versus subsample: why you leave the headers clear

There is a second choice on top of the mode: how much of each frame you scramble. Encrypting every single byte of a video file sounds safest, but it breaks something. A video stream is not an undifferentiated blob; it is a sequence of structured packets. For modern codecs these packets are called NAL units (Network Abstraction Layer units) — each carries a small header saying "what kind of data follows" and then the compressed picture data itself.

Players, packagers, and devices need to read those headers to navigate the stream — to find frame boundaries, switch quality levels, and start playback at the right place. If you encrypt the headers too, every box in the delivery chain goes blind. So Common Encryption defines subsample encryption: within each frame, you leave a small unprotected part (the structural header) in the clear and scramble only the protected part (the heavy compressed picture data that follows). The spec defines a subsample exactly that way — "an unprotected part immediately followed by a protected part." The clear headers let the pipeline steer; the encrypted payload is the part worth stealing, and it stays locked.

This is also why DRM protects the stream and the keys but not the screen: the bytes are unreadable in transit and at rest, but a decrypted, decoded frame still has to be drawn on a display, and a camera pointed at that display sees a picture. The threat model is covered in why DRM exists and what it actually protects; for now, hold the precise claim: encryption hides the compressed payload, not the eventual pixels.

Pattern encryption: the 1:9 that makes 4K affordable to decrypt

Now the third and final mechanic, and the one that explains the modern scheme's name. Even encrypting only the payload of every frame is a lot of cryptographic work when the payload is a 4K, high-frame-rate stream — and that work runs on the decrypt side too, on phones and TV chips with limited power. So the 2016 edition of the standard added pattern encryption: instead of scrambling the entire protected payload, you encrypt a repeating fraction of it.

The pattern is described by two small numbers the spec calls crypt_byte_block and skip_byte_block — how many 16-byte blocks you encrypt, then how many you leave clear, repeating to the end of the payload. The convention that shipped, recommended in the standard, is 1:9 — encrypt one block, skip nine, repeat. That means only about one-tenth of the payload's blocks are ever scrambled, yet because the encrypted blocks are sprinkled densely through every frame, the stream is useless without the key. The standard's own explanation of why this was added is blunt: "Pattern encryption reduces the computational power required by devices to decrypt video tracks."

Walk the saving out loud, because it is the reason the pattern exists. Suppose a frame's protected payload is 200 sixteen-byte blocks:

Full-subsample encryption (cenc, cbc1):
  blocks encrypted = 200  (100% of the payload)

Pattern encryption 1:9 (cbcs, cens):
  one encrypted per ten  = 200 / 10 = 20 blocks (10% of the payload)
  decrypt work           ≈ one-tenth of full encryption

On a battery-powered phone decoding 4K, doing one-tenth of the decryption work is the difference between smooth playback and a hot, stuttering device. Two details complete the picture. Pattern encryption applies to video only; audio is small enough that it is simply fully encrypted (the pattern set to encrypt everything, with no skip). And cbcs pairs pattern encryption with a constant initialization vector reused across the samples, which simplifies the hardware, whereas cenc carries a fresh per-sample IV. These are the kinds of details your packager handles automatically — but they are why the two schemes feel different in practice, not just in theory.

Figure 3. Subsample and pattern encryption. The clear NAL header lets the pipeline navigate; within the protected payload, the cbcs 1:9 pattern encrypts one 16-byte block and skips nine, cutting decrypt work to about a tenth while keeping the stream unplayable without the key.

The four schemes — and the two that actually ship

Put the mode choice (CTR or CBC) together with the coverage choice (full or pattern) and you get a small grid. Common Encryption names each combination with a four-character code. The current 2023 edition defines five schemes in total, but only two of them are deployed in the real world. This table is the one to remember.

Scheme	AES mode	Coverage	Deployed in practice?	FairPlay can read it?
cenc	Counter (CTR)	Full subsample	Yes — the original DASH/Widevine/PlayReady scheme	No
cbcs	Chaining (CBC)	Pattern (1:9 video)	Yes — the modern convergence scheme	Yes
cbc1	Chaining (CBC)	Full subsample	Rare	No
cens	Counter (CTR)	Pattern	Rare	No
sve1	Counter (CTR)	Content-sensitive	New in 2023; not yet in production	No

Two schemes carry essentially all of streaming: cenc (counter mode, full subsample) and cbcs (chaining mode, 1:9 pattern). The other three exist in the standard but you will almost never meet them — cbc1 and cens were stepping stones, and sve1 (a codec-aware "content-sensitive" scheme added in the 2023 fourth edition, where the encrypted bitstream stays a valid decodable bitstream) is too new to plan around. When a vendor, a spec sheet, or a studio talks about "the two schemes," they mean cenc and cbcs. Everything else is footnote.

The history compresses to three steps. The original Common Encryption shipped cenc (counter mode) and MPEG-DASH adopted it. Apple, meanwhile, had always encrypted its HLS streams with AES in CBC mode. The 2016 edition added the pattern-encryption schemes cbcs and cens specifically so that Apple's CBC approach could live inside the same standard as everyone else. That single addition is what made convergence possible — and it set up the rule that governs your packaging today.

Figure 4. The Common Encryption schemes at a glance. Only cenc (counter mode, full) and cbcs (chaining mode, 1:9 pattern) ship at scale; cbcs is the only scheme FairPlay can read, which is why it became the industry default.

Why FairPlay needs cbcs — and why that decided everything

Here is the rule that turns all of the above into a single packaging instruction. Apple FairPlay accepts only cbcs. It cannot read cenc at all. This is not a preference or a default you can change; it is a hard constraint of every iPhone, iPad, Mac, and Apple TV.

The reason is historical and now permanent. Long before Common Encryption existed, Apple built HLS — its streaming format — with a scrambling method called SAMPLE-AES, which encrypts only the audio and video samples using AES in cipher-block-chaining (CBC) mode. When the industry wrote pattern encryption into the standard in 2016, Apple's existing CBC approach mapped onto the new cbcs scheme rather than the counter-mode cenc. Apple chose to adopt the open standard for fMP4 content instead of extending its private format, but it stayed on the CBC side of the fence. The result is the immovable fact every multi-DRM catalog has to design around: a FairPlay device handed cenc-scrambled bytes sees nothing, because it has no counter-mode decryptor.

Now combine that with the other side of the grid. Modern Widevine and PlayReady accept both cenc and cbcs — they were updated years ago to read the chaining-mode scheme. So look at what the options actually are. If you pick cenc, you serve Widevine and PlayReady but lose every Apple device. If you pick cbcs, you serve FairPlay and modern Widevine and modern PlayReady — all three. There is exactly one scheme that all three systems can read, and it is cbcs. FairPlay's one-sided constraint quietly decided the whole industry's default.

"cbcs everywhere": the modern convergence

That logic has a name in streaming circles — "cbcs everywhere" — and as of 2026 it is simply how protected streaming is done. By around 2020 every major content-decryption module had shipped cbcs support, and the rule collapsed to one line: package your catalog once with cbcs, in the CMAF container, and the same master streams to Widevine, PlayReady, and FairPlay. Package in cenc and you cut Safari and every Apple device off.

This is the deep reason the "encrypt once, license many" promise from the multi-DRM article is physically real and not marketing. It rests on two standards working together: Common Encryption's cbcs scheme provides one set of scrambled bytes all three systems accept, and the Common Media Application Format (CMAF, ISO/IEC 23000-19) provides one segmented container that both Apple's HLS and MPEG-DASH delivery can read. One scheme, one container, one encryption pass — the packaging workflow that produces this is covered in packaging: CMAF, HLS, and DASH from one mezzanine.

One precise caution, because popular guides get it wrong in both directions. Some still tell you a multi-DRM catalog "must" keep two encrypted copies, one cenc and one cbcs. Per the standard and current device support, that is true only if your audience includes old clients that predate cbcs — a shrinking legacy tail. For a modern device target, a single cbcs asset serves all three systems, and a second cenc copy is an optional fallback, not a requirement. The rule of thumb: standardize on cbcs, and add cenc only as a deliberate, measured exception for a specific old-device tail you have decided to support.

What is actually inside the file: schemes, keys, and boxes

You now understand the scrambling. The last piece is the labelling — the small metadata structures, called boxes in the MP4/CMAF file format, that tell a DRM system how to find its key and unlock the bytes. You will see these names on vendor dashboards and in studio security checklists, so it pays to recognize four of them.

The scheme box (schm) carries the four-character code — cenc or cbcs — that announces which recipe was used. A player reads this first to decide whether it can play the stream at all.

The track encryption box (tenc) carries the default encryption settings for the track, including the default_KID — the key identifier. A KID is not the key itself; it is a 128-bit name for the key, like a locker number. The same default_KID is shared across all three DRM systems, and each system uses it to ask its own license server for the actual key. As the standard puts it, DRM systems "support identifying the decryption key via stored key identifiers (KIDs)," but "how each DRM system protects and locates the KID identified decryption key is left to a DRM-specific method." Naming the key in the open is safe; the key itself never sits in the file.

The sample encryption box (senc) carries the per-sample initialization vectors — those starting numbers each scrambled sample needs — and, where used, the map of which byte ranges in each frame are clear and which are encrypted.

The protection system header box (pssh) is the one that makes multi-DRM literally work. Each pssh box holds one DRM system's private data, tagged with that system's well-known SystemID. A single file can carry several — one for Widevine, one for PlayReady, one for FairPlay — and "a single file may be constructed to be playable by multiple key and DRM systems, by including ProtectionSystemSpecificHeaderBoxes for each system supported." At playback a device scans the pssh boxes, finds the one matching the system it was born with, ignores the rest, and uses it to fetch the key named by the default_KID. (In modern DASH this header is increasingly delivered in the manifest rather than the file, for operational agility, but the role is the same.)

Tie it together with one sentence you could draw on a whiteboard: the schm box says which scheme, the tenc box names the key with a default_KID, the senc box holds the IVs, and one pssh box per system lets Widevine, PlayReady, and FairPlay each find their own door to the same locked content. That is Figure 1, now in full detail.

How the player checks before it commits: EME and encryptionScheme

One practical question remains: how does a web player know, before it starts, whether the device in front of it can actually read cbcs? The answer is a browser interface called Encrypted Media Extensions (EME), a W3C standard that lets a player negotiate DRM without knowing each system's internals. EME was extended with an encryptionScheme field so a player can ask the device, in advance, "do you support cbcs?" (or cenc) and get a yes or no before choosing what to load. This lets a single player adapt: query the scheme, then request the matching stream. The full browser DRM negotiation — the content-decryption module, the per-browser reality — is the subject of Encrypted Media Extensions and the browser DRM stack. For the encryption decision, the takeaway is that the capability check exists, so a well-built player never has to guess.

A common mistake: cenc-only encryption that breaks Apple

The single most expensive error in this whole area is quiet, because it passes every test the team runs — until it reaches an Apple device. A team encrypts the catalog with the older counter-mode cenc scheme, confirms playback on Android and Windows, and ships. Then every iPhone, iPad, Mac, and Apple TV shows a black screen, because FairPlay cannot read cenc and there is no fallback. The failure is invisible in a Chrome-and-Android test lab and only surfaces when a real Apple device, or a real customer, tries to play. By then the catalog is encrypted and live.

The cure is the rule this whole article builds to: standardize on cbcs from the first packaging job. One cbcs asset serves FairPlay, Widevine, and PlayReady together. If — and only if — you must support a specific old-device tail that predates cbcs, add a cenc variant as a deliberate, documented fallback, never as the default that strands Apple. And test on at least one real device from each ecosystem before you call packaging done; the schemes are not interchangeable, and the only way to be sure is to press play on hardware from all three.

A second, smaller mistake is mixing schemes carelessly within one stream. The interoperability guidelines are explicit: within a set of interchangeable quality levels, every level must use the same scheme, and clients must not try to play cenc and cbcs content at the same time. If you offer both schemes, you offer them as two complete, equal alternatives — not a mixture inside one. Your packager enforces this when configured correctly; the failure mode appears only when someone hand-edits a manifest.

Where Fora Soft fits in

The encryption-scheme choice is one config line that decides whether your catalog plays on every screen or fails silently on a third of them, and a wrong choice surfaces only in production, on the devices hardest to test. Fora Soft has built video streaming, OTT/Internet TV, e-learning, and telemedicine software since 2005, across 625+ shipped projects for 400+ clients, and getting Common Encryption right runs through that work: standardizing a catalog on the cbcs scheme in CMAF so one encrypted master serves Widevine, PlayReady, and FairPlay; wiring the schm/tenc/senc/pssh signaling so every device finds its own license path against a shared default_KID; deciding when a legacy cenc fallback is worth its storage cost and when it is dead weight; and verifying playback on real hardware from all three ecosystems before launch. When a media company needs protection that works on the first try across the whole device matrix — without encrypting and storing the catalog twice — that scheme-level engineering is the capability we bring.

What to read next

• Multi-DRM: one workflow, every device
• License servers and key delivery
• The DRM and content-protection reference architecture

Call to action

• Talk to a streaming engineer — book a 30-minute scoping call to talk through your cenc cbcs plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Common Encryption (CENC) Quick Reference — cenc vs cbcs — A one-page reference to choose an encryption scheme before you lock a packaging config or sign a DRM contract: the two schemes that ship (cenc = AES counter mode read by Widevine and PlayReady; cbcs = AES chaining mode with a 1:9….

References

1. ISO/IEC 23001-7:2023 — Common Encryption in ISO base media file format files (CENC) — ISO/IEC, Fourth edition, 2023-08. The controlling standard. Defines the five protection schemes (§4.2): cenc AES-CTR full sample/subsample, cbc1 AES-CBC full, cens AES-CTR pattern, cbcs AES-CBC pattern (§10), and the new sve1 content-sensitive scheme (Annex A); defines the 16-byte block (§3.1.1), subsample as "an unprotected part immediately followed by a protected part" (§3.1.10), pattern encryption via crypt_byte_block/skip_byte_block (§6, §9.6), and the metadata boxes pssh (§8.1), tenc (§8.2), and senc (§7.2). States Common Encryption enables "decryption of the same file using different DRM and key management systems" and that a single file may be "playable by multiple key and DRM systems, by including ProtectionSystemSpecificHeaderBoxes for each system." Source of the four-scheme grid, the subsample/pattern mechanics, the default_KID/box model, and the history (cbc1 in the 2nd edition; cbcs/cens added for pattern encryption to "reduce the computational power required by devices to decrypt video"). Tier 1 (official standard). https://www.iso.org/standard/84637.html (accessed 2026-06-17)
2. ISO/IEC 23000-19 — Common Media Application Format (CMAF) for segmented media — ISO/IEC. Defines the single segmented container that both HLS and MPEG-DASH read, so one cbcs-encrypted package serves both delivery methods — the container half of "encrypt once". Specifies (with CENC §8) the content-protection box structure in the init and media segments. Tier 1 (official standard). https://www.iso.org/standard/85623.html (accessed 2026-06-17)
3. Encrypted Media Extensions (EME) — W3C Recommendation. Defines the browser DRM API and the key-system/Content Decryption Module model that lets one player negotiate Widevine, PlayReady, or FairPlay; the basis for runtime scheme negotiation. Tier 1 (official standard). https://www.w3.org/TR/encrypted-media/ (accessed 2026-06-17)
4. Encrypted Media: Encryption Scheme Query (encryptionScheme) — W3C / WICG. The EME extension that lets a player detect, before committing, whether a device's CDM supports cbcs (or cenc) by passing encryptionScheme in the media capability to requestMediaKeySystemAccess(); defines cenc, cbcs, and cbcs-1-9. The mechanism behind "the player checks before it commits." Tier 1 (W3C community standard). https://wicg.github.io/encrypted-media-encryption-scheme/ (accessed 2026-06-17)
5. DASH-IF Implementation Guidelines: Content Protection and Security — DASH Industry Forum. Confirms the two deployed schemes: "Encrypted DASH content SHALL use either the cenc or the cbcs protection scheme … cenc and cbcs are two mutually exclusive protection schemes," that a cenc-only client cannot decrypt cbcs content and vice versa, that offering both requires two equal encrypted alternatives (with different content keys recommended), and documents the CMAF box structure (schm, tenc, senc, pssh) and the default_KID scope model. Tier 2 (issuing-body interoperability guideline). https://dashif.org/guidelines/ (accessed 2026-06-17)
6. HTTP Live Streaming (HLS) Authoring Specification for Apple Devices — Apple. First-party requirement that FairPlay-protected HLS uses SAMPLE-AES and that Apple devices read the cbcs scheme of Common Encryption — the constraint that decides the whole multi-DRM default. Tier 3 (first-party). https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices (accessed 2026-06-17)
7. FairPlay Streaming Overview — Apple. First-party documentation that FairPlay protects Apple platforms only, delivers over HLS, and uses the cbcs scheme — the reason cbcs is mandatory in any catalog targeting Apple devices and the historical CBC/SAMPLE-AES lineage behind it. Tier 3 (first-party). https://developer.apple.com/streaming/fps/FairPlayStreamingOverview.pdf (accessed 2026-06-17)
8. Widevine DRM — Overview and Supported Platforms — Google. First-party platform/scheme documentation showing cbcs support across current Android, Chromecast, smart TVs, and desktop/mobile browsers — the evidence behind "modern Widevine accepts cbcs," one half of the cbcs-everywhere convergence. Tier 3 (first-party). https://developers.google.com/widevine/drm/overview (accessed 2026-06-17; page last updated 2024-10-09)
9. PlayReady and Common Encryption / encryption modes — Microsoft Learn. First-party documentation of PlayReady support for the AES-CBC (cbcs) and AES-CTR (cenc) Common Encryption modes and the recommendation to use distinct content keys when both schemes protect the same content — the other half of the convergence and the cross-scheme key-separation caution. Tier 3 (first-party). https://learn.microsoft.com/en-us/playready/ (accessed 2026-06-17)
10. Is this the end of 'cenc'? An overview of DRM/codec support — Fraunhofer FOKUS / Video-Dev. Engineering overview tracing the cbcs convergence — Apple's CBC lineage, the 2016 pattern-encryption addition, and the point at which every major CDM accepted cbcs — corroborating the "cbcs everywhere" timeline in production terms. Tier 4 (engineering/industry). https://websites.fraunhofer.de/video-dev/is-this-the-end-of-cenc-an-overview-of-drm-codec-support-in-2021/ (accessed 2026-06-17)

Source note (per §4.3.2): the scheme definitions, the subsample/pattern mechanics, the box model, and the history all trace to the tier-1 primary standard — ISO/IEC 23001-7:2023 (ref 1), with CMAF (ISO/IEC 23000-19, ref 2) for the container and W3C EME plus the encryptionScheme query (refs 3–4) for the player side. The "two mutually exclusive schemes" rule and the box-structure detail are the DASH-IF interoperability guideline (ref 5, tier 2). The FairPlay-needs-cbcs constraint is Apple first-party (refs 6–7); the modern Widevine/PlayReady cbcs support that completes the convergence is Google and Microsoft first-party (refs 8–9). Where popular guides assert a multi-DRM catalog "must" keep both a cenc and a cbcs copy, this article follows the standard and current device support — a single cbcs asset serves all three for a modern target, with cenc an optional legacy fallback — and flags the discrepancy.