# FFmpeg x264 presets compared

Canonical: https://rendobar.com/blog/x264-presets-measured/
Author: Abdelrahman Essawy
Published: 2026-08-20
Updated: 2026-08-20

---

## Key takeaways

- ultrafast produced a file 6.6x larger than veryslow (2,185 KB against 330 KB) while encoding 19x faster. That is the whole tradeoff in one line.
- veryfast produced a SMALLER file than faster, fast, medium and slow. At CRF 23 the size curve is not monotonic, and sizes are exactly repeatable.
- Going from medium to veryslow saved 24% of the bytes. It cost more time, but repeated runs put medium anywhere from 898 to 1,912 ms, so the multiple is not quotable.
- This is one 5-second 720p clip. The ranking of adjacent presets will move on other content; the ultrafast-to-veryslow spread will not.
- The whole sweep cost $0.0304 to run, which is why nobody publishes these numbers and why we did.

Everyone repeats the same advice about x264 presets: slower is smaller, pick
`medium` unless you have a reason. We ran all nine on the same file and one of
them is not like the others.

Short version, so you can leave if that is all you needed. `ultrafast` is a
genuinely different animal and everything from `veryfast` down is within about
30% of the same size. At CRF 23 on this clip, `veryfast` beat four presets
slower than itself on file size while taking a fraction of their encode time.

## The two ends behave exactly as advertised

`ultrafast` produced **2,185 KB**. `veryslow` produced **330 KB**. That is
**6.6x** the bytes for **19x** less encode time, and it is the reason nobody
ships `ultrafast` for anything that gets stored or streamed. It is a preset for
capture and for intermediates, where you are trading disk for latency on
purpose.

At the other end, `veryslow` saved **24% of the bytes** against `medium`, and it
took substantially longer. How much longer is harder to state than it looks:
`medium` measured between 898 and 1,912 ms across repeated runs of the same
command, so the honest range is somewhere between 2.4x and 5x rather than a
figure.

Whether that trade is worth it depends entirely on how many times the file will
be downloaded. Encode once, serve a million times, and 24% is enormous. Encode a
million times, serve once, and it is a bad trade.

## The middle is where the received wisdom breaks

Here is the part that surprised us. Reading down the size column from
`veryfast`:

| Preset | Encode | Size |
|---|---:|---:|
| veryfast | 542 ms | **388 KB** |
| faster | 737 ms | 440 KB |
| fast | 985 ms | 463 KB |
| medium | 1,912 ms | 433 KB |
| slow | 2,450 ms | 423 KB |

`veryfast` produced a smaller file than the four presets below it. `fast`
produced the largest file of the five.

**Read the size column, not the time column.** Repeated runs of one identical
command varied 2.13x in encode time while producing byte-identical output, so
adjacent presets cannot be separated on time by a single sample. Sizes are exact
and repeatable. See [FFmpeg benchmark variance](/blog/measurement-noise-ffmpeg-benchmarks/).

This is not a bug, and it is not FFmpeg behaving strangely. CRF targets constant
*quality*, not constant size. A slower preset spends its extra time finding
better predictions, and it is free to spend the bytes it saves on detail it
previously discarded. Size at fixed CRF is therefore an emergent property, not a
dial, and it is not obliged to decrease monotonically.

The practical reading: **if you are choosing a preset by output size at a fixed
CRF, measure it on your own content.** The rule of thumb is reliable at the ends
of the range and unreliable in the middle, which is exactly where most people
are choosing.

## What it cost to find out

Every row above is a real job. The nine encodes cost **$0.0304** in total and
the slowest took under five seconds of actual FFmpeg time.

That is the honest reason this comparison is rare rather than standard. It is
not difficult, it is just nobody's job: you need somewhere to run twenty-odd
encodes, a way to time the encode separately from the file transfer, and a
willingness to publish a number that contradicts the advice everyone repeats.

## Where this stops

**This is one clip.** Five seconds, 1280x720, H.264 source, audio stripped so
the numbers are pure video. On a different source, particularly one with more
motion or more grain, the adjacent presets will reorder. Grain especially
punishes fast presets in ways a short clean clip does not show.

**And it is one sample per preset.** Sizes are deterministic, so the size column
is solid. Timings are not: the same command varies by more than 2x run to run,
which is wider than the gap between several adjacent presets here.

What will not change on other content is the shape: a large cliff between
`ultrafast` and everything else, a long flat middle where the differences are
small and not reliably ordered, and a slow tail where you pay real time for
single-digit percentage gains.

If you want the version of this that matters for your pipeline, run the sweep on
your own footage. The commands are in the table above and each one is a single
API call.

Preset is one of seven settings measured on this same source. The rest are in [FFmpeg encoding settings compared](/blog/ffmpeg-encoding-settings/).