53

I have looked at various cheatsheets, but they were outdated. What preset settings work well with the latest versions of FFmpeg? I'm primarily interested in the H.264 and ProRes codecs for low, medium, and high quality presets.

1
  • 1
    I want to add very important note here, video quality are different from each preset, e.g crf 28 preset veryslow looks visually way better than medium preset since more complex algorithms being used to enhance image quality, so it's not matter of size only but Size and image quality.
    – Salem F
    May 22, 2023 at 15:57

3 Answers 3

75

FFmpeg does not include text file based presets and profiles anymore for libx264, i.e. what you've used with the -vpre option. These have been deprecated and removed in favor of accessing the actual x264 presets, profiles (and tunes) with the -preset, -profile:v, and -tune options. The old text files only emulated the official x264 presets and profiles, and due to several limitations could not offer the full functionality that the new system provides. It is also much easier to maintain.

Additionally, many encoders have their own separate options; also called "private options". You will have to look into the audio and video encoder options for common codecs in the FFmpeg online documentation, or check the output of ffmpeg -h full for a complete list of supported options. For example, x264 lists its options under libx264 AVOptions in the full help output.

If your ffmpeg supports -preset then any text file presets should not be used, and FFmpeg no longer comes with any other than some non-standard iPod presets. It is a common misconception that text presets can simply be copied from anywhere and used with any ffmpeg. This is untrue and will result in breakage.


Basically, the presets allow you to do the following things:

Control quality

Quality is controlled either by specifying a bitrate through -b:v (for video) or -b:a (for audio), or by specifying any other encoding method the codec might support.

For x264, there are various encoding methods, with the Constant Rate Factor method being the most sophisticated. It results in variable bitrate, but overall good quality in one single pass. CRF values range from 0 to 51, but sane values are somewhere between 19 and 26, depending on your source and what quality you want. 23 is the default, so you could for example choose 18 for "high quality" and 28 for "low quality", whatever that means for you.

ffmpeg -i input.mp4 -c:v libx264 -crf 23 output.mp4

x264 has other encoding methods as well, but this is out of the scope here.

Constrain the H.264 profile

These profiles define a feature set the encoder may use to match the capabilities of a certain decoder. In recent FFmpeg, use the following syntax to specify a profile, where profile could be baseline, main or high:

ffmpeg -i input.mp4 -c:v libx264 -profile:v baseline output.mp4

For more info and when you should use which profile, see: What are the differences between H.264 Profiles?

Choose an x264 encoding preset

These presets affect the encoding speed. Using a slower preset gives you better compression, or quality per filesize, whereas faster presets give you worse compression. In general, you should just use the preset you can afford to wait for. Presets can be ultrafast, superfast, veryfast, faster, fast, medium (default), slow and veryslow. Here's an example:

ffmpeg -i input.mp4 -c:v libx264 -preset slow output.mp4

Encode lossless video

This is possible by specifying a CRF of 0, so simply use -crf 0:

ffmpeg -i input.mp4 -c:v libx264 -crf 0 output.mp4

Finally, let's talk about ProRes quickly. ProRes accepts either a fixed bitrate with -b:v, or you can specify the profile, which should be a value between 0 and 3, where the bit rates are chosen according to the profile. Higher means better:

ffmpeg -i input.mp4 -c:v prores -profile:v 0 output.mov

The ffmbc Wiki suggests that names of profiles can be used – this however fails in FFmpeg 1.0.

0
36

I did a test in which I trans-coded (using libx264 encoding to .mp4) a high quality video from a Sony camcorder using the full range of preset values (except placebo) on a range of CRF values (18, 21, 24, and 27). I wanted to know what would give me the best combination of encoding speed, output quality and file size.

For each CRF value, I gave each trans-code operation a score for its encode time (e.g., for CRF = 18, preset value ultrafast's time of 5.7 seconds got a score of 1.0, veryslow's time of 162 seconds got a 0, with all other scores scaled in between). I calculated output file size scores similarly, of course giving the smallest file the best score. I then added the two scores for a "combined" speed/size score.

For each of the four CRF values, the "veryfast" preset was the hands-down winner, with nearly perfect scores of 1.94 (for CRF 18 and 21), 1.96 (CRF 24) and 1.97 (CRF 27). I find it very curious that "veryfast" produced nearly the smallest file size every time, losing only to "veryslow" and never by much.

One difference I did notice among the various preset values was that the operating system (Windows 7) would give me different thumbnails. The faster presets would show a thumbnail several seconds into the video, where the thumbnails for the slower presets would reflect the opening frame(s) of the video. That's not important for me; what I learned was that "-preset veryfast" seems to be an easy choice.

Here are my results (as a snapshot image of an Excel spreadsheet):
excel snapshot

Here is the Excel spreadsheet as csv text:

