I've been encoding AV2 test streams with AVM, the AV2 reference encoder, which is very slow. So I measured how best to spread a batch of encodes over a hybrid laptop CPU: an i7-12700H with 6 P-cores (with hyperthreading) and 8 E-cores.

Each encode used one thread, --cpu-used=6, and was pinned to a single core, using short 270p and 720p clips from the AV2 test set.

• An E-core encodes at about half the speed of a P-core. That held for 8-bit, 10-bit and 720p input, and dropped to about 42% with all cores busy.
• The E-cores still add ~50% throughput. 6 P-cores give 268 frames/min, 6 P + 8 E give 400. The P-cores lose only 4% when the E-cores are busy too.
• Hyperthreading adds 15% on the P-cores alone, but only about 2% once the E-cores are busy. Clocks drop, so it looks like a power limit.
• Pinning barely matters. All layouts using all cores land within 10% of each other. Unpinned, Windows shuffles the encodes between core types, so they all finish around the same time.

My personal take-way is to run 14 single-threaded encodes and let the OS schedule them. If you pin them, put the long encodes on P-cores.

Full write-up with figures, raw data and scripts: https://github.com/EwoutH/AV2/tree/main/perf/2026-10-15-avm-p-vs-e-cores

Earlier test on AVM's speed presets: https://github.com/EwoutH/AV2/tree/main/perf/2026-10-14-avm-preset-sweep

I ran an overnight sweep of the AVM reference encoder (av2-enc branch, 89eae123d). It covers --cpu-used 0–9 on four CTC clips (three at 270p/360p, one at 720p) at QP 110/145/180/210. Each encode used one thread and was scored with PSNR, SSIM and VMAF. BD-rates below are relative to s1.

Main takeaways:

• s6 is the fastest preset. s7–s9 are 8–25% slower than s6 and save at most 2.6% bits. Above 6, a higher number doesn't mean a faster encode.
• The default is s0. If you don't set --cpu-used, avmenc runs 6–11x slower than s1 for about 2% fewer bits on average. On some clips s0 does no better than s1.
• s1 → s6: about 10x faster for 10–14% more bits. One clip (Vertical_Bayshore) loses much more: +25% PSNR, +41% VMAF.
• s3 is a good middle point: 4–5x faster than s1 for 4–9% more bits.
• It's still slow. At s6 on one thread it takes ~1.5–3 s/frame at 270p/360p, ~5 s/frame at 720p and ~15 s/frame at 1080p.
• Inter frames speed up much more than keyframes. At s6 they take 8% of their s1 time; the keyframe takes 13%.

Caveats: the clips are short (33/65 frames, so the keyframe weighs heavily), there are only four clips, and the timings come from a laptop (i7-12700H, MSVC build). The 1080p run didn't finish, so it's shown as same-QP comparisons only.

The write-up, all charts, raw results (JSONL/CSV) and scripts are here: https://github.com/EwoutH/AV2/tree/main/perf/2026-10-14-avm-preset-sweep

Feedback and suggestions for the next run are welcome.

I've published a small set of AV2 test streams, made with the AVM reference encoder from the official CTC test clips. They're meant for testing and benchmarking decoders such as dav2d.

• 10 streams: three small clips (270p and 360p, 130 frames, QP 110/160/210) and seven 720p and 1080p clips at QP 160, with 73 to 240 frames each.
• Decoded MD5s: manifest.txt lists the avmdec --md5 output for each stream, so you can check your decoder's output against it.

Samples and details: https://github.com/EwoutH/AV2/tree/main/samples

Nightly AVM builds (avmenc and avmdec) for Windows, macOS and Linux are at https://ewouth.github.io/AV2/. Each one includes the exact AVM commit it was built from.

Feedback and decoder results against the MD5s are welcome.

I set up nightly builds of AVM, the AV2 reference encoder and decoder, so you can try AV2 without compiling anything:

https://ewouth.github.io/AV2/

• avmenc and avmdec for Windows x64, macOS (Apple Silicon and Intel) and Linux (x64 and arm64)
• Rebuilt automatically whenever AVM's main branch changes; older builds stay available on the releases page
• Standalone binaries, nothing to install

Quick start:

avmenc input.y4m -o output.ivf --ivf --end-usage=q --qp=160 --cpu-used=6
avmdec output.ivf -o decoded.y4m

Things to know: these are unofficial builds, not from AOMedia. AVM is research software and slow, expect seconds per frame at low resolutions and minutes per frame for HD. AV2 is still changing, so a stream from one build may not decode with another; each download includes the exact AVM commit.

