Your Next Codec Should Cost One Ladder

In March, a major streaming media survey of industry professionals was carried out on their codec plans for the year. 40% said they intend to deploy AV1 in 2026. In the same survey, H.264, a codec standardised in 2003, was still in use at 84% of respondents. Both numbers are telling the truth, and together they describe how streaming libraries actually grow: every codec transition in this industry has been sold as a replacement, and none has ever replaced anything.

Codecs Add. They Never Subtract

The reason H.264 refuses to die is sitting in living rooms. A Tizen or WebOS smart TV bought in 2016 is still on the wall and still requesting AVC; set-top boxes get amortised over eight to ten years; hotel screens and budget Android tablets stretch the tail further still. So AV1 gets adopted for the devices that can decode it, HEVC covers the large middle, and AVC stays for everyone else, because switching a codec off means telling some portion of your subscriber base that their television no longer works.

The pull towards the new codec is real, and it comes from the delivery side of the business. AV1 bitrate savings land directly in CDN egress bills and mobile data budgets, which is where high-volume services feel cost the most (Mickaël Raulet made the encode-side case for AV1 on this blog in January, including where the savings are real and where they are not). Delivery wants the new codec; storage pays for keeping all the old ones alive.

Three codecs serving one catalogue is now the planning assumption for any service with a broad device population. VVC is queuing behind them: live at the head end today, with origin and packaging support next in the pipe.

Where the Copies Come From

A codec never arrives alone. It brings a bitrate ladder, and the ladder gets multiplied by everything else the delivery chain wants: TS for the older set-top population and CMAF for everyone else, Widevine, PlayReady and FairPlay across the DRM estate, audio variants, subtitle sets. In a pre-packaged architecture every one of those permutations is written to storage before anyone has asked for it.

Run the numbers on a deliberately modest service. Five ladder rungs per codec, two container formats, two DRM stacks: 20 stored variants of each asset, per codec. Two codecs is 40 variants. Add AV1 and you are at 60, before 4K, a second audio language or a regionalized copy has entered the conversation. The codec count sets how many ladders you encode. The container and DRM axis multiply each of those ladders by four, and that second multiplier is the one a storage architecture can do something about.

Most of the multiplied content is never watched. On the cloud DVR platforms we have measured, playback ever touches only a low single-digit percentage of recorded content, and the legacy platform in our May case study was carrying roughly two units of stored data for every one that subscribers actually requested. Nobody audits this, because it arrives as a slow rise in a storage line item rather than as an event.

Store One Ladder, Package on Request

The way out is to stop treating packaging as a storage event. NEA Genesis holds one encoded ladder per codec, in open non-proprietary formats, and packages Just-In-Time: when a device requests playback, the packager wraps that ladder in the container, DRM and manifest the device asked for, at that moment. The codec itself is chosen at encode time and stored that way; the packager does not transcode. What moves off disk and into compute is everything downstream of the codec, which is where the multiplication was living. The CDN edge then caches the packaged output, so popular content pays the packaging cost once per segment rather than once per viewer, and the long tail (which is most of the library) may never be packaged at all.

So the arithmetic changes shape rather than disappearing. Three codecs still means three encoded ladders, and adopting AV1 still adds storage; on the modest service above it means fifteen stored renditions where the pre-packaged model held sixty. Encode new content in AV1 where the bitrate savings justify it, keep serving the 2016 televisions their AVC, and the next codec adds a ladder rather than twenty permutations.

The migration we published in May is what this looks like at scale: a Tier-1 operator moved its cloud DVR estate to Genesis and storage dropped from over 100 petabytes to 55. Most of that came out of permutations the old platform had been writing to disk before anyone asked for them. When that operator turns on its fourth codec it pays for one more encoded ladder. The container and DRM copies that used to arrive alongside each one are gone from the storage line.

Open formats also keep the library portable. If the platform changes, the content does not have to be re-processed to move, and in a market this consolidated that is worth something in a renewal negotiation rather than only at the exit.

The Ladder Should Shrink as the Content Ages

Storing one ladder per codec is the floor. Nothing says the ladder has to keep all its rungs for the life of the asset.

A month of session data from a European IPTV operator puts numbers on it. 40% of viewing sessions requested content less than an hour old, 53% under two hours, 78% under a day. Past three weeks, the entire remaining tail came to 3.6% of sessions. The drop is steep at the front: demand falls by about two thirds between the first hour and the second, and by roughly 96% by the sixth.

Operators already act on the front of that curve. On the same estate, a recent-content tier of about 70 terabytes carried a cache-hit ratio above 80% for all set-top-box linear traffic, which is a caching decision rather than a storage one. The back of the curve is where the storage sits. A ladder sized for the launch surge is still holding every rung it started with in week four, on the same fast disk, for 3.6% of the demand.

NEA Genesis acts on both. Profiles can be stripped out of the ladder as content ages, so a recording that launched with its full rung count is thinned down to the renditions the tail still requests, and the storage behind the removed profiles is returned. The operator sets the schedule: which rungs go at seven days, which go at twenty-eight, what floor stays permanently. Ageing content also moves down onto cheaper storage classes in a hybrid on-prem and cloud model, so the hot window stays on fast local storage and the three-week-old material sits in infrequent-access or archive-class object storage, priced for the access pattern it actually has. Neither policy touches the codec decision.

The Costs JIT Does Not Remove

What this does not fix: the encode side of a codec decision keeps its full weight. Every codec you support is an encoding run you pay for and a ladder you store for the life of the asset, and ladder design and licensing still need a business case per codec (HEVC’s royalty situation has not become simpler with age), which is exactly the ground the January AV1 post covered. JIT packaging also spends CPU at request time, so the packaging tier needs sizing for peak request rates, and that favours platforms whose packagers scale independently rather than as part of a monolith.

Ageing policies have edges of their own. Stripping a profile out is not reversible without re-encoding, so a catalogue where old content occasionally comes back to life – a sports archive that wakes up during a tournament – needs its retention rules written with that in mind, and cloud storage classes charge to read data back out as well as to hold it. None of this matters much at small scale either. If your service is modest, your device base uniform and your library shallow, pre-packaging stays simple and cheap. The arithmetic only turns painful on services that record everything: cloud DVR, catch-up, nPVR, large VOD estates.

The Question to Ask About the Next Codec

VVC is already on roadmap slides, and something will queue behind VVC. So ask it in the RFP rather than the retrospective: how many copies of your library will the next codec create, and how many of them will still be sitting on fast storage in week four?

---

Explore related insights

---