Best x265 software and time/quality settings?

[YaBoyShredderson]

Im thinking of changing my bluray encodes from x264 in handbrake to x265 to squeeze out a little more space.
In handbrake with x264 i use crf 18, very slow, film tune, high profile, level 4.1. Audio i set it to ac3 5.1 640kbs.

I was thinking of using staxrip instead as its what i use for my 4k blurays, but im still a little confused with it. Im thinking of using 10bit too, and with 2 pass abr instead of crf as with my current settings, the file sizes can vary so wildy, and some files actually get bigger. Im think of using 7mbits, which im aware is a bit high for x265, but i dont mind bloating the easilt compressed stuff a bit, at least i know the quality will be practically lossless. The harder to compress stuff, where 7mbits can be considered a "low" bitrate, will benefit from x265s efficency and wont be stupid artifacty.

Im not as familiar with x265 as i am with x264, and i have a couple of questions. In terms of preset, the general wisfom is to go as slow as one can bare, but im wondering what the difference is between slow and slower mainly, im not too concerned about the others. With x264 veryslow i can encode faster than realtime pretty much, 25-30fps give or take, and thats with limiting thread count too. Im asking if theres is maybe a 1-2% improvment in efficency, at like half the speed, and is therefore not worth it, that kind of question.

I also want to know if i should leave tune at none, as there is no film tune. For my 4k stuff, i essentially set the same settings as film tune manually, but i cant remember what it was. Also, what about thred count? I put threads=18 in the advanced options in handbrake, as i have 12c/24t 5900x, and opening 36 threads is a lot, as the quality loss begins to become noticable at that point. Im thinking, as x265 equals thread count, rather than 1.5x like x264, i should set frame threads to 12, and run 2 encodes at the same time? Or would it be worth going lower, how much difference in quality would it make, or is it just not relevant with 12 threads?

Also, what level should i use? If i leave it on automatic, i can only use main, not high for x265. For x264, level 4 was generally what i needed, it only mentioned bitrates and resolutuons n stuff, 25mbits for 1080p which was all i really need. For x265, i read that 12 mbits is the max for 4.0, which seems quite low, but that 30 was the max if i use high? Also, i noticed it was mentioning something to do with luma and stuff, which i dont understand, and i used 5.1 with my 4k stuff to avoid messing with the hdr.

Also, audio. I use ac3 640kbs for 5.1 as ac3 is a very old inneficient codec, and i was told thay anything less than max can make the difference noticable, but i may as well save space on audio too. What is the "HEVC" of audio coding? I want something that would also generally work with a soundbar or sound system, as i want to get one in the future. I was thinking aac or opus. I heard opus is very efficent. Whst bitratw should i use? 384? 512?

Thanks.

[benwaggoner]

x265's default tuning is generally just fine. Using --preset slower is where the best features of HEVC generally kick in, but it'll still be a lot slower than x264 veryslow.

The Main profile of HEVC is equivalent to High in x265. Main10 would be used for 10-bit instead of High10. x265 is generally able to use more threads than x264 at a given frame size. If you are doing 1080p, you probably don't need to be running in parallel with only 12 physical cores, and can just leave it at default. Using more than you have logical cores is pointless, and probably would cause encoding to become slower overall at some point due to the extra overhead of parallelization.

By Level, do you mean Tier? A typical 1080p encode for distribution/playback would be Main Profile Level 4.0 Main Tier. High Tier is more for creating high-bitrate mezzanine files. High Tier is basically all the same constraints of Profile & Level, except allowing much higher bitrates than Main Tier. But, for the same reason, not as compatible for device decoding.

For 1080p24, 12 Mbps peak is generally quite ample with x265. 1080p50 would use a higher profile with a higher max bitrate.

[YaBoyShredderson]

Originally Posted by benwaggoner

x265's default tuning is generally just fine. Using --preset slower is where the best features of HEVC generally kick in, but it'll still be a lot slower than x264 veryslow.

The Main profile of HEVC is equivalent to High in x265. Main10 would be used for 10-bit instead of High10. x265 is generally able to use more threads than x264 at a given frame size. If you are doing 1080p, you probably don't need to be running in parallel with only 12 physical cores, and can just leave it at default. Using more than you have logical cores is pointless, and probably would cause encoding to become slower overall at some point due to the extra overhead of parallelization.

By Level, do you mean Tier? A typical 1080p encode for distribution/playback would be Main Profile Level 4.0 Main Tier. High Tier is more for creating high-bitrate mezzanine files. High Tier is basically all the same constraints of Profile & Level, except allowing much higher bitrates than Main Tier. But, for the same reason, not as compatible for device decoding.

For 1080p24, 12 Mbps peak is generally quite ample with x265. 1080p50 would use a higher profile with a higher max bitrate.

So its worth using slower over slow? Not worth going much slower than that?

I heard that x265 was LESS parralelizable than x264? Would it not still make sense to use only 12 threads out 24 anyway? I can play games while encoding, and when im not playing, i can run a second encode. Does fewer threads not mean higher compression efficiency like with x264? If only marginal?

