x265 HEVC Encoder

[Barough]

x265 v3.2+34-8e6db24c1517 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[benwaggoner]

Originally Posted by utack

I am surprised how much difference "slower" makes compared to "slow"
It is probably expected due to all the extra bframes giving a quality gain and much more lookahead making different choices what to prioritize, but was not fully aware of it before testing.

I've kinda thought of slower as the first "real" x265 preset, where most of the stuff that makes HEVC better are in play. The quality gap between slower and placebo is smaller than that between slow and slower.

Except for lossless, where placebo has a pretty significant efficiency gain over even veryslow.

[Blue_MiSfit]

I'd say "Slow" is a good compromise, but yeah, "Slower" is really where all the magic happens

[Magik Mark]

I have 16 threads CPU. Is there a way to instruct x265 to use only 14?

Need the rest for other apps

[Atak_Snajpera]

Originally Posted by Magik Mark

I have 16 threads CPU. Is there a way to instruct x265 to use only 14?

Need the rest for other apps

I would just run x265.exe in IDLE priority. You may also use Process Explorer to change affinity to only 14 logical processors.

[vpupkind]

Originally Posted by benwaggoner

It would be counterproductive in fact. IIRC, hdr10-opt adjusts delta qp for chroma based on luma levels to better match the characteristics of the PQ EOTF. By default x265 is more optimized for gamma. hdr10-opt would thus be bad for 709 or HLG. Dolby Vision, except in profiles that have a backwards compatible PQ base layer, doesn't even use Y'Cb'Cr, and in Profile 5 does some crazy dynamic range adjustments, so not helpful there.

There's probably fruitful research to be done for how to adapt chroma qp relative to luma based on each macroblock's luma levels in a psychovisual model.

ISO/IEC 23008-14 does that. I haven't had too much luck with their recommendations -- they destroyed textures in very bright scenes (think icy mountains).

[benwaggoner]

Originally Posted by Magik Mark

I have 16 threads CPU. Is there a way to instruct x265 to use only 14?

--pools "14" should exactly limit it to 14 cores.

https://x265.readthedocs.io/en/defau...l#thread-pools

[Rousseau]

Originally Posted by Barough

x265 v3.2+34-8e6db24c1517 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)

https://bitbucket.org/multicoreware/x265/commits/branch/default

multi-pass-opt-analysis / distortion causes a crash in this build.

[Magik Mark]

Originally Posted by benwaggoner

--pools "14" should exactly limit it to 14 cores.



https://x265.readthedocs.io/en/defau...l#thread-pools

Thanks alot!


Sent from my iPhone using Tapatalk

[jlpsvk]

Is there any way to fully utitlise x265 with single process (without distrubuted encoding) on Ryzen 9 3950X (16c/32t) without quality loss?

[benwaggoner]

Originally Posted by jlpsvk

Is there any way to fully utitlise x265 with single process (without distrubuted encoding) on Ryzen 9 3950X (16c/32t) without quality loss?

What resolution are you encoding to?

--preset slower --pmode --pme should saturate most systems. Although it's often faster to leave out --pmode and --pme if the cores/pixels ratio isn't that high. The goal is to maximize fps, not CPU load. PMode is typically a lot more useful than PME, which I've only seen to be helpful at SD resolutions and below.

PMode and PME don't have any negative quality impact, and pmode can actually help a trifle, potentially.

Doing 2160p on an 18/36 system encoding is ~30% faster without pmode than with it, even though CPU load is about 50% versus ~90%.

[Boulder]

--pmode can have a negative impact in CRF mode, so be warned. I just experienced that.. it produced a lower bitrate than without --pmode at the same settings at CRF 18, and I happened to check a scene with a heavily noisy picture. The dancing of the noise was much uglier than in a test encode without --pmode.

[Atak_Snajpera]

Originally Posted by jlpsvk

Is there any way to fully utitlise x265 with single process (without distrubuted encoding) on Ryzen 9 3950X (16c/32t) without quality loss?

--ctu 32

[benwaggoner]

Originally Posted by Atak_Snajpera

--ctu 32

Right! There are other ways to increase parallelism, at the risk of some hits to compression efficiency. However, with a whole lot of cores, quality @ perf might have a different optimal configuration, like using more frame thread and a higher RD level. Other parameters in the same bucket:

