x265 low CPU when preset medium

[tormento]

I have tried to encode a bunch of files with x265 on preset medium.

It can't occupy 100% CPU, while on preset slow it goes full throttle.

It isn't a decoding issue, as I am using DGDecNV (and I tried sw decoding too), it isn't a slow script issue as I tried both AVS+ with
and without Prefetch (and tried VS too).

Any idea about how to increase CPU usage? I have tried to increase pools too but no way.

[Atak_Snajpera]

--ctu 32

[tormento]

--ctu 32
Maximum CU size (width and height). The larger the maximum CU size, the more efficiently x265 can encode flat areas of the picture, giving large reductions in bitrate. However this comes at a loss of parallelism with fewer rows of CUs that can be encoded in parallel, and less frame parallelism as well. Because of this the faster presets use a CU size of 32. Default: 64

How much is the bitrate impact when lowering it?

I forgot to say that I have a 4 core / 8 threads CPU, not so many to have parallelism problems, perhaps.

[Atak_Snajpera]

What is resolution of your video file? What is average CPU usage during encoding?

[rwill]

With all relevant information being withheld by tormento all I can suspect is some lookahead-slices crap.

[tormento]

What is resolution of your video file? What is average CPU usage during encoding?

1080p

49-81% on medium
burning sun :) on slow

[tormento]

With all relevant information being withheld by tormento all I can suspect is some lookahead-slices crap.
Is there anything I can do to prevent that?

[Atak_Snajpera]

49-81% on medium
burning sun :) on slow

With 80% you already use more than 90% percent of your cpu computation power. 50% is about 80%. SMT in video encoding does not give more than 20%.

[Rumbah]

The way I do it is to cut the video in n parts and encode them in parallel. The drawback is that it uses n times the RAM.

[rwill]

What about "--lookahead-threads 4" ? Or "--frame-threads 3" ?

[tormento]

With 80% you already use more than 90% percent of your cpu computation power. 50% is about 80%. SMT in video encoding does not give more than 20%.
Ooook... why on slow I have steady 100%?

[tormento]

--lookahead-threads 4
Testing --lookahead-threads 4 --pools 12, seems faster. Thanks ;)

[tormento]

Well. I looked at my night encode logs and there are looong moments of low cpu usage.

It seems that my initial happyness was not well grounded.

[benwaggoner]

Well. I looked at my night encode logs and there are looong moments of low cpu usage.

It seems that my initial happyness was not well grounded.
Sometimes there's only so much for the CPU to do during certain kinds of content. For example, in end-credits the encoder can get to extremely good matches extremely quickly. It's a feature, not a bug, that the encoder doesn't spend unneeded compute, electricity, and waste heat.

That said, there could still be some other potential bottleneck in source read, demux, decode, preprocessing, encoding, and writing out the file. And those can be limited by i/o as easily as by compute. All it takes is some slower single-threaded process somewhere in the signal chain to slow everything down.

A good way to test that is to use increasingly higher --presets. If slow and slower have ballpark the same encoding time but slower has higher CPU usage, that suggests some non-x265 bottleneck.

[benwaggoner]

Maximum CU size (width and height). The larger the maximum CU size, the more efficiently x265 can encode flat areas of the picture, giving large reductions in bitrate. However this comes at a loss of parallelism with fewer rows of CUs that can be encoded in parallel, and less frame parallelism as well. Because of this the faster presets use a CU size of 32. Default: 64

How much is the bitrate impact when lowering it?
It is really quite minor most of the time, and can actually improve quality when encoding with noisy sources. I've seen it been helpful mostly at extremely low bitrates and at 2160p with clean sources.

I forgot to say that I have a 4 core / 8 threads CPU, not so many to have parallelism problems, perhaps.[/QUOTE]
Oh! Yeah, even 480p should be able to saturate that.