SVT-AV1 presets, 4x the time for a fifth fewer bytes

Over three runs each, SVT-AV1 preset 4 took 3.9x as long as preset 12 and wrote a file about a fifth smaller. Unlike most sweeps on this blog, the timings repeated within a few percent, so the speed column is readable. What the sweep cannot tell you is which preset gives the best quality per byte, because at a fixed CRF the preset changes quality too, and quality was not scored.

ffmpeg -i in.mp4 -c:v libsvtav1 -crf 35 -preset 8 -an out.mp4

Each variant changes only -preset. The clip, the FFmpeg build (versions were not recorded per run) and the timing rules are on the benchmark methodology page.

Variant	Encode	Size	Cost
preset 4	2399 ms	174.6 KB	$0.0058
preset 6	1585 ms	197.3 KB	$0.0043
preset 8	1105 ms	224.4 KB	$0.0028
preset 10	653 ms	229.7 KB	$0.0021
preset 12	614 ms fastest	219.7 KB	$0.0021

Measured 2026-08-20 on the Rendobar API. Encode time is the FFmpeg step alone, separated from download and upload. 5 of 5 runs succeeded. Sizes are exact and repeatable. Timings are the median of 3 runs, and cost is from the first run. Why.

The time in the component is the median of three runs. Here is the spread behind each median:

The size column is not ordered#

Preset 10 wrote a larger file than preset 8 and preset 12. Preset 12 was 2% smaller than preset 8 and 1.8x faster, and its three runs never overlapped preset 10’s.

On size and speed alone that makes preset 12 look like the better choice. It is not a result I would ship on. -crf asks for a quality level, and each preset reaches for it with a different search, so the file size at a fixed CRF is a side effect. A faster preset that writes a smaller file may simply be keeping less detail. The same inversion shows up in the x264 preset sweep, and it has the same explanation.

To choose between two presets, hold one axis fixed and score the other. Encode both at the same file size and compare VMAF, or at the same VMAF and compare size. This sweep did neither.

The speed dial, in time per second of video#

Preset 4 took 2.2x as long as preset 8 and wrote a 22% smaller file. In absolute terms, preset 4 spent about 1.3 seconds more on each 5-second clip, roughly a quarter of a second of extra encode per second of 720p video on this runner.

Whether that is worth it depends on how often a file is watched. Go slower when you encode once and serve many times, since the bytes are paid on every view. Go faster when most of a library is never watched. The full range from preset 4 to 12 is narrower in size than AV1’s reputation suggests, though again, at unscored quality.

These timings repeat, and that is unusual here#

Every preset landed within 1.3% to 3.4% of itself across three runs, with no thread pinning. The same libx264 command on its default threading has swung 85% on identical work, which is the finding FFmpeg benchmark variance documents.

I have not isolated why SVT-AV1 behaves differently. It manages its own parallelism, set by the lp parameter in its documentation, and that is the likely reason, but this sweep does not prove it. Output sizes were identical across all three runs of every preset.

Presets 0 to 3 were not measured. They are slow enough that three runs each would have made the sweep far slower to run.

Repeating each preset three times was the cheap part: every run is one API call, so the repeats were one loop with a counter, and the size check came free with them.

I would start an AV1 pipeline at preset 8, then encode a sample of real content at 8 and at 12 to the same size and let VMAF decide. If 12 holds up, the 1.8x is yours for nothing.