FFmpeg tune presets compared
Compare all seven x264 -tune values on one clip. zerolatency produced 2.2x the bytes and fastdecode 1.7x, which is not what a performance flag implies.
Abdelrahman Essawy 4 MIN READ-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.
| Variant | Encode | Size | Cost |
|---|---|---|---|
| no tune | 912 ms fastest | 433.0 KB | $0.0025 |
| film | 1502 ms | 446.6 KB | $0.0030 |
| animation | 2045 ms | 404.9 KB | $0.0036 |
| grain | 1133 ms | 450.0 KB | $0.0026 |
| stillimage | 959 ms | 536.6 KB | $0.0023 |
| fastdecode | 982 ms | 725.7 KB | $0.0024 |
| zerolatency | 1444 ms | 955.5 KB | $0.0029 |
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 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 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.
Frequently asked questions
What does -tune zerolatency cost?
121% more bytes on our clip. It disables lookahead, B-frames and frame threading so the encoder never holds a frame back, and every one of those features exists to improve compression.
Should I use -tune zerolatency for HLS?
Usually not. If your pipeline already buffers seconds of segments you have accepted the latency, so zerolatency is doubling your bitrate for a benefit you are not collecting.
Does -tune ever make files smaller?
animation did, by 6.5% on live-action footage, and the saving is usually larger on actual animation. film and grain both made the file slightly larger, which is intended.
What is -tune stillimage for?
Slideshow-type content with long static shots. It raises quality on the static portions rather than reducing size, and we measured it 24% larger than no tune.