Do FFMPEG H264 presets affect video quality?

Question

I am definitely not an FFMPEG expert, but according to this document :

A preset is a set of options that will provide a certain coding rate for compression. A slower preset will provide better compression (compression is quality per file size). A common use is to use the slowest preset for which you have patience. Current presets in decreasing order of speed: ultrafast, ultrafast, very fast, fast, fast, medium, slow, slow, very strong, placebo.

So, as I understand it, ffmpeg presets should not affect the quality of the output video, but they should determine the compression size / size of the output file. Therefore, with the same quality parameter (I will use -crf 24 ), the files should be larger, for example, faster than the preset than for the slower preset. This would be the only reason to use a slower preset - to get a smaller file size.

This is not the case. I encode the HD stream from Handycam using different presets, everything else is the same:

 ffmpeg -y -i "$fname" -vf yadif=1,scale=-1:720 -acodec aac -ab 128k -ac 2 -strict experimental -vcodec libx264 -vpre slow -threads 2 -crf 24 "$outp" 

Surprisingly, I get the smallest file size for a veryfast preset! For example:

• slower : output data transfer rate of 3500 kbit / s, encoding speed of 17 frames per second, file size 29 MB.
• veryfast : data transfer rate 3050 kbit / s, encoding speed 34 frames per second, file size 25 MB.

What I think is not how it should be. Now I wonder, is it because of the degradation of the encoding quality for the veryfast preset? Or in my case using slower just doesn't make sense for some reason?

Answer 1

Yes, the quality may vary slightly depending on the preset used, but it should not be significant. Here is an excerpt from the discussion on # x264. A similar question with your answers was provided by one of the x264 developers:

 verb3k | Do different presets have an effect on quality when used with CRF? @Dark_Shikari | verb3k: yes, but not too much. @Dark_Shikari | a 0th-order approximation is that they have no effect. @Dark_Shikari | The main reason there a difference is because the preset affects how x264 itself measures quality @Dark_Shikari | that is, it uses better, more accurate methods of measuring quality @Dark_Shikari | obviously, this will affect the definition of what -crf does! @Dark_Shikari | It just not too much, so we can mostly ignore it. @Dark_Shikari | specifically, there are three big things that can affect the definition of quality @Dark_Shikari | 1) AQ being on/off @Dark_Shikari | jump: ultrafast to superfast @Dark_Shikari | 2) mbtree being on/off @Dark_Shikari | jump: superfast to veryfast @Dark_Shikari | 3) psy-rd being on/off @Dark_Shikari | jump: faster to fast @Dark_Shikari | above fast there are no more big jumps. 

This means that a slower preset with the same CRF value will improve the quality for the bit rate, but may result in higher or lower quality and bit rate.

Answer 2

If that helps, this is git diff from slower to veryfast . Even if you just consider the value of ref , you can see how veryfast can be of lower quality.

 ref In short, this value is the number of previous frames each P-frame can use as references. 

a source

 --- a/slower +++ b/veryfast @@ -1,20 +1,20 @@ cabac=1 -ref=8 +ref=1 deblock=1:0:0 -analyse=0x3:0x133 -me=umh -subme=9 +analyse=0x3:0x113 +me=hex +subme=2 psy=1 psy_rd=1.00:0.00 -mixed_ref=1 +mixed_ref=0 me_range=16 chroma_me=1 -trellis=2 +trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 -chroma_qp_offset=-2 +chroma_qp_offset=0 threads=12 lookahead_threads=2 sliced_threads=0 @@ -25,17 +25,17 @@ bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 -b_adapt=2 +b_adapt=1 b_bias=0 -direct=3 +direct=1 weightb=1 open_gop=0 -weightp=2 +weightp=1 keyint=250 keyint_min=23 scenecut=40 intra_refresh=0 -rc_lookahead=60 +rc_lookahead=10 rc=crf mbtree=1 crf=23.0