CRF,Preset,Seconds,score,MB,score,totalscore
18,1_ultrafast,5.7,1.00,59.5,0.09,1.09
18,2_superfast,8.4,0.98,62.3,0.00,0.98
18,3_veryfast,10.8,0.97,30.9,0.98,1.94
18,4_faster,16.0,0.93,33.5,0.89,1.83
18,5_fast,24.0,0.88,36.8,0.79,1.68
18,6_medium,29.1,0.85,34.9,0.85,1.70
18,7_slow,48.1,0.73,33.9,0.88,1.61
18,8_slower,84.9,0.49,33.0,0.91,1.40
18,9_veryslow,162.0,0.00,30.1,1.00,1.00
21,1_ultrafast,5.7,1.00,38.0,0.00,1.00
21,2_superfast,7.9,0.98,35.0,0.15,1.14
21,3_veryfast,10.0,0.97,19.0,0.97,1.94
21,4_faster,14.2,0.94,21.0,0.87,1.80
21,5_fast,19.9,0.89,23.0,0.77,1.66
21,6_medium,24.6,0.86,22.0,0.82,1.67
21,7_slow,43.1,0.72,21.0,0.87,1.58
21,8_slower,69.8,0.51,20.5,0.89,1.41
21,9_veryslow,137.3,0.00,18.4,1.00,1.00
24,1_ultrafast,5.5,1.00,24.9,0.00,1.00
24,2_superfast,7.5,0.98,21.4,0.27,1.25
24,3_veryfast,9.3,0.97,12.0,0.99,1.96
24,4_faster,13.2,0.93,14.0,0.84,1.77
24,5_fast,17.4,0.90,15.0,0.76,1.66
24,6_medium,21.0,0.87,14.4,0.81,1.67
24,7_slow,37.3,0.72,14.0,0.84,1.56
24,8_slower,62.2,0.51,13.0,0.92,1.42
24,9_veryslow,121.1,0.00,11.9,1.00,1.00
27,1_ultrafast,5.5,1.00,16.8,0.00,1.00
27,2_superfast,7.4,0.98,13.6,0.38,1.36
27,3_veryfast,9.0,0.97,8.4,1.00,1.97
27,4_faster,12.6,0.93,10.1,0.80,1.73
27,5_fast,15.8,0.90,10.4,0.76,1.66
27,6_medium,18.8,0.87,10.0,0.81,1.68
27,7_slow,34.1,0.73,9.8,0.83,1.56
27,8_slower,59.6,0.48,9.0,0.93,1.41
27,9_veryslow,109.7,0.00,8.4,1.00,1.00
4
  • 1
    I must admit that I looked on your results with suspicion, but I've repeated the test and got v. similar results, using ffmpeg version 3.3.2-1 on a 2 min 1080p movie clip. In fact veryfast generated the smallest file size 60% of the time, and coming 2nd to veryslow 40% of the time (but not by much). From now on I'll be using veryfast for all my encodes along with a fairly low CRF value (18, 19, 20) since veryfast was only a little slower with the lower CRF values than it was with the higher ones. Thanks you've saved me lots of time. Raw data and script in comment below.
    – mattst
    Nov 9, 2018 at 17:22
  • 1
    Continuing from the comment above... Here's my raw data - CRFs 18 to 27 and the Linux/UNIX bash script that I wrote to run the encodes (in case anyone wishes to run a similar test).
    – mattst
    Nov 9, 2018 at 17:25
  • 2
    Here are some great blog posts on the subjects, with tests conducted for x264 and x265 (results are, predictably, very different for each) Feb 20, 2019 at 6:46
  • 1
    These comparisons incorrectly assume that quality doesn't change. But it does. That's why the bitrate "increases" for the slower presets. If the quality improved by 100000x and bitrate increased by 0.1%, wouldn't you say that's worth the tradeoff?! A proper comparison should also include a perceptual quality metric (e.g. VMAF). That said, I agree that ultrafast and superfast should be avoided. Jan 8 at 7:58
2

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.
Note that these curves may vary depending on the data source and video resolution.

Table of results:

-preset BD-Rate (%)
ultrafast 51.2
superfast 39.0
veryfast 53.5
faster 53.3
fast 50.3
medium 37.5
slow 5.3
slower 0.8
veryslow 0.0

BD-Rate denotes the relative percentage increase in rate with respect to the reference curve (i.e., veryslow).

Each preset takes 1.3x – 2.0x the encoding time as its immediately preceding preset.

Recommendations:

  • -preset ultrafast for realtime applications such as streaming
  • -preset medium (default) for casual usage
  • -preset slow for long term personal storage
  • -preset veryslow for publishing (YouTube, Netflix, or DVD)

-preset slow is usually much better than -preset medium, and worth the 2x encode time.


Source data:

To generate the plot above, the following data was combined:

VMAF vs CRF Bitrate vs CRF
4
  • Mateen, your answer contradicts the answer above which shows that veryfast preset was the best compromise for speed and file size. Has something changed in ffmpeg now offers its best fast output in superfast rather than veryfast? Jan 11 at 14:23
  • 1
    @Foliovision That answer incorrectly ignores the big drop in quality. Or rather, it assumes quality = CRF, which is not true, as shown in this plot (quality = VMAF). Compression engineers are smarter than that answer insinuates: if a preset takes longer, it's usually because it is better on average. I try to quantify how much better in this answer, though the exact amounts will depend on the data source. My answer considers UHD 4K, but lower resolutions may be different. Jan 12 at 0:28
  • The plot to which you link suggests that for quality one should not accept anything faster than Slow. In a hurry, perhaps Medium. And that other than ultrafast (which is awful), it makes little difference if one chooses fast, faster, veryfast or superfast. Is this the reality? I'm trying to make some real world decisions here on encoding presets. Thanks. Jan 12 at 13:55
  • 1
    @Foliovision At least for this particular data source, fast-ultrafast all gave similar results, as you noticed. If you can, I recommend running a few sample encodes on your own data source / target resolution in the same way as "Code Calamity" and I did here to account for both bitrate and perceptual quality. Generally speaking, my guess is that for most data sources, slow is much better than medium, and medium is much better than ultrafast. Jan 12 at 14:38

You must log in to answer this question.

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