Speed

Single-thread encode speed of every preset and reference on an Arm core and an x86 core, the browser (WebAssembly) build, hardware encoders for scale, and how our decoders compare with the established ones.

Encode, one core

Encode CPU time per frame at 720p, one thread, at a fixed quantizer chosen for each encoder to land near the chart's middle rung on three development clips; real-time CBR costs our encoders slightly more. The Jetson core's clock is locked; the PC is a shared machine, so each PC run is paired with an x264 run in the same round, and differences of a few percent there are noise.

In the browser (WebAssembly)

Frames per second of the browser build on one PC core, single-threaded (the module has no threads), under V8 (node, cross-checked in headless Chromium). Decode: our CBR streams, decode alone. Encode: the demo's settings and its whole encode call (RGBA in). In brackets, the WebAssembly time over the native build's on the same streams. Fast only where the demo offers it.

Browser encode against ffmpeg.wasm

Encode speed of our browser module and of the official single-thread ffmpeg.wasm (x264), on one PC core in the same session: one 720p clip at the chart's middle rung. ffmpeg.wasm is a generic build without SIMD, so it is a weak yardstick for what a SIMD port of x264 would reach; no estimate of such a port is plotted. Quality is the chart's point for the same encoder and preset (the held-out fresh clips against x264 --tune psnr, native builds); the browser runs were not scored themselves. Lower is fewer bits, right is faster.

Decoders against the established ones

Our decoders' time per frame against FFmpeg (H.264, HEVC; also VP9 in brackets), dav1d (AV1), vpxdec (VP9), VVdeC (VVC) and avmdec (AV2, a research reference decoder not built for speed) natively, and in the browser against ffmpeg.wasm (no SIMD; it has no AV1, VVC or AV2 decoder), every decoder with one thread, though the references are normally run multi-threaded and are faster that way. Streams: ours, and third-party ones (x264, openh264, x265 with B-frames, IP cameras, SVT-AV1, libaom, vpxenc). Below 1 means ours took less time. Every native output matched its reference decoder's. The PC was loaded during this run: read its ratios as rough and its WebAssembly times as upper bounds; the Jetson core was otherwise idle.

Hardware encoders, for scale

NVIDIA NVENC on an RTX 5090 GPU in the same low-delay CBR on the development clips. Its speed is GPU wall-clock time with frames already in GPU memory, not CPU time, so it is not comparable with the tables above; the zero line here is the default-tuned x264 medium.