Better x265 medium or x264 slow?

[tormento]

I have done some tests and while x265 medium is nice enough for anime with flat areas, it loses lot of details in movies with textures on par with x264 slow.

[benwaggoner]

Originally Posted by Boulder

Wasn't the intent more like using SAO in frames where it could be useful? As you well know, the default --sao eats details for breakfast and really cannot be recommended to anything but some very low bitrate encodes where details would be lost anyway. Or did you mix up --selective-sao and --limit-sao?

I chaired the SMPTE tech conference track where MCW presented their research on the feature. The intent was a speedup for faster presets, as SAO had minimal impact on bidirectional frames, and their data showed a speed impact with an immaterial impact on quality.

It's not entirely surprising that it might have a bigger impact on kinds of content that aren't part of typical encoder test libraries, like anime, but it's not something I'd heard about before. Cool!

[Boulder]

x265's SAO has been broken since the dawn of time. What it needs is a parameter for strength, but that won't happen.

@tormento, try with --no-sao if you lose details. Also --rdoq-level 1 --psy-rd 1.8 --psy-rdoq 5 might be useful.

[tormento]

Why with x265 medium I don't get full CPU utilization such as with slow preset?

I have tried both AVS and VS script and they just do the frame serving part, without any filter.

I have tried different decoders too: DGDecNV, FFVideo, FFMS2, etc.

--pme and --pmode utterly decrease performace.

[FranceBB]

If you're not encoding UHD but rather FULL HD, try to play with the --merange and --ctu.
For instance, for FULL HD you might benefit from limiting CTU to 32.

Try with --ctu 32 --merange 25 and toss --pme and --pmode and tell me how it goes.

P.s too bad you're nowhere near Milan Santa Giulia, but rather in Pavia, 'cause we would have had breakfast together otherwise.

[tormento]

Originally Posted by FranceBB

If you're not encoding UHD but rather FULL HD, try to play with the --merange and --ctu.
For instance, for FULL HD you might benefit from limiting CTU to 32.

Has it any impact about compatibility and compressibility?

Isn't better to increase pool number?

[benwaggoner]

Originally Posted by tormento

Has it any impact about compatibility and compressibility?

Isn't better to increase pool number?

CTU doesn't have any compatibility impact. Using 32 over 64 can reduce compression efficiency some for cleaner content with flatter regions.

You can look in your --log-level 2 .csv file to see how often 64x64 gets used in your encodes.

[tormento]

Setting --pools 10 instead of the default 8 (my logical cores) did the trick.

[Kill3rWolf]

Originally Posted by benwaggoner

You can look in your --log-level 2 .csv file to see how often 64x64 gets used in your encodes.

How can I look at this one in Handbrake? Possible or not? Searched everywhere.

Originally Posted by FranceBB

Try with --ctu 32 --merange 25 and toss --pme and --pmode and tell me how it goes.

merange default is 57. As far I know, a higher range is better...no question, but confusing with the reduction. I'll go lowest 32, but afraid to go more lower.

I was going to ask about CTU, but I think it's well written here: https://en.wikipedia.org/wiki/Coding_tree_unit

[excellentswordfight]

Originally Posted by Kill3rWolf

How can I look at this one in Handbrake? Possible or not? Searched everywhere.



merange default is 57. As far I know, a higher range is better...no question, but confusing with the reduction. I'll go lowest 32, but afraid to go more lower.

The merange values used in the presets are based on a CTU of 64, when lowering CTU they might not be optimal any more. The value of 25 for CTU 32 is based on how its described in the docs:

"The default is derived from the default CTU size (64) minus the luma interpolation half-length (4) minus maximum subpel distance (2) minus one extra pixel just in case the hex search method is used. If the search range were any larger than this, another CTU row of latency would be required for reference frames."

As I see that you ask a lot of questions regarding the different options for x265 I strongly recommend the docs as they covers most questions you have been asking

https://x265.readthedocs.io/en/master/cli.html

[Boulder]

Originally Posted by excellentswordfight

The merange values used in the presets are based on a CTU of 64, when lowering CTU they might not be optimal any more.

It should also be noted that bigger is not always better even with larger CTUs or resolutions. It is possible that the analysis finds a better motion vector but it is still totally wrong if it's tracking an incorrect movement.

I personally use --merange 26 for 1080p or less, --merange 58 for 1440p and CTU 32 for both. I don't know if there's any real benefit from using --hme for >1080p.

[benwaggoner]

Originally Posted by Kill3rWolf

How can I look at this one in Handbrake? Possible or not? Searched everywhere.

I doubt that Handbrake would have that as a GUI option! If there's a way to add your own command line parameters, it could be possible. I always use a x265 binary directly to have full control over parameters.

merange default is 57. As far I know, a higher range is better...no question, but confusing with the reduction. I'll go lowest 32, but afraid to go more lower.

And IIRC, what --merange does can be quite different depending on what --me is set to.