FFmpeg x264 presets compared
Compare all nine x264 presets on one file with real encode times and output sizes. The slower presets are not monotonically smaller, and one is backwards.
Abdelrahman Essawy 4 MIN READEveryone 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.
| Variant | Encode | Size | Cost |
|---|---|---|---|
| ultrafast | 238 ms fastest | 2185.1 KB | $0.0029 |
| superfast | 388 ms | 732.2 KB | $0.0024 |
| veryfast | 542 ms | 388.4 KB | $0.0021 |
| faster | 737 ms | 440.0 KB | $0.0022 |
| fast | 985 ms | 463.1 KB | $0.0025 |
| medium | 1912 ms | 433.0 KB | $0.0039 |
| slow | 2450 ms | 422.8 KB | $0.0040 |
| slower | 2685 ms | 358.6 KB | $0.0041 |
| veryslow | 4635 ms | 329.5 KB | $0.0062 |
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.
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.
Frequently asked questions
Which x264 preset should I use?
medium is a sensible default and veryfast is worth measuring against it, because on our clip veryfast produced a smaller file than faster, fast, medium and slow. Choose by measuring your own content, since the size ordering in the middle of the range is not reliable.
Does a slower x264 preset always give a smaller file?
No. At a fixed CRF the encoder targets quality rather than size, so a slower preset can find more detail worth spending bits on. We measured veryfast at 388 KB against fast at 463 KB, which inverts the usual assumption.
How much bigger is ultrafast?
On our 5-second 720p clip ultrafast produced 2,185 KB against veryslow's 330 KB, which is 6.6x the bytes. That gap is far outside measurement noise and is the one preset difference you can rely on.
Is preset the same as CRF?
No. CRF sets the quality target and preset sets how hard the encoder searches to hit it. They are independent, and changing preset at a fixed CRF changes both the time and the resulting size.