KB: HEVC (x265) Encoding

Preset Method Comparison

To use `preset`, do the following or set it in env var FFCVT_O

  cm=medium
  ffcvt -f testf.mp4 -debug 1 -force -suf $cm -- -preset $cm

Which will invoke

  ffmpeg -i testf.mp4 -c:a libopus -b:a 64k -c:v libx265 -x265-params crf=28 -y -preset medium testf_medium_.mkv

Here are the final sizes and the conversion time (in seconds):

  2916841  testf.mp4
  1807513  testf_.mkv
  1743701  testf_veryfast_.mkv   41
  2111667  testf_faster_.mkv     44
  1793216  testf_fast_.mkv       85
  1807513  testf_medium_.mkv    120
  1628502  testf_slow_.mkv      366
  1521889  testf_slower_.mkv    964
  1531154  testf_veryslow_.mkv 1413

I.e., if `preset` is not used, the default is `medium`.

Here is another set of results, sizes and the conversion time (in minutes):

 171019470  testf.avi
  55114663  testf_veryfast_.mkv  39.2
  57287586  testf_faster_.mkv    51.07
  52950504  testf_fast_.mkv     147.11
  55641838  testf_medium_.mkv   174.25

Same source file, using the fixed `-preset fast`, altering the crf:

  52950504  testf_28_.mkv       147.11
  43480573  testf_30_.mkv       146.5
  36609186  testf_32_.mkv       144.5
  31427912  testf_34_.mkv       143.9
  27397348  testf_36_.mkv       139.33

So it confirms that `-preset` determines the conversion time,
while `crf` controls the final file size, not conversion time.

The ffmpeg x265 preset determines how fast the encoding process will be. if you choose ultrafast, the encoding process is going to run fast, but the file size will be larger when compared to medium. The visual quality will be the same. Valid presets are ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow and placebo.

Because that the visual quality are the same, so there is no need to go for the slower options, because you won't be gaining anything but for the final file size. Therefore, check for yourself the above result file sizes and the conversion times, then pick a preset level you feel comfortable. The following present the same data of above first two list in graphs. Click on them each to bring up bigger and most importantly, interactive graph.

I personally would go for veryfast because it produces the final size not much different than fast, medium, but only take less than a quarter of the time (but you may choose anything). I.e., I'll use

export FFCVT_O="-preset veryfast"

so as to avoid specifying it each time when invoking ffcvt.

The CRF Comparison

Constant Rate Factor

This method allows the encoder to attempt to achieve a certain output quality for the whole file when output file size is of less importance. This provides maximum compression efficiency with a single pass. Each frame gets the bitrate it needs to keep the requested quality level. The downside is that you can't tell it to get a specific filesize or not go over a specific size or bitrate.

CRF Comparison

The following present the crf comparison data from above list in graph. Click on it to bring up the bigger and interactive graph.

So we can confirms that, crf controls the final file size, not conversion time. When crf=36 the final file size is almost half the size of crf=28 (and only 16% of the original size), but that's only good for the content like slide presentation, in which the content are mostly static, and a blur of up to a quarter of second during transition is not too troublesome.