TL;DR
AOMedia released the AV2 reference encoder (1.0.0) at the end of May 2026. It’s real, it’s about 30% more efficient than AV1 on paper, and you cannot ship it yet: the encoder is slow, there’s no FFmpeg support, and no hardware decoders in the wild. This post shows what to run today instead: probe your AV1 hardware support, build a clean AV1+H.264 ladder with FFmpeg, and wire a one-line canary so you know the day AV2 becomes worth touching.
📦 Code: github.com/USER/av2-reality-check, replace before publishing
The news, in one paragraph
AOMedia published AV2 reference software 1.0.0 (the AOM Video Model) on May 28, 2026, with the spec announcement in early June. Developer evaluations put it around 28.6% smaller than AV1 by PSNR-YUV and 32.6% by VMAF at equal quality, past 40% on screen content. Royalty-free, same as AV1. Great. Now the catch: the encoder is slow by design (it’s a reference implementation, not a production one), there’s no FFmpeg integration yet, and no shipping hardware decoders. That combination means AV2 is a “read the release notes” event, not a “change your pipeline” event.
If you’ve been through the AV1 rollout, this rhymes exactly. So let’s spend the effort where it pays off in 2026.
1. Probe what your machines can actually do 🔍
Before touching codecs, find out what your encode boxes support. FFmpeg is the source of truth.
# What AV1 encoders does this build expose?
ffmpeg -hide_banner -encoders | grep -i av1
# Typical output on a 2026 build:
# V....D libsvtav1 SVT-AV1 (codec av1)
# V....D libaom-av1 libaom AV1 (codec av1)
# V....D av1_nvenc NVIDIA NVENC av1 encoder (codec av1)
# V....D av1_qsv AV1 (Intel Quick Sync Video) (codec av1)
# V....D av1_vaapi AV1 (VAAPI) (codec av1)
# And confirm AV2 is NOT here yet (it won't be):
ffmpeg -hide_banner -encoders | grep -i av2 || echo "no av2 encoder, expected in 2026"
Enter fullscreen mode Exit fullscreen mode
If you see av1_nvenc, av1_qsv, or av1_vaapi, you have hardware AV1 encoding available, which is the difference between AV1 being practical and AV1 being an overnight batch job. Check for hardware:
# NVIDIA: is the AV1 encode session available?
ffmpeg -hide_banner -f lavfi -i testsrc=size=1280x720:rate=30 -t 2 \
-c:v av1_nvenc -y /tmp/av1_hw_test.mp4 && echo "AV1 NVENC works"
Enter fullscreen mode Exit fullscreen mode
2. The mistake to avoid: software-decode AV1 on phones
The single most common AV1 own-goal is serving AV1 to every browser that claims support, without checking whether the device decodes it in hardware. Software-decoding AV1 on a phone cooks the battery and throttles. Detect real support on the client instead:
// client: prefer AV1 only when the device is likely to hardware-decode it
async function preferAv1() {
if (!("mediaCapabilities" in navigator)) return false;
const cfg = {
type: "media-source",
video: {
contentType: 'video/mp4; codecs="av01.0.05M.08"',
width: 1920, height: 1080, bitrate: 3_000_000, framerate: 30,
},
};
const info = await navigator.mediaCapabilities.decodingInfo(cfg);
// "smooth" + "powerEfficient" is your best proxy for hardware decode.
return info.supported && info.smooth && info.powerEfficient;
}
Enter fullscreen mode Exit fullscreen mode
⚠️
powerEfficientis the key field. A device can reportsupported: truewhile decoding in software, which is worse than just serving H.264. Gate AV1 onpowerEfficient, not onsupported.
3. Build a ladder you can ship today 🎞️
Multi-codec adaptive delivery is the actual 2026 state of the art: AV1 for devices that hardware-decode it, H.264 for everyone else. Here’s a two-codec, three-rung ladder with SVT-AV1 (fast, tunable) and libx264 as the universal fallback.
#!/usr/bin/env bash
# build-ladder.sh, AV1 (svt-av1) + H.264 (x264), keyframe-aligned for clean ABR
set -euo pipefail
IN="$1"
GOP=48 # 2s at 24fps; keep identical across every rung so ABR switches cleanly
for rung in "1920x1080:av1:0" "1280x720:av1:0" "854x480:h264:0"; do
IFS=":" read -r size codec _ <<< "$rung"
if [ "$codec" = "av1" ]; then
ffmpeg -y -i "$IN" -vf "scale=$size" \
-c:v libsvtav1 -preset 7 -crf 30 \
-g $GOP -keyint_min $GOP -sc_threshold 0 \
-svtav1-params "film-grain=8" \
-c:a libopus -b:a 128k "out_${size}_av1.mp4"
else
ffmpeg -y -i "$IN" -vf "scale=$size" \
-c:v libx264 -preset veryfast -crf 21 \
-g $GOP -keyint_min $GOP -sc_threshold 0 \
-c:a aac -b:a 128k "out_${size}_h264.mp4"
fi
done
echo "ladder built. package to HLS/DASH with codec-separated variant streams."
Enter fullscreen mode Exit fullscreen mode
Two details that matter more than the codec choice:
-
Keyframe alignment.
-gand-keyint_minequal, and-sc_threshold 0, on every rung. If GOPs don’t align across renditions, ABR switches stutter no matter how good your codec is. -
Grain synthesis.
film-grain=8in SVT-AV1 lets the encoder model grain instead of spending bitrate encoding it. On noisy source that’s a real saving, available now, no AV2 required.
4. Wire the canary for AV2 🪝
You want to know the moment AV2 becomes worth an experiment. The signal is FFmpeg support landing. Drop this in CI or a weekly cron:
#!/usr/bin/env bash
# av2-watch.sh, pings you when your ffmpeg build grows an av2 encoder
if ffmpeg -hide_banner -encoders 2>/dev/null | grep -qi 'av2\|libaom-av2\|libavm'; then
echo "AV2 encoder detected in ffmpeg, time to run experiments"
exit 0
fi
echo "no av2 encoder yet ($(date +%F))"
Enter fullscreen mode Exit fullscreen mode
# terminal output today:
$ ./av2-watch.sh
no av2 encoder yet (2026-08-03)
Enter fullscreen mode Exit fullscreen mode
When that flips, you experiment. You do not put it under production traffic, because a fast software encode still leaves the decode side unsolved. AV2 becomes a real default only when a critical mass of your viewers have hardware decoders, and following AV1’s timeline that trails the spec by a couple of years.
5. If you truly need more compression right now
There’s exactly one next-gen codec further along than AV2 in 2026, and it’s VVC (H.266). It buys AV2-like efficiency over HEVC, but browser support is effectively nonexistent and it is not royalty-free, so its realistic home is smart TVs and set-top boxes where you own the decoder. Same shape of constraint AV2 will have, just earlier. For general web audiences, a well-tuned AV1+H.264 ladder is still the move.
What’s next
Run build-ladder.sh on a representative asset, compare the AV1 rung against your current H.264-only output with ffmpeg-quality-metrics (VMAF), and see how much bandwidth a tuned AV1 ladder saves you today. Keep av2-watch.sh running. The ceiling went up this summer; the work that pays off before AV2 is shippable is the ladder you’re serving right now.
답글 남기기