1

Today I tried to find out which difference in file size the preset slow makes compared to the preset ultrafast when encoding a video (if all other parameters are the same). I took a video with approximately 10 GB and encoded the first two minutes using the following command line:

"C:\Program Files\ffmpeg\bin\ffmpeg.exe" -i input.mkv -c:v libx265 -preset slow -crf 22 -c:a copy output.mkv

To encode only the first two minutes, I watched the console after I had issued that command, and hit Ctrl-C when FFMPEG had encoded the first two minutes.

Then output.mkv was about 70 MB in size.

When I replaced -preset slow by -preset ultrafast in the command line above and let it encode the first two minutes again, output.mkv was about 40 MB in size.

Now I am totally baffled. I must have seriously misunderstood something.

From the documentation (in the section about the preset) (omission mine):

A slower preset will provide better compression (compression is quality per filesize). [...] Similarly, for constant quality encoding, you will simply save bitrate by choosing a slower preset.

As I understand my command line and the documentation, I am using constant quality encoding, so slower presets should mean better compression, and that in turn should mean smaller file sizes. So why does the output file increase in size when I use a slower preset, given that the preset is the only parameter that changes?

Side note: I am aware that the citation above is from the FFMPEG H.264 documentation, while I am using the H.265 encoder. However, FFMPEG's documentation for the latter states that both encoders behave the same with respect to the preset.

EDIT

@harrymc has drawn my attention to this question, which I have to admit is the same as mine, and which I had missed during my research. However, the answer there -as long as it is- is not sufficient (at least to me), because it contradicts FFMPEG's documentation without giving an understandable (again, for me) explanation or explaining the errors in FFMPEG's documentation.

Therefore: My question is a duplicate (sorry, no intention), but the answer(s) to the other question didn't solve my problem.

Binarus
  • 1,687
  • 9
  • 19
  • 3
    Does this answer your question? [Why does preset "veryfast" in FFmpeg generate the most compressed file compared to all other presets?](https://superuser.com/questions/1556953/why-does-preset-veryfast-in-ffmpeg-generate-the-most-compressed-file-compared) – harrymc Jan 08 '23 at 19:03
  • @harrymc Thank you very much, I have indeed missed that question. I admit that it is the same as mine. However, the answer there is hard to understand and makes some statements which seem to contradict FFMPEG's documentation. At least for me, the answer there, as long as it is, is not sufficient or even clear. – Binarus Jan 09 '23 at 10:22
  • @Binarus no problem in missing the previous question, and it's perfectly fine to have a follow up question as well. However, could rewrite your current question such that it focusses on the the part you don't understand or feel that contradicts FFMPEG's docs? Simply [edit] your question (no need to write "edit" or "update") rewrite it from scratch (as if you seen the duplicate question before posting your question) and focus on why the duplicate does not answer your question. – Saaru Lindestøkke Jan 09 '23 at 10:53
  • OK, good tip, thanks. I'll do that, but I'll need a day or so :-) – Binarus Jan 09 '23 at 10:57
  • @BlindSpots I didn't try the things you mentioned because the contradiction to the documentation is so remarkable. After all, it's not about 5% difference in the "wrong" direction, but nearly 50% (taking the smaller file size as basis); this probably wouldn't change a lot with more material. I also believe that my method of limiting the time is OK, because encoding by CRF is a one-pass process (please correct me if I am wrong). Therefore, it shouldn't make a difference if I interrupt it after it has reached 2 minutes or if I cut out the first two minutes and encode that. – Binarus Jan 09 '23 at 11:07

0 Answers0