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

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
Lsize=  150252kB

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

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

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

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
Lsize=  125262kB

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
Lsize=  125061kB

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
Lsize=  118149kB

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

And is the video loss something with preset veryfast?

  • 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)? – Peter Mortensen Jun 1 at 23:44
  • 1
    "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 at 15:03

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' 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 . -preset ultrafast is usually noticeably bad even at high bitrate, but other presets can look as good as veryfast 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.)

| improve this answer | |
  • 10
    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. – Cody Gray Jun 2 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 – Peter Cordes Jun 2 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. – Peter Cordes Jun 2 at 13:24
  • 7
    @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/…. – Toastrackenigma Jun 3 at 6:03
  • 3
    @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 at 15:50

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.