“Should we move to AV1?” is usually answered with a compression-efficiency chart. That chart cannot answer it. A codec switch pays back only when the delivery savings on the share of viewers who can actually hardware-decode the new codec exceed the added encode cost plus the cost of keeping a fallback ladder alive — and none of those three quantities is a property of the codec. They are properties of your catalogue, your encode fleet, and your audience.
That reframing is what turns a codec preference into a decision with a payback horizon. The rest of this piece is the decision structure we use to get there: which ledgers to open, what to measure in each, and what should make you defer the switch entirely.
The three ledgers a codec decision actually has
Teams tend to model one ledger — bitrate — and infer the other two. Modelling them separately is the whole trick, because they move in different directions and at different speeds.
Encode cost per stream rises, and it rises non-linearly. HEVC’s coding gains come from more search, more prediction modes, and larger coding structures; AV1 adds more again. On the same accelerator, the number of concurrent streams you can hold drops as codec complexity increases, which means a codec switch is also a fleet-sizing decision. If you are running GPU encoders, this shows up as fewer streams per card at the same preset quality — the practical consequence is that a “free” bitrate saving is paid for in capital or instance hours somewhere upstream.
Delivery cost per stream falls, but only on eligible traffic. The saving applies to the viewers who receive the new renditions. Viewers on clients without hardware decode either fall back to H.264 (no saving, and now a second ladder to maintain) or software-decode with battery and thermal consequences you will hear about in support tickets rather than in your cost model.
Parallel-ladder cost is the ledger nobody opens. During any phased rollout you store, package, and serve two ladders. That is duplicated storage, duplicated origin requests, duplicated CDN cache footprint, and duplicated QA surface. The transition period is usually longer than planned, so this cost should be modelled as a standing charge with a named end date rather than a rounding error.
Why does the eligible device share drive the break-even more than codec efficiency?
Because codec efficiency is roughly fixed and public, while eligible share is variable and yours. Published figures for HEVC and AV1 are broadly similar across the industry; what differs between two companies making the same codec decision is what fraction of their streams can consume the output. A catalogue where 80% of watch-time comes from recent smart TVs and flagship phones is a different decision from one where 45% of watch-time comes from set-top boxes and older Android devices, even though the codec’s compression ratio is identical in both cases.
Licensing exposure works the same way. It scales with where and how you distribute, not with the codec’s technical merit. Both licensing and hardware-decode coverage are audience properties, and both move the break-even further than a few percentage points of coding gain.
We see this pattern regularly: the codec analysis is done well and the audience analysis is not done at all, so the model is precise about the smaller variable and silent on the larger one.
The decision surface
Measure by watch-time, not by device count. A device population that is 30% AV1-capable but accounts for 60% of watch-hours is a different proposition from the reverse.
| Variable | What to measure | Which way it pushes |
|---|---|---|
| Eligible share (HEVC) | % of watch-time on clients with HEVC hardware decode | High share → switch pays sooner |
| Eligible share (AV1) | % of watch-time on clients with AV1 hardware decode | Usually lower than HEVC today → longer payback |
| Encode cost delta | Streams per accelerator at matched quality, H.264 vs HEVC vs AV1 | Falls with each generation → cost up |
| Delivery saving | Measured bitrate reduction at matched VMAF × eligible watch-time × egress rate | The only ledger with a positive sign |
| Parallel-ladder cost | Duplicate storage + origin/CDN request overhead × rollout months | Longer rollout → worse |
| Licensing exposure | Per-territory, per-distribution-mode obligations | Territory-dependent; can dominate |
| QoE on fallback path | Quality scores per device class on the H.264 ladder | If it degrades, the switch failed |
Reading the table as a rubric: if the delivery saving column does not exceed the sum of the encode delta and the parallel-ladder charge over a horizon you are willing to state out loud, the answer is not yet.
Go, phase, or defer
Three outcomes, and “phase” is the most common correct one.
- Go (full re-encode) — eligible share is high on the target codec, encode capacity exists without new hardware, licensing is settled for your distribution footprint, and the fallback ladder can be retired within the modelled horizon.
- Phase — eligible share is concentrated. Re-encode the top of the audience (the titles that generate the most watch-hours) rather than the top of the catalogue by prestige. This buys most of the delivery saving for a fraction of the encode and storage cost, and it gives you a real measurement before you commit the catalogue.
- Defer — eligible share is low, or unmeasured; encode capacity would require a fleet expansion whose cost exceeds the modelled saving; licensing is unresolved in a major territory; or the QoE baseline per device class does not exist yet, in which case you cannot tell afterwards whether the switch helped.
Defer is a legitimate engineering answer and it should be written down with the condition that would reverse it — “revisit when AV1 hardware-decode watch-time share passes 50%” is a decision; “AV1 later” is not.
What evidence gates the decision
Two artefacts. First, a blended cost-per-stream figure before and after the proposed switch, built from measured encode throughput on your own content at your own presets rather than from vendor benchmarks. Second, a quality-of-experience baseline segmented by device class, so the post-switch comparison is at matched quality rather than matched bitrate. Comparing bitrates alone will always flatter the newer codec; comparing at matched perceptual quality is the only version of the comparison that means anything to a viewer.
The profiling discipline behind both is the same one used in an inference-cost audit — instrument first, attribute cost to specific jobs, then model the change. Applied to video, that becomes the encode-cost-and-device-mix profiling in our Inference Cost-Cut Pack, scoped to transcoding workloads. The broader cost structure of a streaming delivery path, of which codec choice is one lever among several, sits in our media and telecom broadcast engineering work.
Validating the switch after the fact
A codec migration that reduced bitrate and degraded playback is a failure that reads as a success on the finance dashboard for at least one billing cycle. Guard against it by fixing the acceptance criteria before the rollout: VMAF at the rungs viewers actually consume, rebuffer rate and startup time per device class, and the share of sessions landing on the fallback ladder. If the fallback share is higher than your eligibility model predicted, the model was wrong about your audience — which is more useful information than the codec comparison was.
The uncertainty we would name honestly: eligible-share curves move under you. Device populations refresh, browsers ship decoders, and a break-even that fails today can pass in eighteen months without you changing anything. That argues for re-running the model on a schedule rather than treating the codec decision as settled once.
Frequently Asked Questions
What does deciding when to switch codecs (H.264 → HEVC → AV1) for a transcoding workload mean in practice? A common Switch Codecs H 264 question is worth clarifying. It means producing a go/no-go with a named payback horizon rather than a codec preference. In practice you model three ledgers — encode cost per stream, delivery cost per stream on the eligible viewer share, and the cost of maintaining parallel ladders — and compare their net against a horizon you are willing to state.
What costs does a codec migration actually add — encode compute, licensing, storage for parallel ladders — and how do we size each? Encode compute is sized from measured streams per accelerator at matched quality on your own content, not from published encoder benchmarks. Licensing is sized per territory and per distribution mode, because obligations follow distribution rather than technology. Parallel-ladder cost is duplicate storage plus origin and CDN request overhead, multiplied by the number of months both ladders stay live.
How do we measure the eligible viewer share for HEVC or AV1 hardware decode, and why does that share drive the break-even more than codec efficiency? Measure it as a share of watch-time on clients with hardware decode for the target codec, not as a share of device count. It dominates the break-even because codec efficiency is roughly the same for everyone and publicly known, while eligible share varies enormously between two companies facing the identical codec choice.
When is a phased rollout (top-of-catalogue or top-of-audience first) better than a full re-encode, and how long do we keep both ladders live? Phase when eligible share is concentrated rather than broad, and phase by top-of-audience — the titles generating the most watch-hours — rather than by catalogue prestige. Keep both ladders live until fallback-path session share drops below the threshold you set in the model, and treat the dual-ladder period as a standing cost with a named end date.
How much encoder throughput do we lose per accelerator moving from H.264 to HEVC to AV1, and what does that do to fleet sizing? Throughput per accelerator falls as codec complexity rises, because HEVC adds search and prediction work and AV1 adds more again — so the figure must be measured on your content and presets rather than assumed. The consequence is that a codec switch is also a fleet-sizing decision: fewer concurrent streams per card means either more accelerators or a longer encode window.
What evidence should gate the go/no-go decision, and what would make us defer a codec switch entirely? Two artefacts gate it: a blended cost-per-stream model before and after, built from measured encode throughput, and a quality-of-experience baseline segmented by device class. Defer when eligible share is low or unmeasured, when encode capacity would need a fleet expansion costing more than the modelled saving, when licensing is unresolved in a major territory, or when no QoE baseline exists to judge the outcome against.
How do we validate that a codec switch improved quality-of-experience rather than only reducing bitrate? Compare at matched perceptual quality, not matched bitrate — VMAF at the rungs viewers actually consume, alongside rebuffer rate and startup time per device class. Also track the share of sessions landing on the fallback ladder; if it exceeds what the eligibility model predicted, the audience assumption was wrong even if the bitrate saving materialised.
Codec migration ROI in four numbers
Calculate bandwidth savings, encoder cost increase, client compatibility loss, and migration engineering time—if payback exceeds fourteen months, defer the switch.
