Better x265 medium or x264 slow?

[tormento]

The title tells it all.

I always used x265 on movies I love and x264 on movies I like.

Do you think that x265 preset medium crf 22 can outperform x264 preset slow crf 20 in quality?

[Arkana]

Not sure with slow but veryslow x264 surpass x265 medium at same bitrate (both CRF mode). At least from my own test.

[Boulder]

The title tells it all.

I always used x265 on movies I love and x264 on movies I like.

Do you think that x265 preset medium crf 22 can outperform x264 preset slow crf 20 in quality?

Probably not. I'd say x265 needs at least --preset slow, preferably --preset slower. And --aq-mode 1 :D

[gonca]

I always used x265 on movies I love and x264 on movies I like.
If movies are 4K HDR then it is a moot point.
Otherwise, use your eyes in your normal viewing conditions

[benwaggoner]

I have seen some oddball examples with very heavy, fine grain where --preset slow looked better than --preset slower. After a deep dive, it turned out that it was about --rd 4 versus --rd 6. For some types of noise, --rd 4 outperforms --rd 6 by a pretty big margin. This has been mostly an issue in 4K encoding.

But yeah, in general I prefer to use at least --preset slower.

[tormento]

I have seen some oddball examples with very heavy, fine grain
Latest movies use digital cameras with almost no noise if not in postproduction.

Older ones deserve some kind of denoising most of times.

I am not the person who calls pure noise "details".

[Kill3rWolf]

I got the same question as you, thanks for posting.

Curious minds want to know something, could you tell me about your PC configuration?

[tormento]

Curious minds want to know something, could you tell me about your PC configuration?
Intel i7-2600k @ 4.5 GHz
Asus P8Z77 WS custom bios
16 GB DDR3
Nvidia 1060 3GB
3 x Samsung 860 Pro

[benwaggoner]

Latest movies use digital cameras with almost no noise if not in postproduction.
Rarely in production, often in post-production. Grain gives that "filmic" look, and makes it easier to composite in VFX, and to mix 2K elements with 4K production.

Older ones deserve some kind of denoising most of times.
I've seen the most severe issues in newer content with synthesized grain. Particularly when they try to get the feel by doing some per-pixel RGB randomization. Actual Super35 film grain has bigger, softer particles in practice.

I am not the person who calls pure noise "details".
Right, in the sense no one cares if each frame has its grain particles in the same place as the source. It's really about preserving the feel.

There is also some bad thinking around "creative intent" meaning preserving all the grain in the negative. If the creators watched the movie on a projector on a perf screen, they wouldn't have seen the grain either. I don't think we need to preserve fine grain that was never seen by the people who made it!

[Gravitator]

Parity in?: SD, HD, FHD, UHD.

[tormento]

Parity in?: SD, HD, FHD, UHD.


Mostly 1080p

[benwaggoner]

Mostly 1080p
I haven't found any 1080p content where slow > slower, and plenty of content where slower > slow. The biggest deltas are in things like text, animation, and graphics. Amp, rect, more B and reference frames, and more TU size options can help a lot.

[RanmaCanada]

I'd have to agree with Boulder. Preset Slow or Slower only, as Medium is just to janky. You should also be using CRF 17-19 for movies as per the spreadsheet (https://docs.google.com/spreadsheets/d/1u9fKNsRcLgc-1oVV5GhBgoPGO9vLpcn-x3NUgTmeC-0/edit#gid=0) that was posted here quite some time ago. Some of the settings may be outdated, but it's a great guide.

[tormento]

And for anime with no noise or grain at all?

[Boulder]

And for anime with no noise or grain at all?

x265 might be better due to the larger CTU size it can use if the material is rather flat. --sao could be useful as well.

[tormento]

x265 might be better due to the larger CTU size it can use if the material is rather flat. --sao could be useful as well.


Isn’t that in animation preset already?

[Boulder]

--sao is in all tunings I think? It's just that most people use --no-sao to disable it as it can remove a lot of details from the video unless you use --selective-sao 1 or 2.

[benwaggoner]

And for anime with no noise or grain at all?
That kind of content start to really shine with --preset slower and higher. And gets more benefit from slower -> veryslow -> placebo.

Also --tskip really helps, by providing a non-DCT-like mode for TUs for flat content with very sharp edges, like text and animation lines.

--preset slower --tskip --tskip-fast will encode a lot faster and still look better than --preset placebo.

--tu-intra-depth 4 --tu-inter-depth 4 can also be great for this stuff, to allow for small TUs to encapsulate very sharp edges. With a min 4x4 TU plus --amp and --rect allows TUs to match the shape of a single sharp edge really well for better efficiency and better quality at a given QP.

[benwaggoner]

--sao is in all tunings I think? It's just that most people use --no-sao to disable it as it can remove a lot of details from the video unless you use --selective-sao 1 or 2.
Have you found examples of content where you get visibly different output with the different --selective-sao modes? Do you have any examples to share?

Prior test data demonstrated perf improvements from --selective-sao, and that was the intent of the feature. Quality improvements weren't anticipated nor discovered in testing.

[Boulder]

Have you found examples of content where you get visibly different output with the different --selective-sao modes? Do you have any examples to share?

Prior test data demonstrated perf improvements from --selective-sao, and that was the intent of the feature. Quality improvements weren't anticipated nor discovered in testing.

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?

--selective-sao 1 has a very subtle effect on I-frames, whereas --selective-sao 2 already blurs P-frames quite a lot - even in rather still scenes so it's not motion related in any way.

PNG screenshot file sizes are a good way to compare the amount of blurring in my opinion.

I-frame:
lossless -- 3035 kB
ssao 1 -- 2804 kB
ssao 2 -- 2804 kB (tested that it works properly :))

P-frame (the next after the I-frame):
lossless -- 2995 kB
ssao 1 -- 2895 kB
ssao 2 -- 2791 kB (especially the background is blurrier upon investigation, also hair)

B-frame (right after the I-frame):
lossless -- 2980 kB
ssao 1 -- 2751 kB
ssao 2 -- 2747 kB

[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]

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]

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]

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]

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.

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]

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]

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]

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.