Trouble with ffmpeg preset "p1 through p7"

[Ronstang]

I have been using a command string that had the preset "hq" that FFmpeg Batch AV Converter reported as deprecated. After figuring out what that meant and a little research I found that the "hq" preset has been replaced by the "p" preset with values of 1-7. The following is the documentation I found for this preset:

• -preset <int> E..V...... Set the encoding preset (from 0 to 18) (default p4)
  default 0 E..V......
  slow 1 E..V...... hq 2 passes
  medium 2 E..V...... hq 1 pass
  fast 3 E..V...... hp 1 pass
  hp 4 E..V......
  hq 5 E..V......
  bd 6 E..V......
  ll 7 E..V...... low latency
  llhq 8 E..V...... low latency hq
  llhp 9 E..V...... low latency hp
  lossless 10 E..V......
  losslesshp 11 E..V......
  p1 12 E..V...... fastest (lowest quality)
  p2 13 E..V...... faster (lower quality)
  p3 14 E..V...... fast (low quality)
  p4 15 E..V...... medium (default)
  p5 16 E..V...... slow (good quality)
  p6 17 E..V...... slower (better quality)
  p7 18 E..V...... slowest (best quality)

*Sorry I can't figure out how to get the above to post and retain it's formatting*


Here is the command string I have been testing with for quite some time:

-c:v hevc_nvenc -vf "fieldmatch,bwdif=mode=0:deint=1,decimate,format=y uv420p10le" -c:a copy -c copy -preset hq -rc constqp -rc-lookahead 60 -spatial_aq 1 -temporal_aq 1 -nonref_p 1 -cq 26

I ran some tests. I changed the hq to p7 as according to the documentation they should be equivalent. I ran the same video file with each setting and the file sizes were identical so I assume that means the settings are identical. I then ran the same video file with the preset set to "18" and once again the file size was identical to the other two already tested. So I assume the presets "hq", "p7" and "18" are all identical.

So I went ahead an tried the preset at "p1" for comparison's sake and while the same video file encoded a little faster, maybe 10%, the file size was about 50% larger. This I did not expect. Is is possible for the file size to be larger with the quality being lower? I was led to believe the larger the file size the higher the quality of the resulting compressed video.

I have been using ffmpeg 4.4 full lately and after an nVidia graphics card driver update my files upon compression have become much smaller than before with the exact same settings as above so I have been testing to see what has happened. The quality isn't bad even with most full length movies ending up 1-1.5Gb in size....but I have been trying to see if I can get more quality with slightly larger file size since these same movies encoded before in H.264 are 3 to 4 times the size often.

I am confused because I don't know what to do with the "p" preset now. Is the documentation wrong and is "p1" the higher quality.....BUT....it does run faster, hence my confusion.

It seems the more I learn the less I know and the move confused I become LOL. Any help would be greatly appreciated.

[hydra3333]

Oh, ffmpeg nvenc hevc_nvenc ?

Perhaps see this from the manufacturer, nvidia,
https://developer.download.nvidia.com/video/gputechconf/gtc/2020/presentations/s21337-...l-flow-sdk.pdf
pages 16 to 27.

[Ronstang]

Thank you for that. I read through it but I am not sure exactly what it is trying to tell me. Here are two files I encoded yesterday using Nvenc with the above settings ans the following presets:

Blue Thunder (1983) STZEH - p7 file size = 1,265, 602 bit rate = 1,825 kb/s

Blue Thunder (1983) STZEH - p1 file size = 1,948,955 bit rate = 2,811 kb/s

When those graphs are showing bit rate savings with the new presets does that mean that the p7 preset which they claim is higher quality does so with a smaller file size and a lower bit rate? I watched a movie last night with similar results to above that had lots of dark scenes and is an older movie with less than stellar transfer.....and I switched back an forth between to two different encodes when ever it looked like there where quality issues.....and I could not tell the difference between the two. The smaller file had the same perceived quality as the one that was 50% larger and more than twice the bit rate so any visual issues where obviously present in the source (recorded cable tv). I was actually quite impressed.

If this is the case then it's a windfall to have decent quality with a smaller file size.

[Ronstang]

Anyone with some insight on this issue. I would like to know if I am interpreting the results of this testing and of the graphs in nVidio's documentation posted by hydra3333

[october262]

Anyone with some insight on this issue. I would like to know if I am interpreting the results of this testing and of the graphs in nVidio's documentation posted by hydra3333

perhaps this here will help - https://developer.nvidia.com/blog/introducing-video-codec-sdk-10-presets/

[jagabo]

Is is possible for the file size to be larger with the quality being lower?

Of course.

I was led to believe the larger the file size the higher the quality of the resulting compressed video.

All else being equal, yes. But this is the whole point of having presets. The slower presets spend more time looking for more and better ways to compress the video. So you can pick your tradeoffs. More encoding time to get smaller files or higher quality. Faster encoding but lower quality or larger files.

By the way, the definition of bitrate is:

bitrate = stream size / running time

So lower bitrates means proportionally smaller streams. The file size is the sum of the size of the all the streams plus a little container overhead. So lower bitrates also result in smaller files.

[Ronstang]

Thank you. My confusion came from the fact that using preset p1 had a file size of 50% larger than the same file with a preset of p1 but upon testing several times with different files the times did not vary hardly at all. I realized last night that the possible cause of this was I had switched to a routine of that did IVTC because my files were not actually interlaced an am using 10bit color. When I switched to IVTC my encode times went up considerably but considering the occasional shuddering is now gone upon playback it is worth it. I can only assume the extra time it takes to perform this operation is masking the time differences of p1-p7. The IVTC that works may also only run in CPU not GPU so that might mask the time difference too. \

Either way I ran the same movie I first encoded with the new versions my video driver and the IVTC and 10 bit color which resulted in a small file by comparison to the past. The quality was damned good for an old movie with a questionable transfer recorded from Cable TV, the banding in dark scenes was gone (YAY!) but I had strange artifacting occasionally in dark scenes so there was a new glitch. That turned out to be my overclocked (factory applied) video card so I downclocked it as far as possible on all settings and the artifacts are gone with no affect on encode speed. I encoded it again with p7 in place of hq and the results were identical. P1 was 50% larger and p7 with spatial set to 12 and then 15 were each a proportionally bigger but still smaller file size than when it was set to p1. I watched the movie and each time there was anything that might be considered a quality issue arose I switched an re-watched the scene with the other versions of the file....and there was really no difference so those issues are in the source, not an issue....and the smaller file size (amazingly small compared to what they used to be with old drivers and versions of ffmpeg) wins because it takes up less space but the quality is actually very good considering.