67

The FFmpeg wiki says that the best compression rate is by preset "veryslow".

But when I am trying it with my video then preset veryfast provides the best compression in my case.

The following is the output of my samples:

Preset ultrafast

ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset ultrafast -c:a aac  -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-ultrafast.mp4"

frame= 2822
fps= 65
q=-1.0
Lsize=
239118kB
time=00:01:34.18
bitrate=20797.6kbits/s
speed=2.16x

Preset superfast

ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset superfast -c:a aac  -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-superfast.mp4"

frame= 2822
fps= 63
q=-1.0
Lsize=  150252kB
time=00:01:34.18
bitrate=13068.3kbits/s
speed=2.09x

Preset veryfast

ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset veryfast -c:a aac  -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-veryfast.mp4"

frame= 2822
fps= 62
q=-1.0
Lsize=
115997kB
time=00:01:34.18
bitrate=10089.0kbits/s
speed=2.08x

Preset fast

ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset fast -c:a aac  -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-fast.mp4"

frame= 2822
fps= 52
q=-1.0
Lsize=
133773kB
time=00:01:34.18
bitrate=11635.1kbits/s
speed=1.72x

Preset medium

ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset medium -c:a aac  -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-medium.mp4"

frame= 2822
fps= 43
q=-1.0
Lsize=
124154kB
time=00:01:34.18
bitrate=10798.4kbits/s
speed=1.42x

Preset slow

ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset slow -c:a aac  -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-slow.mp4"

frame= 2822
fps= 27
q=-1.0
Lsize=  125262kB
time=00:01:34.18
bitrate=10894.8kbits/s
speed=0.886x

Preset slower

ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset slower -c:a aac  -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-slower.mp4"

frame= 2822
fps= 14
q=-1.0
Lsize=  125061kB
time=00:01:34.18
bitrate=10877.3kbits/s
speed=0.465x

Preset veryslow

ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset veryslow -c:a aac  -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-veryslow.mp4"

frame= 2822
fps=6.6
q=-1.0
Lsize=  118149kB
time=00:01:34.18
bitrate=10276.2kbits/s
speed=0.221x

Why does preset veryfast generate the most compressed file compared to other presets?

And is the video loss something with preset veryfast?

5
  • What do you mean by the last question? Whether "veryfast" is expected to result in the highest or lowest loss of video quality among the presets (compared to the original)? Jun 1, 2020 at 23:44
  • 2
    "Best compression" is different from "most compressed". In this case, veryfast gave the most compressed file by chance, and probably one of the worst qualities when compared to the original.
    – lvella
    Jun 2, 2020 at 15:03
  • What's up with all the votes on my answer in the last couple days? Did this get linked somewhere? If so, thanks for sharing it :) Jul 16, 2020 at 18:18
  • 1
    @PeterCordes: the SE newsletter
    – guntbert
    Jul 16, 2020 at 20:37
  • In fact Wiki says placebo is the best: "It helps at most ~1% in terms of quality, compared to the veryslow preset at the cost of a much higher encoding time." Also, you should not use mp4 container for comparison. Encode directly to Annex B files, i.e. .264. If that is still a problem in newest FFnpeg and newest x264, report it to trac.ffmpeg.org. Mar 12, 2023 at 22:49

3 Answers 3

120

Lossy compression is a tradeoff between bitrate (file size) and quality, not just about getting the smallest files. If that's all you wanted, use -preset veryslow -crf 51 (and optionally downscale to 256x144) to get a very tiny file that's mostly just blurred blobs with no detail.

Encoding is a 3-way tradeoff of CPU time against quality against bitrate, very different from lossless compression like zip where file size is how you measure "best" compression, and is what you trade off vs. time in a 2-way tradeoff.1 Or 3-way if compression and decompression speed are independent...

-preset veryslow gives you the best tradeoff x264 can offer2, by spending more CPU time searching for ways to represent more detail per bit. (i.e. best tradeoff of rate per distortion).

This is mostly orthogonal to rate-control, which decides how many total bits to spend. x264's default rate-control is CRF 23 (ffmpeg -crf 23); if you want smaller files, use -preset veryslow -crf 26 or something to spend fewer bits for the same complexity, resulting in more blurring. It's logarithmic so bumping up the CRF by a few numbers can change the bitrate by a factor of 2. For nearly transparent quality, -crf 18 or 20 is often good, but costs more bitrate.


CRF mode is not true constant-quality (SSIM, PSNR, or any other metric). With faster encoding presets, x264 uses a simpler decision-making process to decide how / where to spend bits, resulting in some variation in bitrate for the same CRF setting.

With different search tools to find redundancy as @szatmary explains, a higher preset might find a much smaller way to encode something that only looks slightly worse. Or a way to encode some blocks that looks much better but is only slightly larger. Depending which way these things go on average, the same CRF at different quality presets will have different quality and different bitrate.

That's why you don't get progressively smaller files at identical quality; -preset veryfast typically looks worse at the same CRF. -preset ultrafast is usually noticeably bad even at high bitrate / low CRF, but other presets can look as good as veryslow if you spend much more bitrate.

