VP9 vs AV1: When Does Migration Now Pay?

AV1 migration became practical as hardware decoding spread through newer phones, PCs, streaming boxes, smart TVs, and GPUs between 2020 and 2025. What changed was playback cost, not the codec specification: supported devices could finally decode AV1 without hammering the CPU or draining a battery through software decoding.

The codec itself is not new

The Alliance for Open Media released the first AV1 bitstream specification in 2018, and its current AOMedia Video specification↗ still defines an open, royalty-free video codec designed for internet delivery. Browser and service support arrived before universal silicon support, which left early deployments serving AV1 mainly to desktops powerful enough to decode it.

That bottleneck has eased. Intel added fixed-function AV1 decoding with 11th-generation Core graphics, Nvidia included it in GeForce RTX 30-series GPUs, AMD followed with RDNA 2, and modern mobile and television chipsets increasingly carry dedicated decoders. Apple added AV1 hardware decoding to the A17 Pro and M3 generation, though capability still varies across its installed base.

Broad does not mean universal

Older devices remain the expensive exception. A 2018 smart TV, low-end Android handset, office PC, or inexpensive set-top box may support VP9 well but lack AV1 decoding capabilities. Some can decode modest AV1 streams in software; high-resolution streaming at 4K, HDR, or 60 frames per second is a different proposition.

This is why device compatibility must be measured from playback telemetry. A hardware support list describes products sold, while session data describes products still being used.

A sensible planning range is roughly 15 to 30 percent less bitrate than VP9 at comparable visual quality, not a guaranteed 30 percent cut across every title. The result moves with encoder, preset, resolution, grain, animation, frame rate, and the quality metric used to declare a tie.

The headline number needs context

It is common to read that AV1 achieves approximately 30% better compression than VP9. That figure is plausible for selected test sets and encoder settings, but codec compression efficiency is not a fixed property like a file header version.

Clean animation can compress exceptionally well. Film grain, concert lighting, sports, rapid camera movement, screen text, and already damaged source material produce different outcomes. An AV1 encode tuned for maximum compression may also require far more processing than a faster preset that saves only a modest amount of bandwidth consumption.

Measure the delivered ladder

Compare complete adaptive bitrate ladders rather than one 1080p sample. The useful number is bytes delivered per viewing hour after accounting for resolution switching, startup behavior, abandoned sessions, and fallback traffic.

• Encode the same mezzanine files with production VP9 and candidate AV1 settings.
• Match visual quality with VMAF, SSIMPLUS, or another consistent metric, then inspect difficult scenes by eye.
• Package equivalent HLS or DASH ladders.
• Weight each rendition by actual watch time.
• Add CDN request and storage charges before calling the result a saving.

AV1 provides better compression efficiency than VP9 often enough to matter at scale. It does not repeal the bill for video encoding.

Encoding cost erases the gain when a title receives too few viewing hours to repay the extra compute, engineering, validation, and storage. Large streaming platforms can amortize a resource-intensive encode over millions of plays; a long-tail library often cannot.

Use break-even viewing hours

The decision can be reduced to a serviceable equation:

If AV1 costs $12 more to encode and validate, while reducing CDN charges by $0.0015 per viewing hour, the title needs 8,000 AV1 viewing hours to break even. Change the CDN rate, cache-hit pattern, bitrate ladder, or regional traffic mix and the answer changes with it.

Encoding cost is only one line item. Include orchestration, failed jobs, quality control, additional manifests, player testing, origin storage, cache duplication, and incident response. The storage component is usually smaller than teams fear, but a second codec can reduce cache density when requests split between VP9 and AV1 objects.

Live video has harsher limits

Real-time applications cannot casually exchange ten times more compute for smaller files. Live encoders operate against a deadline, and faster AV1 modes surrender some improved compression. Hardware encoders help, but their output should be compared with the existing VP9 live path rather than a slow offline AV1 reference encode.

For small catalogs or lightly watched archives, I would keep VP9 and revisit the calculation when traffic changes.

Viewers on metered, congested, or bandwidth-limited connections benefit most from smaller AV1 renditions, provided their device has hardware decoding. Viewers using older devices may get smoother playback from VP9 because efficient decoding matters more than a smaller compressed video stream.

Segment by capability, not user agent alone

Playback selection should combine codec declaration, device capability, operating system, browser or app version, resolution, HDR mode, and observed decode performance. The web platform exposes codec support imperfectly, and a positive answer can mean software decoding rather than low-power silicon.

Current browser codec compatibility data↗ shows wide AV1 coverage in current browser families, but browser support does not prove that every underlying machine can play 4K AV1 smoothly. Android documentation likewise distinguishes supported media formats from the behavior of a particular product; its video format guidance↗ is a floor, not a catalog of every chipset.

Watch the failure signals

• Sustained dropped frames indicate that nominal support is not sufficient.
• High CPU use can turn better compression into shorter battery life.
• Slow startup may point to oversized segments, manifest logic, or decoder initialization.
• Frequent downshifts can erase the promised high-quality video gain.
• A fallback request immediately after AV1 selection often exposes a false capability report.

Smart TVs deserve their own cohort. Model names are inconsistent, firmware updates are uneven, and television hardware remains in homes far longer than phones.

Do not re-encode an entire VP9 library merely because new clients support AV1. Encode new and popular titles first, then backfill older assets only when predicted delivery savings clear a title-level break-even threshold.

Start with the hot set

A small fraction of a catalog usually generates most viewing hours. Those titles repay AV1 preparation quickly and provide enough traffic to expose playback failures without placing the whole service at risk.

Use source mezzanines whenever they exist. Transcoding VP9 into AV1 compounds compression damage, particularly around grain, gradients, text, and motion. A smaller file is not a win if the migration compromises quality or forces a higher AV1 bitrate to hide generation loss.

Keep the fallback boring

A dual-codec library needs deterministic selection. Serve AV1 to proven-capable clients and retain VP9 for older devices, uncertain decoders, and applications that have not passed validation. The VP9 codec is better suited for HD/4K or VR videos only where its mature decode path outweighs AV1's bitrate advantage; that is a fleet decision, not a universal codec rule.

Re-encoding is most attractive when:

• The source master is available.
• The title has substantial forecast watch time.
• Delivery charges dominate storage charges.
• The audience has high AV1 device compatibility.
• Quality control can cover the content type.

Archive completion is a poor business metric. Cost per successful viewing hour is the one that matters.

A staged rollout should measure total cost per successful play, playback reliability, and quality by device cohort. Bitrate reduction alone cannot tell you whether AV1 improved the service.

Confirmed measurements

Start with a small percentage of eligible sessions and maintain a VP9 control group. Record:

• Average delivered bitrate by resolution and content class.
• Startup time and time to first frame.
• Rebuffering ratio and bitrate switches.
• Dropped frames and decode errors.
• CPU load, battery impact, and thermal throttling where clients expose them.
• CDN bytes, cache-hit ratio, origin egress, and request count.
• Encode time, failed jobs, and quality-control labor.
• Fallback frequency by model, browser, app, and operating system.

The first two sentences of a player error report rarely name the real fault. A generic media decode failure can come from an unsupported profile, level, pixel format, bit depth, HDR combination, audio track, or container feature rather than AV1 itself.

Expected benefits

Expect reducing bandwidth consumption to help mobile and constrained-network cohorts first. Expect the financial return to concentrate in heavily watched titles and expensive delivery regions. Treat both as hypotheses until the experiment shows lower total delivery costs without worse smooth playback.

For a nearby comparison with another high-efficiency codec, see AV1 and H.265 delivery trade-offs.

SmartTube can expose codec preferences and playback diagnostics, but it cannot add an AV1 hardware decoder to a television or streaming box. On unsupported hardware, forcing AV1 may increase CPU load, dropped frames, heat, or fallback behavior even when the stream uses fewer bits.

Treat the selector as a diagnostic

The useful comparison is the same video, resolution, frame rate, and HDR mode under both codecs. Check the reported codec, dropped frames, buffer health, and sustained playback rather than assuming that the AV1 label means a better result.

Application behavior can also change between releases because stream selection depends on YouTube formats, player logic, and device APIs. SmartTube is not a representative deployment test for a publisher's web, mobile, and connected-TV audience. It is one client on one class of device.

If VP9 plays 4K60 cleanly and AV1 stutters, choose VP9. Better compression has no value after the decoder misses its presentation deadline.

In 2026, AV1 is worth adding for new encodes and high-traffic catalog titles when telemetry shows capable hardware and delivery savings exceed the full dual-codec cost. A VP9 shutdown is usually premature because installed smart TVs, set-top boxes, browsers, and low-cost devices still make fallback valuable.

What is confirmed

AV1 is widely supported across current product lines, offers better compression at matched quality in many workloads, and remains open-source and royalty-free through the AOMedia licensing framework. VP9 is also a mature royalty-free video technology with broad deployment, fast encoders, and an enormous working device base.

The practical comparison is no longer whether AV1 can replace VP9 technically. It can. The question is whether a particular service has enough compatible viewing hours to pay for another ladder.

What is expected

AV1's share should rise as pre-2020 hardware ages out, fixed-function encoders improve, and streaming platforms refine per-title settings. Encoding will get cheaper. The uncertain part is pace: television replacement cycles are slow, and services with regional or budget-device audiences will carry VP9 longer than premium mobile-first services.

The decision rule is blunt. Add AV1 where it lowers the cost of a successful, high-quality play. Keep VP9 everywhere else.