# FFmpeg tune presets compared

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

---

## Key takeaways

- -tune zerolatency produced 955.5 KB against no tune's 433.0 KB. That is 2.2x the bytes, and it is the flag people enable for live streaming without pricing it.
- -tune fastdecode produced 725.7 KB, 1.7x the baseline. Both of the performance tunes are the expensive ones.
- -tune animation was the only value that made the file smaller, at 404.9 KB, a 6.5% saving.
- -tune stillimage produced 536.6 KB, 24% larger, which is the opposite of what the name suggests to most people.
- Sizes here are exact and repeatable. The timing column is a single sample each and should not be read closely.

`-tune` looks like a free hint to the encoder about your content. Two of its
values are not free at all, and they are the two most likely to end up in a
streaming config.

Short version. **`-tune zerolatency` costs 2.2x the bytes.** `-tune fastdecode`
costs 1.7x. Only `-tune animation` made the file smaller.

## The two performance tunes are the expensive ones

| Tune | Size | vs baseline |
|---|---:|---:|
| animation | 404.9 KB | **−6.5%** |
| none | 433.0 KB | — |
| film | 446.6 KB | +3.1% |
| grain | 450.0 KB | +3.9% |
| stillimage | 536.6 KB | +24% |
| fastdecode | 725.7 KB | **+68%** |
| zerolatency | 955.5 KB | **+121%** |

`zerolatency` more than doubles the output. That is the cost of what it actually
does: it disables lookahead, B-frames and frame-based threading so that the
encoder never holds a frame back. Every one of those features exists to improve
compression, so turning them all off costs compression.

`fastdecode` is the same shape for the same reason. It disables CABAC, loop
filtering and weighted prediction to make the *decoder's* job cheaper, and each
of those is a compression tool.

Neither flag is misnamed. They do exactly what they say. The problem is that
"tune for low latency" reads like a scheduling hint and behaves like a 121%
bitrate increase.

## Where this bites

`-tune zerolatency` is in a very large number of live-streaming configs, usually
copied from a tutorial, and often on a pipeline that is not actually
latency-sensitive.

If you are doing genuine realtime, sub-second interactive video, you need it and
the bitrate is the price. If you are streaming to HLS with a six-second segment
buffer, you have already accepted seconds of latency and `zerolatency` is buying
you nothing while costing you **121% of your bandwidth**.

That is the single most expensive default in this sweep, and it is one word in a
command line.

## animation is the only one that pays

**404.9 KB against 433.0 KB**, a 6.5% saving.

`animation` raises deblocking strength and adjusts psychovisual settings for
content with flat colour areas and hard edges, which compresses better under
those settings. On actual animation the saving is usually larger than what we
measured on live-action footage, so treat 6.5% as a floor for the right content
type.

`film` and `grain` both made the file slightly *larger*, by 3.1% and 3.9%. That
is intended: `grain` in particular tells the encoder to preserve grain rather than
smooth it away, and preserving detail costs bits. You use it because you want the
grain, not to save space.

## stillimage is not for still images

**+24%**, which surprises people.

It is tuned for slideshow-type content, long static shots with occasional
changes, and it raises quality on the static portions rather than reducing size.
If you want a smaller file from a static source, a longer keyframe interval and a
higher CRF will do far more than this flag, and
[FFmpeg keyframe interval compared](/blog/ffmpeg-keyframe-interval-cost/) shows
the size of that lever.

## Read the sizes, not the times

The encode-time column here is a single sample per variant, and repeated runs of
one identical command on this infrastructure vary by up to 2x when threading is
left on auto, which it is here. So `animation` appearing to take 2,045 ms against
`no tune`'s 912 ms is not a result worth quoting.

The sizes are exact. They were produced by a deterministic encoder and would come
out identical on a re-run. That asymmetry is
covered in [FFmpeg benchmark variance](/blog/measurement-noise-ffmpeg-benchmarks/)
and it applies to every benchmark on this site.

## Where this stops

One 5-second 1280x720 live-action clip, libx264 CRF 23 preset medium, audio
stripped. `-tune` is explicitly content-dependent, so the ranking will move on
other footage: `animation` on real animation and `grain` on genuinely grainy film
will both behave differently from what live-action shows.

The two findings that will not move are the mechanical ones. `zerolatency` and
`fastdecode` disable compression features by design, so they cost bytes on any
content.

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