Smaller file doesn't mean "better compression". Remember that quality is also variable. If you used ffmpeg -i in.mp4 -ssim 1 -tune ssim -preset veryslow out.mkv to get libx264 to calculate the SSIM visual quality metric, you'll find that veryslow has better quality per bitrate than veryfast. (If you're benchmarking quality, do it at fixed bitrate, i.e. 2-pass not CRF. See https://trac.ffmpeg.org/wiki/Encode/H.264)

Keep in mind that psychovisual optimizations that make images look better to humans (like -psy-rd=1.0:0.15) can score worse on some quality metrics, so for real use you don't want -tune ssim. Psy-rd means to take human perception into account when optimizing the rate vs. distortion tradeoff. AQ (adaptive quantization) is another psy optimization, but one that SSIM is sophisticated enough to recognize as beneficial, unlike the simpler PSNR quality metric.

Humans tend to perceive high (spatial) frequency noise as detail if it's small-scale, even if it's not the same detail as in the source image. And our eyes like detail instead of blurring. e.g. fringing and ringing artifacts from quantizing = rounding the DCT coefficients can actually look better than just blurring everything, if they're minor. Stuff that looks worse when you pause and zoom in can trick your eye pleasantly when you just watch normally. (h.264 has a deblocking filter in-loop, applied before frames are displayed and used as references, so it more easily avoids blocking than earlier codecs like DivX / h.263. Cranking that up can just blur everything at low bitrate).

The idea here is similar to what MP3 and other advance audio codecs do for sound, except there's more room for psychoacoustic optimization because loud sounds really stop ears from hearing quiet stuff at nearby frequencies.


If you're encoding once to keep the result for a long time, and/or serve it up over the internet, use -preset veryslow. Or at least -preset medium. You pay the CPU cost once, and reap the savings in file size (for a given quality) repeatedly.

But if you're only going to watch an encode once, e.g. to put a video on a mobile device where you'll watch it once then delete it, then -preset faster -crf 20 makes sense if you have the storage space. Just spend extra bits.


Footnote 1: In lossless compression, you trade off file size vs. speed of compression and/or decompression (which can be different; some codecs are very fast to decompress even if they allow good slow compression). Actually RAM usage / cache footprint can also be a variable if you want to get into that level of detail. In lossless compression, quality is fixed at "perfect", like x264 -qp 0

h.264 decode performance can vary some with number of reference frames, more having a larger memory footprint and thus maybe more cache misses for a CPU decoder. But often h.264 is decoded by hardware. As with many lossless compression schemes, big changes in decode performance are only had with totally different codecs (like h.265), not different options for the same codec. Extra encode time is spent searching for different ways to encode the same bits, but there's only one way to decode.

And yes, h.264 has a lossless mode, as part of the Hi444PP profile. No, you don't want to use it over the internet; many decoders other than FFmpeg lack support for that special feature, and the bitrate is enormous, like 100 to 200 Mbit/s for 1080p30 YUV 4:2:0 or RGB 4:4:4. How to create an uncompressed AVI from a series of 1000's of PNG images using FFMPEG has some test results from the Sintel trailer.

Footnote 2: Other codecs like h.265 (with the x265 encoder) or VP9 can offer even better rate distortion tradeoffs, but at the cost of much more CPU time to encode. For a fixed encode time, I'm not sure if there's any advantage to x265 over x264. But decoder compatibility with h.265 is much less widespread than h.264.

Decode compatibility is very good for h.264 main profile, and hopefully also high profile these days. (8x8 DCT is most useful for high resolutions like 1080p and especially 4k.) x264's default is high profile. Some obsolete mobile devices might only have hardware decode for h.264 baseline profile, but that's significantly worse quality per bitrate (no B-frames, and no CABAC, only the less efficient CAVLC for the final step of losslessly encoding structs into a bitstream.)

10
  • 21
    Not only did I learn about FFmpeg from this answer, but I also learned about a way to cause content on Wikipedia to be highlighted via a hyperlink... Mind blown. Jun 2, 2020 at 1:58
  • @CodyGray: Oh, I just copied the link from my google search result, forgot to trim it down. But yeah, happy accident, I didn't know that was possible either! The highlighted text is what google extracts for the first result for a search on lossy compression Jun 2, 2020 at 2:08
  • 1
    @JiK: I had considered mentioning speed for lossless thought it would distract from the point I was making. On 2nd look, it would fit naturally into that paragraph after all; fixed, thanks. Jun 2, 2020 at 13:24
  • 18
    @CodyGray It's not a Wikipedia thing; but a new Chrome feature - you can do it with any site, e.g. superuser.com/questions/1556953/…. Jun 3, 2020 at 6:03
  • 6
    @Toastrackenigma Ahh, that explains why I'm not seeing it on Firefox. Had thought someone had edited the link or page between that comment and now.
    – Izkata
    Jun 3, 2020 at 15:50
19

The presets don't control the speed of the encoding. They enable or disables compression features (usually called "tools"). When using a slower preset, more tools are enabled. But since every video is different, it's impossible to get the balance perfect for every video every time.

In the case of your specific content, one of those tools is taking more CPU and more bits, but it will generate higher quality video while still fitting inside the bitrate envelope.

2
  • The presets don't control the speed of the encoding. Are you sure? Isn't that the whole point of them - why else would they be named that way? Feb 25, 2021 at 0:52
  • 3
    @HashimAziz More specifically, The presets don't DIRECTLY control the speed of the encoding. They indirectly control the speed by skipping certain steps that improve quality.
    – szatmary
    Feb 25, 2021 at 17:28
2

Compression is a trade-off between:

  • Quality (maximize)
  • Bitrate (minimize)
  • Encoding time (minimize)

Encoding time is most important for real-time streaming, whereas bitrate and quality are much more important for long-term storage.

Slower encoding times (i.e. presets) tend to give better quality-vs-bitrate trade-off curves.

Quality vs Bitrate for H.265 for various presets on 4K UHD video
vmaf_vs_bitrate_mbps
Slower presets are better at minimizing rate for a given target quality level.

This plot was constructed using this code by combining the "VMAF vs CRF" and "bitrate vs CRF" plots from this source.

This plot shows:

  • veryslow, slower, slow provide great compression.
  • medium (default) is a good compromise between compression and encoding time.
  • fast, faster, veryfast, superfast are usually similar.
  • ultrafast is always the worst at low bitrates.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .