r/AV2 • • 7h ago

AV2 reference encoder (AVM) on Intel P-cores vs E-cores: E-cores are half as fast, but still add ~50% throughput

Thumbnail
gallery
5 Upvotes

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


r/AV2 • • 17h ago

I benchmarked all AVM's `--cpu-used` presets

Thumbnail
gallery
5 Upvotes

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.