-F >4 (this had quality hits in older versions; not sure of the impact in 3.x)
--lookahead slices >8 (It seems like this shouldn't have a quality hit, but it is 1 in the slowest presets)

Another thing that might help (haven't tested) without impacting quality is --selective-sao 2. SAO itself limits parallelism somewhat per https://x265.readthedocs.io/en/default/threading.html. So turning it off for B-frames could help. Although it's also possible that the latency hit is fixed whenever SAO is on at all, so --no-sao might help, although with efficiency hits, particularly at lower bitrates. Worth testing.

[benwaggoner]

Originally Posted by Boulder

--pmode can have a negative impact in CRF mode, so be warned. I just experienced that.. it produced a lower bitrate than without --pmode at the same settings at CRF 18, and I happened to check a scene with a heavily noisy picture. The dancing of the noise was much uglier than in a test encode without --pmode.

Oh, good tip! That isn't supposed to happen in theory. You should provide a bug report and repro to MultiCoreWare so they can look at this deeper.

[jlpsvk]

Originally Posted by benwaggoner

What resolution are you encoding to?

--preset slower --pmode --pme should saturate most systems. Although it's often faster to leave out --pmode and --pme if the cores/pixels ratio isn't that high. The goal is to maximize fps, not CPU load. PMode is typically a lot more useful than PME, which I've only seen to be helpful at SD resolutions and below.

PMode and PME don't have any negative quality impact, and pmode can actually help a trifle, potentially.

Doing 2160p on an 18/36 system encoding is ~30% faster without pmode than with it, even though CPU load is about 50% versus ~90%.

I am encoding 2160p, with CRF16.

[Boulder]

Originally Posted by benwaggoner

--lookahead slices >8 (It seems like this shouldn't have a quality hit, but it is 1 in the slowest presets)

This probably affects frame type decision, at least that's what I observed when using four lookahead slices compared to just one.

Oh, good tip! That isn't supposed to happen in theory. You should provide a bug report and repro to MultiCoreWare so they can look at this deeper.

It's probably due to the encoder doing deeper analysis as some performance related early skips are avoided. Nevertheless, I got a clip of the scene for my testing toolkit and I can definitely create a ticket for the issue. Maybe there is something there to fix.

[jlpsvk]

i tested, and without pme and pmode, it's faster.

[microchip8]

Originally Posted by benwaggoner

Right! There are other ways to increase parallelism, at the risk of some hits to compression efficiency. However, with a whole lot of cores, quality @ perf might have a different optimal configuration, like using more frame thread and a higher RD level. Other parameters in the same bucket:

-F >4 (this had quality hits in older versions; not sure of the impact in 3.x)
--lookahead slices >8 (It seems like this shouldn't have a quality hit, but it is 1 in the slowest presets)

Another thing that might help (haven't tested) without impacting quality is --selective-sao 2. SAO itself limits parallelism somewhat per https://x265.readthedocs.io/en/default/threading.html. So turning it off for B-frames could help. Although it's also possible that the latency hit is fixed whenever SAO is on at all, so --no-sao might help, although with efficiency hits, particularly at lower bitrates. Worth testing.

I have tested a few samples with SAO and selective-sao set to 2. I find the result looking too soft. Without it, there's more detail present. But if others like it, who am I to stop them?

[jlpsvk]

Originally Posted by froggy1

I have tested a few samples with SAO and selective-sao set to 2. I find the result looking too soft. Without it, there's more detail present. But if others like it, who am I to stop them?

exactly... my 2160p HDR10 preset currently...any suggestions?

--preset slow --profile main10 --level-idc 5.1 --output-depth 10 --crf 16 --ctu 64 --aq-mode 4 --merange 57 --amp --no-rskip --qg-size 8 --vbv-bufsize 160000 --vbv-maxrate 160000 --bframes 8
--rc-lookahead 48 --gop-lookahead 30 --hdr10 --hdr10-opt --repeat-headers --no-info --no-deblock --no-sao --selective-sao 0 --allow-non-conformance --no-strong-intra-smoothing --high-tier --chromaloc 2
--fades --hme --hme-search umh,umh,star