Source and build workflow: https://github.com/EwoutH/AV2. Feedback and bug reports welcome.

hi!

I've compiled things before but it was a while ago. I currently have visual studio 2022 and can't seem to get the compile option to not be greyed out. Can anyone help this non-coder to figure out what's wrong? I updated my cmake instance and that allowed me to use build insights to I guess kind of compile it? But no real compile feature. I must be totally missing something. help?

The AV2 spec is out, and I've heard very little in terms of actual adoption. AFAIK there is no talk of AV2 support in any browsers yet, and no support in VLC. I think there is preliminary support in FFMPEG, but I'm not 100% on that.

How close are us nerdy early-adopters to being able to play an AV2 clip?

I wanted AV2 streams to test decoders with, and the only official conformance streams I found are commercial. So I encoded some myself with AVM, the AV2 reference encoder, using clips from the official AV2 test set.

Available now: three low-resolution clips (270p, a vertical 270x480, and 360p), each at three quality levels (QP 110, 160 and 210). Each stream comes with an MD5 of its decoded output from the reference decoder, so you can check whether another decoder produces the same frames.

Caveats:

• These aren't official conformance streams. AV2 is still changing, so they're tied to the AVM commit they were made with.
• They were built on Windows without TensorFlow Lite, which means two encoder experiments were off. Details are in the README.
• 720p and 1080p are coming. AVM currently crashes on those resolutions in my Windows build, but working on it.

The Python script that produces everything is included. It builds AVM, downloads only the needed frames of each source clip, and encodes in parallel within a memory budget.

Link: https://github.com/EwoutH/AV2/tree/main/samples

If you try them with dav2d or another decoder, I'd be interested to hear whether the MD5s match.

"Intel will demonstrate SVT-AV2, an open-source software encoder designed to accelerate AV2 implementation and evaluation across the ecosystem."

Nice!

I've been simmering with this a while now trying to add AV1/AV2 support for older GPUs that don't have hardware encoders. This PoC seems to work with the current AV2 spec. It's not as efficient as current AV1 encoders or SVT-AV1 but it's getting there. Feedback and optimizations welcome if anybody wants to try. Note the webm/matroska container still doesn't support AV2 yet.

https://github.com/jboero/clave

Will there be an SVT-AV2 project? What we do know is that the AVM/AV2 encoder runs extremely slowly, with frame rates in the range of minutes—about a factor of 100 slower than SVT-AV1. This makes it practically impossible to even test it with longer videos. With the decoder, on the other hand, the problems are comparatively minor. I also don’t understand why the developers of AV2 don’t offer a way to access AV1’s fast encoding paths—assuming there is a decoder which has both ways for AV1 and AV2—and thus enable a transitional hybrid approach that sacrifices maximum compression.

AV2 Reference Software (AVM) has moved to Github: https://github.com/AOMediaCodec/avm

Do you have sample files to test decoders ?

dav2d is the fastest AV2 decoder on all platforms :)

Roadmap

The plan is the following:

On-going

1. Complete C implementation of the decoder,
2. Provide a usable API,
3. Port to most platforms,

After

1. Make it fast on desktop, by writing asm for AVX2 chips.
2. Make it fast on mobile, by writing asm for ARMv8 chips,
3. Make it fast on older desktop, by writing asm for SSSE3+ chips,
4. Make high bit-depth fast on mobile, by writing asm for ARMv8 chips.
5. Make it fast on older mobile, by writing asm for ARMv7 chips,
6. Make high bit-depth fast on older mobile, by writing asm for ARMv7 chips,
7. Make high bit-depth fast on desktop, by writing asm for AVX2 chips,
8. Make high bit-depth fast on older desktop, by writing asm for SSSE3+ chips,
9. Improve threading.
10. Improve C code base with various tweaks.
11. Accelerate for less common architectures, like PPC, SSE2, RISC-V or AVX-512.
12. Use more GPU decoding, when possible.

With AV2 incoming, I think that having a different subreddit for each codec dilutes the community. If you are interested in a subreddit that covers not just AV2 but all open-source/royalty-free codecs (including VP8/VP9, Opus, JPEG-XL, etc.) please come join!

The codec was supposed to be finalized by year end, and there are about 10 days left, is the launch/finalization still happening?

Is there a decoder

So stream finally hits https://www.youtube.com/watch?v=RUMwMe_2Dqo

.. And of course no one mentions LTs § PVQs

Does AV2 fix banding? Or am I going to have to suffer through those gnarly compression artifacts in every talking head documentary shot?