Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 19th September 2022, 09:17   #1  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
x265 low CPU when preset medium

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.
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 19th September 2022, 09:20   #2  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
--ctu 32
Atak_Snajpera is offline   Reply With Quote
Old 19th September 2022, 10:01   #3  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
Quote:
Originally Posted by Atak_Snajpera View Post
--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.
__________________
@turment on Telegram

Last edited by tormento; 19th September 2022 at 10:20.
tormento is offline   Reply With Quote
Old 19th September 2022, 10:23   #4  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
What is resolution of your video file? What is average CPU usage during encoding?
Atak_Snajpera is offline   Reply With Quote
Old 19th September 2022, 11:06   #5  |  Link
rwill
Registered User
 
Join Date: Dec 2013
Posts: 343
With all relevant information being withheld by tormento all I can suspect is some lookahead-slices crap.
rwill is offline   Reply With Quote
Old 19th September 2022, 12:28   #6  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
Quote:
Originally Posted by Atak_Snajpera View Post
What is resolution of your video file? What is average CPU usage during encoding?
1080p

49-81% on medium
burning sun on slow
__________________
@turment on Telegram

Last edited by tormento; 19th September 2022 at 12:44.
tormento is offline   Reply With Quote
Old 19th September 2022, 12:29   #7  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
Quote:
Originally Posted by rwill View Post
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?
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 19th September 2022, 12:45   #8  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Quote:
Originally Posted by tormento View Post
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%.
Atak_Snajpera is offline   Reply With Quote
Old 19th September 2022, 13:01   #9  |  Link
Rumbah
Registered User
 
Join Date: Mar 2003
Posts: 480
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.
Rumbah is offline   Reply With Quote
Old 19th September 2022, 13:09   #10  |  Link
rwill
Registered User
 
Join Date: Dec 2013
Posts: 343
What about "--lookahead-threads 4" ? Or "--frame-threads 3" ?
rwill is offline   Reply With Quote
Old 19th September 2022, 17:44   #11  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
Quote:
Originally Posted by Atak_Snajpera View Post
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%?
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 19th September 2022, 17:56   #12  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
Quote:
Originally Posted by rwill View Post
--lookahead-threads 4
Testing --lookahead-threads 4 --pools 12, seems faster. Thanks
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 20th September 2022, 10:38   #13  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
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.
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 20th September 2022, 16:27   #14  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by tormento View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 20th September 2022, 16:30   #15  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by tormento View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 20:41.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.