ffmpeg - why does h265 compression increase the filesize?

Question

I try to learn about the basics of video encoding/decoding so I played around with ffmpeg a little to get my hands on it and not just read about the topic.

Accodring to the ffmpeg documentation there are two options to configure the compression of a h265 encoded video file. The first is the -crf option and the second is the -preset option.

https://trac.ffmpeg.org/wiki/Encode/H.264 https://trac.ffmpeg.org/wiki/Encode/H.265

The crf option does what I expect that it does, the lower the value, the better the quality, the brigger the file size. So far so good. But what I don't understand is the -preset option.

The documentation says:

A preset is a collection of options that will provide a certain encoding speed to compression ratio. A slower preset will provide better compression (compression is quality per file size). This means that, for example, if you target a certain file size or constant bit rate, you will achieve better quality with a slower preset. Similarly, for constant quality encoding, you will simply save bitrate by choosing a slower preset. Use the slowest preset that you have patience for. The available presets in descending order of speed are:

ultrafast
superfast
veryfast
faster
fast
medium – default preset
slow
slower
veryslow
placebo – ignore this as it is not useful (see FAQ) 

So I encoded my input file once with ultrafast and once with veryslow:

ffmpeg -i Input.mkv -c:a aac -c:v libx265 -preset ultrafast -crf 15 output_crf-15_preset_ultrafast.mp4

ffmpeg -i Input.mkv -c:a aac -c:v libx265 -preset veryslow -crf 15 output_crf-15_preset_veryslow.mp4

The results are very confusing for me:

33M Dez 24 16:43 Input.mkv
90M Dez 24 16:48 output_crf-15_preset_ultrafast.mp4
116M Dez 24 19:34 output_crf-15_preset_veryslow.mp4

first of all, the copressed videos have a bigger filesize then the input file? Then the veryslow-version which should compress better has a bigger filesize then the ultrafast-version? That does not make any sense to me.

In addition I also did a lossless encoding

ffmpeg -i Input.mkv -c:a aac -c:v libx265 -x265-params lossless=1 output_crf-15_lossless.mp4

And the resulting file is about 1.2GB in size? Why does that happen? Shouldn't it be as big as the original?

The testfile and results: https://mega.nz/folder/Ok8UhCRB#DDblMnGgSoJ0LeE_DtVmGg

Answer 1

CRF is not a constant quality guarantee, more of an approximate bitrate specification. veryslow outperforms ultrafast in SSIM:

ffmpeg -i output_crf-15_preset_ultrafast.mp4 -i Input.mkv -lavfi ssim=stats_file=ssim_logfile.txt -f null -
ffmpeg -i output_crf-15_preset_veryslow.mp4 -i Input.mkv -lavfi ssim=stats_file=ssim_logfile.txt -f null -
ffmpeg -i output_crf-15_lossless.mp4 -i Input.mkv -lavfi ssim=stats_file=ssim_logfile.txt -f null -

ultrafast
SSIM Y:0.988442 (19.371360) U:0.990816 (20.369877) V:0.989430 (19.759408) All:0.989003 (19.587190)

veryslow
SSIM Y:0.994984 (22.996610) U:0.995488 (23.456610) V:0.994814 (22.851297) All:0.995040 (23.045022)

Lossless
SSIM Y:1.000000 (inf) U:1.000000 (inf) V:1.000000 (inf) All:1.000000 (inf)

The result from the lossless compression is also not surprising. Suppose I have data in the form of integer coordinates for 2D functions (e.g. y=x). Suppose I have an encoding scheme that assumes horizontal lines, and therefore only records (x,y) coordinates when y is different from the previous coordinate. Under this scheme, to save a horizontal line "losslessly", I only need 1 coordinate. For a series of coordinates that define a horizontal line with 1 outlier coordinate with a different y, I need to save at most 3 coordinates to losslessly save the data. But to losslessly store the integer coordinates of the line y=x, I need to save every coordinate in the entire domain. Under other encoding schemes, y=x is trivial to encode losslessly.

Or imagine you have some image that consists only of circles, and an encoding scheme that is based on squares. It might take 10,000 squares to losslessly encode a circle at some resolution, while 100 squares gets you 99% of the way there, and close enough no one can tell the difference.

Lossless encoding will be much closer in size to saving a bitmap for each frame than a very high quality, lossy encoding. You lose even if you losslessly compress something already compressed in the same format. E.g., if you losslessly compress a x264 video using x264, instead of reconstructing the raw, uncompressed video, you must now perfectly reconstruct this x264 lossy version of that video, but without the benefit of referring to the original video! There's no guarantee you'll find the same compression and in most cases, you're practically guaranteed not to.

See also this answer.