Ever wonder what the various x264/x265 "tune" settings do?

[sophisticles]

This experiment started off with my desire to see if it was possible to convert a full DVD to 100mb.

The answer is yes it is possible, but the results truly suck.

The test encodes then morphed into me wanting to see the effects of the various tunes on file size and quality.

I'm sure someone at some point has done such a test, but I do not recall having ever seen it.

For this test I used the Valkaama DVD, which is a full 93 minutes in run time:

http://www.valkaama.com/index.php?page=valkaama&l=en

I used Handbrake on Linux to convert it to x264 slower preset with no tune, tune film, tune grain, tune psnr and tune ssim.

I also converted the DVD to x265 fast preset with no tune, tune psnr, tune ssim, and tune grain.

For all encodes I chose CRF 30. X264 defaults to CRF 23 and x265 defaults to CRF 28; the documentation i have seen claims that x265 CRF 28 should produce the same perceived visual quality at half the bit rate. I chose CRF 30 for both because I wanted to keep the file sizes small and i figured that x265 should produce much higher quality then x264 at the same CRF value.

The results are very interesting.

Encoding times are as follows:

x264
slower 31:09
film 31:51
grain 32:34
psnr 26:58
ssim 28:53

x265
fast 25:17
psnr 22:54
ssim 24:03
grain 1:05:47

I will be adding svt-av1 test encodes soon.

If anyone has a hardware AV1 encoder, feel free to post some test encodes using the above linked source and target the 100mb file size range, to see how it compares.

[Sharc]

For targeting a certain file size like 100MB one should better go for 2-pass encodes, rather than fiddling with CRF values by trial and error ad infinitum.
Tune grain, for example, tries to preserve the grain by changing a few x264 settings (deblock, psy-rd, deadzone, chroma_qp_offset, qcomp, ipratio, aq) as one can see from MediaInfo. Hence for CRF (which is 1-pass) one would expect much larger file sizes with tune grain, especially for grainy sources. No surprise at all.
Whether you want/like it is a different story as it introduces possibly undesired side effects.

[sophisticles]

The original tests I did were 2-pass As I said, the test then morphed into seeing what effect the various tunes have when CRF is held constant.

[sophisticles]

Here are the svt-av1 test encodes, preset 6m no tune and tune psnr.

no tune 1:14:00
psnr 1:11:38

Edit: There were done at CQ 50.

[Sharc]

The original tests I did were 2-pass As I said, the test then morphed into seeing what effect the various tunes have when CRF is held constant.

OK. But then we are back to comparing for significantly different file sizes (bitrates), especially with tune grain, which is doubtful if we want to assess or compare "quality".

[sophisticles]

I just did some more test encodes, this time with NETFLIX source I used in the other thread and I did a 1 pass ABR encode.

NETFLIX x264 fast.mp4 26:21
NETFLIX x264 fast film.mp4 30:37
NETFLIX x264 fast grain.mp4 32:09
NETFLIX x264 fast psnr.mp4 30:07
NETFLIX x264 fast ssim.mp4 28:07
NETFLIX x264 superfast.mp4 22:24

As I have said a number of times, with x264 the various presets and tuning options are pretty much snake oil, a scam.

I don't know if this is intentional, if it's a function of the AVC spec, if it's just the various options within the code base experiencing "convergence", in other words the developers continuously refining the code, trying to squeeze more and more quality at a given bit-rate, that eventually all options offer similar results, but there's no question that the various x264 options seem to be the software version of "high performance" spark plugs, ignition wires and air filters for cars.

[hello_hello]

As I have said a number of times, with x264 the various presets and tuning options are pretty much snake oil, a scam.

I don't know if this is intentional, if it's a function of the AVC spec, if it's just the various options within the code base experiencing "convergence", in other words the developers continuously refining the code, trying to squeeze more and more quality at a given bit-rate, that eventually all options offer similar results, but there's no question that the various x264 options seem to be the software version of "high performance" spark plugs, ignition wires and air filters for cars.

I wouldn't waste my time testing any speed presets faster than medium myself, but that aside....

Maybe when you've run more than a few unrealistic encodes you might think differently.

The animation tuning, for example, increases the number of B and reference frames compared to Tune Film, or no tuning, it reduces Psy and AQ strength considerably, and sets deblock strength and deblock threshold to 1. The result is quite a bit of extra compression for a given CRF value, especially for animation, and for a while I used the animation tuning a lot, but eventually I decided it was too prone to banding (even with dithering in the script), so these days I use a combination of settings somewhere between no tuning and the animation tuning. For the same CRF value the file sizes are a bit larger, but with a bit of dithering in the script I find it fixes a lot of the existing banding in animation and prevents the encoder from causing any more of it. Naturally if you use settings that cause the encoder to retain more information the bitrate will increase, for a given CRF value.

It's never been claimed that a given CRF value will produce the same relative quality every time when different encoder settings are used. This is the official definition of CRF encoding:

http://www.chaneru.com/Roku/HLS/X264_Settings.htm#crf
Constant Ratefactor. While qp targets a certain quantizer, and bitrate targets a certain filesize, crf targets a certain 'quality'. The idea is for crf n to give the same perceptual quality as qp n, just in a smaller space. The arbitrary unit of measure for crf values is the "ratefactor".

CRF "n" aims to produce the same perceptual quality as QP "n", but at a lower bitrate. That's it. If changing various x264 settings, whether it be a speed preset or tuning, changes the bitrate when encoding in dumb QP mode, why wouldn't it to do the same in CRF mode?

I just did some more test encodes, this time with NETFLIX source I used in the other thread and I did a 1 pass ABR encode.

ABR? Another waste of time.