DEV Community

Mason K
Mason K

Posted on

AV2 shipped its 1.0 encoder. Here's what to actually run in your pipeline instead.

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

⚠️ powerEfficient is the key field. A device can report supported: true while decoding in software, which is worse than just serving H.264. Gate AV1 on powerEfficient, not on supported.

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. -g and -keyint_min equal, 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=8 in 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.

Top comments (0)