Yes thats what i thought, high is just another set of restraints. It wont impact quality unless i max out the main teir of whatever level im on. At first i thought it was like x264, where high is actually more efficient than main.

So leaving level unrestricted is best?

[lazyjss]

I am using a nvidia turing gen graphics card to encode my 4k uhd blu ray rips.
Stax rip is a the best program I have found for this.

I have done a lot of pixel peeping and it is not worth the long encode times for me, so I am using hardware acceleration.

hdr metadata gets pass through and files sizes are larger however than software.
Something to think about.

[YaBoyShredderson]

Originally Posted by lazyjss

I am using a nvidia turing gen graphics card to encode my 4k uhd blu ray rips.
Stax rip is a the best program I have found for this.

I have done a lot of pixel peeping and it is not worth the long encode times for me, so I am using hardware acceleration.

hdr metadata gets pass through and files sizes are larger however than software.
Something to think about.

I tried that, turing nvenc squashed a lot of detail out, even at high bitrates. The only time it didnt was at bitrates so high its not worth compressing in the first place.

[benwaggoner]

[QUOTE=YaBoyShredderson;1935598]So its worth using slower over slow? Not worth going much slower than that?/QUOTE]
veryslow and placebo will give some small incremental gains at the cost of a lot of encoding time. Slower is where most of the good stuff kicks in, so quality tuning between slower-veryslow-placebo is pretty similar.

I heard that x265 was LESS parralelizable than x264?/QUOTE]
Not in my experience, but it may vary depending on preset and other parameters. Wavefront Parallel Processing (wpp) is one useful feature for parallelism not in H.264. And x265 has features like --pmode which offer other paths to increase parallelism.

QUOTE]Would it not still make sense to use only 12 threads out 24 anyway? I can play games while encoding, and when im not playing, i can run a second encode. Does fewer threads not mean higher compression efficiency like with x264? If only marginal?/QUOTE]
Sure, if you want to do other things, sure. Fewer threads can impact quality slightly because a variety of parameters auto-adjust based on the number of available threads, but you can get the same results by manually setting those parameters. On my dual-socket workstation, I almost always pin encoding to one or the other physical CPU for this reason. It's only with 8K encoding that more than 36 logical threads wind up being more important that the NUMA overhead.

QUOTE]Yes thats what i thought, high is just another set of restraints. It wont impact quality unless i max out the main teir of whatever level im on. At first i thought it was like x264, where high is actually more efficient than main.

You're talking about High Profile in x264. The equivalent in x265 would be using Main10 or something. The key tool of High Profile in H.264 is allowing for 8x8 blocks. HEVC's Main allows for up to 32x32 blocks.

Tier is something orthgonal.

So leaving level unrestricted is best?

Letting x265 pick for you is generally fine, unless you're doing something unusual and specific. Unrestricted is bad because you can't predict decoder compatibility. I've only ever had an unrestricted level when doing lossless encoding, since there is no way to control VBV anyway.

[YaBoyShredderson]

Originally Posted by benwaggoner

Letting x265 pick for you is generally fine, unless you're doing something unusual and specific. Unrestricted is bad because you can't predict decoder compatibility. I've only ever had an unrestricted level when doing lossless encoding, since there is no way to control VBV anyway.

Thanks for all this advice. Last thing, should i leave it unrestricted then or lock to either 4.0 or 4.1? I will using 2 pass abr of 7mbits (im aware thats generally considered quite high for x265 1080p?) but am not sure if some content may come out with some scenes on the extremes, needing more than 12mbits.

[benwaggoner]

Originally Posted by YaBoyShredderson

Thanks for all this advice. Last thing, should i leave it unrestricted then or lock to either 4.0 or 4.1? I will using 2 pass abr of 7mbits (im aware thats generally considered quite high for x265 1080p?) but am not sure if some content may come out with some scenes on the extremes, needing more than 12mbits.

There are some older devices with 4.0 but not 4.1 decoders, so I'd go for 4.0 unless you find content where the 4.0 limit has a quality impact if you're worried about broad compatibility. If you're only going to use it on 4.1+ devices, then no reason not to use the higher limit. I don't think anyone is still shipping 4.0 only hardware.

[DMD]

Good evening.
I am also interested in the best compromise between speed and quality, personally I am interested in UHD encoding in H265, from what I understand software encoding turns out to be the best.
As a software I use StaxRip, I don't know if there are better than this.
Using StaxRip a Slower preset should be a good compromise with the final quality, are there any obvious differences with Very Slow?
At the CPU level, the minimum number of cores it must have to work at its best?
Thank you

[Kill3rWolf]

Originally Posted by benwaggoner

HEVC's Main allows for up to 32x32 blocks.

That's why CTU 32 is recommended for HEVC's Main?

[benwaggoner]

Originally Posted by Kill3rWolf

That's why CTU 32 is recommended for HEVC's Main?

It's more that 32 is the highest "safe" size. 64 is slightly more efficient, but can cause some visible issues with noisy content. I would use it for clean content like cel or computer animation.