Log in

View Full Version : x264 Time/Quality Optimization


Danette
13th March 2022, 15:14
Edited after post #4

I'm processing a d2v file, with script, through MeGUI. My basic preferred x264 settings are Constant Quality, Quality=18 and Very Slow.

I've been reconsidering the time/quality trade-off in moving between "Medium" through "Very Slow" and, as is known, time and file size is reduced when moving from "Very Slow" through each step up to "Medium".

However, I just tried changing the "Medium" setting to Quality=17, from my standard Quality=18. In doing so, the time remains the same as Quality=18, but file size is increased by about 35% vs. the "Very Slow" preset.

What is happening to the video quality in doing this? Is the "Medium"/Quality=17 setting close to the quality of the "Very Slow"/Quality=18 setting, particularly given the increased size? If I further increase the quality of the “Medium” preset to 16, vs. the quality=18/“Very Slow” preset, the speed remains basically that of all “Medium” settings, which is about 20% less than the “Very Slow” preset.

rwill
13th March 2022, 15:40
https://en.wikipedia.org/wiki/Quantization_(image_processing)

Rumbah
13th March 2022, 16:39
The quality setting to 20 instead of 18 means lower quality. The higher the number, the lower the quality. So it's perfectly normal that your encoding gets smaller with the higer quality value. A setting of 23 will even be smaller.

But the quality setting is not comparable if you use different other settings. So a "medium" encode of quality 18 has a different perceived quality than a "very slow" encoding with quality 18 and the sizes will be very different.

So the normal way to go would be to first choose a speed setting that you are willing to spend and then test the quality setting that looks good for you.

In the case you described to compare a very slow encoding with your normal encoding, you have to look at the file size of your medium/20 encode and then do a 2 pass encoding with veryslow to get the same file size as your medium/20 encode. Then you can see the quality difference between medium and veryslow.

rwill
13th March 2022, 18:22
To be more generic, for any more or less sane encoder it should be like this:

Imagine a Triangle with the words "Quality", "Speed" and "Low Bitrate" in each corner. These are the major targets you can have when you use an encoder to encode a sequence. Putting more weight on one thing, like "Speed", will lower "Quality" or "Low Bitrate" or both.

So its always a tradeoff, it depends where you want to put your focus.

Danette
14th March 2022, 02:08
I apologize to previous posters. Of course, you are right (and I knew this). I simply wasn’t using the right numbers and just realized it. I’ve edited the OP to reflect this. Essentially, as you know, I can greatly increase speed using the “Medium” preset vs. the “Very Slow” preset, even when increasing the quality setting, albeit with an acceptable increase in file size. The question is: will these higher quality settings in “Medium” preset close the gap between the lower quality settings in the “Very Slow” preset?

rwill
14th March 2022, 06:58
Slower speed modes in x264 take more care where they put bits compared to faster speed modes. So a bit spent in a slow speed mode has a more positive impact on quality than a bit spent in a faster speed mode. This is mostly caused by the psy- and (psy-)trellis tools in the x264 encoder. One cannot calculate the 'numbers' though at it is highly content dependent.

Sharc
14th March 2022, 10:19
You can approach, meet and even exceed the quality of a slower preset by reducing the CRF (=increasing the filesize) with a faster preset. How much you would have to reduce the CRF of the faster preset depends on the source. Only your eyes will tell, or you may do a PSNR,VMAF or other standard metrics "objective" comparison.
Note that for x264 8 bit --CRF 0 (or more general --qp 0 for 8 bit and 10 bit) is lossless (huge file size), and lossless is lossless, independent of the preset.

(Added: The overall encoding time depends also on the script if you should have a script in place. A complex script may mask the encoder's encoding time)