A codec migration is sold as a bitrate reduction, and bitrate reduction gets booked as a cost reduction. Those are two different claims, and the gap between them is where codec projects turn into cost regressions wearing a modernisation label. The failure is not that the newer codec compresses worse than advertised — it usually compresses exactly as advertised. The failure is that the saving lands on one line of the cost sheet while the new costs land on three others.
This piece is about the failure mode itself: how the saving gets absorbed, what it looks like on the way down, and which signals tell you it is happening before the catalogue has been re-encoded.
How the saving gets absorbed
Four cost surfaces move when you change codec, and only one of them moves in your favour.
Delivery falls. Fewer bits per second per viewer, fewer bytes egressed, a smaller CDN bill. That is real and it is the number in the proposal.
Encode compute rises, often sharply. The coding gains in HEVC and AV1 come from larger coding tree units, richer intra-prediction, and far more motion-estimation search — all of which are paid for in encoder cycles. A codec that halves bitrate does not halve cost; it moves cost from the delivery line to the encode line, and the exchange rate depends on your content and your encoder fleet, not on the codec spec. Whether that trade is favourable is an arithmetic question about your workload, and it is answered by measurement rather than by generational ordering.
Storage rises, because the old renditions do not go away. Any device population with incomplete hardware decode support needs a second ladder — usually H.264 — living alongside the new one. Two ladders means two sets of renditions per title, two sets of segments, two sets of manifests, and a storage and request footprint that grew rather than shrank.
Quality-of-experience diverges by device class. The viewers who fall back are not getting the same product as the viewers who don’t, and if nobody is measuring per-device-class QoE, that divergence is invisible until it shows up in retention.
Why does the fallback ladder cost more than teams expect?
Because “nominally supported” and “hardware-decoded” are not the same statement. A device can decode a codec in software and still be a bad place to send it — battery drain, thermal throttling, dropped frames on higher rungs, and a player that quietly steps down to a rung nobody optimised. So the fallback ladder is not a small tail hedge that you keep for legacy set-top boxes; it is a full parallel pipeline whose share of served streams is an empirical property of your audience.
That share is the single most decisive number in the whole migration, and in our experience it is the number teams have never instrumented. If the majority of streams still take the H.264 path, the delivery saving applies to a minority of traffic while the encode and storage costs apply to the whole catalogue. The migration then has to clear a bar it was never sized against.
Early warning signs
The failure is diagnosable before the re-encode, and each signal below is cheap to collect relative to the cost of a catalogue-wide encode.
| Signal | What it looks like | Why it predicts a cost regression |
|---|---|---|
| Fallback share unmeasured | Nobody can state what percentage of streams are served on the H.264 ladder | The delivery saving is being applied to traffic that may not exist |
| Device support taken from spec sheets | Coverage argued from codec support matrices rather than player telemetry | Software decode counted as if it were hardware decode |
| Encode cost quoted per hour of fleet, not per stream | “We have the GPUs already” used as the encode-cost answer | Encode minutes and GPU-hours per hour of source content per codec are never compared across codecs |
| Storage modelled as replacement | Plan assumes new renditions replace old ones | Dual ladders mean parallel renditions, so storage footprint per title rises |
| QoE measured in aggregate | One global QoE number, no split by device class | A regression concentrated on the fallback path averages away |
| Business case rests on published efficiency figures | Savings derived from a compression-efficiency claim, not your content | Content complexity changes what the codec actually buys |
Three or more of these present is the practical threshold at which we would stop and profile before committing encode budget. That is a planning heuristic drawn from cost-audit work on transcoding pipelines, not a benchmarked failure rate — the point is the direction of the check, not a precise probability.
What to do instead
Compute one number and defend it: net cost-per-stream, including encode compute, storage of parallel renditions, and delivery — not delivery alone. Everything else is instrumentation in service of that figure.
- Measure fallback share from player telemetry, split by device class, before choosing a target codec.
- Record encode minutes and GPU-hours per hour of source content, per codec, on your own content rather than a reference clip.
- Track storage footprint per title with both ladders present, including segment and manifest overhead.
- Score quality-of-experience per device class, so a regression on the fallback path cannot hide inside an average.
Then scope the change to where the arithmetic works. A codec that is net-negative across a full catalogue is frequently net-positive on new releases and high-traffic titles, where the delivery volume per encode is high enough to repay the encode cost. Limiting a new codec to that slice is not timidity; it is the same decision the numbers would force after a failed catalogue-wide migration, taken earlier and more cheaply. Which slice qualifies, and when a full re-encode is genuinely justified, is a threshold question we work through in when to switch codecs across H.264, HEVC and AV1.
The instrumentation itself is ordinary work — FFmpeg-level job accounting with a stable job identity, NVENC or hardware-encoder utilisation captured per job, player-side telemetry joined to device class. None of it requires new tooling. It requires deciding to collect it before the re-encode rather than after.
What this costs when ignored
An unnecessary catalogue re-encode is typically the largest single line item in a codec migration: encode compute across the entire library, engineering time on packaging and manifest changes, storage that doubles and does not come back down, and a QoE regression on the device classes least able to absorb one. Avoiding one re-encode that the numbers did not support is usually worth more than the delivery saving the migration was chasing.
That is why the profiling comes first. Our broadcast and streaming engineering work treats a codec proposal as a hypothesis about net cost-per-stream, and the Inference Cost-Cut Pack profiles the encoder pipeline and the viewer device mix so the hypothesis is scored before the catalogue is committed. The structural causes of this — why per-stream economics in streaming pipelines resist single-variable optimisation — are developed further in our media and telecom transcoding cost work.
One caveat that matters more than any figure here: results are content- and device-mix dependent. The same codec change can be clearly net-positive on one catalogue and clearly net-negative on another, with no error in either analysis. That is not a hedge — it is the reason a generational argument about codecs cannot substitute for a measurement of yours.
Frequently Asked Questions
What does “we use the newest codec” doesn’t always cut cost mean in practice? Codec recency guarantees neither compression efficiency nor compatibility with existing transcode pipelines. It means the bitrate saving a newer codec delivers is only one of four cost surfaces that move. Encode compute per stream rises, storage rises when a fallback ladder has to coexist with the new one, and quality-of-experience shifts by device class. If those three exceed the delivery saving for your actual viewer mix, the migration raises net cost-per-stream.
How much does encode-time compute per stream offset the bitrate saving from a newer codec? There is no portable ratio, because it depends on content complexity, encoder preset, ladder depth, and whether encoding runs on CPU or hardware encoders. The measurable form of the question is encode minutes and GPU-hours per hour of source content, per codec, on your own content — compared directly against the egress reduction on your own traffic.
What share of our audience actually gets hardware decode, and what does the fallback ladder cost us? That share has to come from player telemetry split by device class, not from codec support matrices, because software decode is often counted as support when it is a poor delivery target. The fallback ladder costs a full parallel set of renditions, segments and manifests per title, plus the storage and request volume that carries — which is why an unmeasured fallback share is the strongest single predictor of a cost regression.
How do we compare AV1, HEVC, and H.264 on net cost-per-stream rather than bitrate alone? Build one figure per codec that sums encode compute, storage of the renditions that must exist, and delivery for the traffic that codec will actually serve — then divide by streams served. Bitrate alone answers only the delivery term. The comparison is only meaningful on your content and your measured device mix.
When is a full catalogue re-encode justified, and when should a new codec be limited to new or high-traffic titles? A full re-encode is justified when the delivery saving across the whole library clears the encode and storage cost at your measured fallback share. Where it does not, the codec often still pays on new releases and high-traffic titles, because those carry enough delivery volume per encode to repay the encode cost.
What quality-of-experience regression should we expect on the fallback path, and how do we measure it per device class? Expect the regression to concentrate on devices doing software decode — dropped frames, thermal throttling, and players stepping down to rungs nobody tuned. Measure it by scoring QoE separately per device class rather than in aggregate, so a regression on the fallback path cannot be averaged away by the hardware-decode majority.
What signals in a profiling pass tell us a codec migration will be a cost regression before we commit to it? The strongest signals are an unmeasured fallback share, device support argued from spec sheets rather than telemetry, encode cost quoted per fleet-hour instead of per stream, storage modelled as replacement rather than addition, aggregate-only QoE, and a business case resting on published compression-efficiency figures. Three or more of those present is our practical threshold for profiling before committing encode budget.
Four Variables That Outweigh Compression Efficiency
Licensing fees, encode time, hardware support, and storage already paid for will eat any bitrate savings the latest codec promises. We Use Newest Codec rewards teams that measure first and argue later — start with the smallest instrumented slice and let the numbers settle the design.
