3900X not using 100% with Handbrake

Zepher

[H]ipster Replacement
Joined
Sep 29, 2001
Messages
20,905
Is there a reason why Handbrake is only using around 40% of the 3900X during an X265 encode?

And are the temps I am seeing with HW Monitor and CoreTemp correct? Seems kinda high at 70+ C with only 40% load on the processor, and the max was 88*C according to CoreTemp.
Is it maybe throttling due to temps. I told my friend that we may need to get an aftermarket cooler for his 3900X setup, either a Noctua Air cooler or Corsair AIO. He's going to decide in a day or so which one to get.

handbrake-x265-3900x.jpg

I ran the same test with the same settings on my 4790k and Handbrake uses over 90% of the CPU.

handbrake-x265-4790k.jpg
 
handbrake has issues scaling over 8 threads which is what you're hitting so you might need to mess with it some to get it to scale beyond that. been years since i messed with it though.
 
Is there a reason why Handbrake is only using around 40% of the 3900X during an X265 encode?

And are the temps I am seeing with HW Monitor and CoreTemp correct? Seems kinda high at 70+ C with only 40% load on the processor, and the max was 88*C according to CoreTemp.
Is it maybe throttling due to temps. I told my friend that we may need to get an aftermarket cooler for his 3900X setup, either a Noctua Air cooler or Corsair AIO. He's going to decide in a day or so which one to get.

View attachment 200004

I ran the same test with the same settings on my 4790k and Handbrake uses over 90% of the CPU.

View attachment 200005
Your running two pass encodes. The first pass always does that. It doesn't fully loaded the CPU. On the second pass you should see much better loading of the CPU.

Two pass is kind of old school. You should try playing with the constant quality slider. The whole video won't be locked into a single bitrate. And it will be a one pass encode.
 
handbrake has issues scaling over 8 threads which is what you're hitting so you might need to mess with it some to get it to scale beyond that. been years since i messed with it though.

A couple of years ago when I was using my dual Xeon, I had to run 2 instances of Handbrake and set the affinity for each to 16 threads and it did 100%.

hal-9000-handbrake-encoding-power-usage-dual-xeon.jpg

I was playing around with the affinity settings on the 3900X and it didn't really seem to change, lowered it to 12 and 16 threads, it would just use less threads but the other threads weren't ramping up.
I'll try it again and lower it down to 8 threads and see what happens.
 
Your running two pass encodes. The first pass always does that. It doesn't fully loaded the CPU. On the second pass you should see much better loading of the CPU.

Two pass is kind of old school. You should try playing with the constant quality slider. The whole video won't be locked into a single bitrate. And it will be a one pass encode.

If you look at my second image, it loaded up the 4790k from the get go with the same settings.
 
I loaded up 2 instances, single pass x265, and set 12 threads for each and it loads up to 75% of the CPU, but coretemp shows 85*C.

handrake-2x-x265-1-pass-3900x.jpg
 
So I guess the stock cooler isn't adequate for this CPU, it does look pretty though with the fancy colors, lol.

View attachment 200034
AIO I guess unless there is something going on with your cooling. Max out your cpu fan profile, take the case side off, double check your cpu mount, double check case fan orientation in front out the back or at least Have a methodology to the airflow whatever it is.

Out of ideas.
 
Last edited:
  • Like
Reactions: N4CR
like this
AIO I guess unless there is something going on with your cooling. Max out your cpu fan profile, take the case side off, double check your cpu mount, double check case fan orientation in front out the back or at least Have a methodology to the airflow whatever it is.

Out of ideas.

fans are correct, this is temporary case, will be going into a Thermaltake Level 20 mid tower when I get my friends OS migrated to this machine.

I'll try new thermal paste and see if that improves it, otherwise going with new Air cooler or AIO.
 
  • Like
Reactions: Mega6
like this
I saw similar results testing h.265 1080p encoding between my old system (4770k @ 4.3ghz, 32gb ram) and new (3900x @ 4.0ghz, 32gb ram). I'm a novice when it comes to video encoding so I just tested with the default preset h.265 1080p30.

From my research, handbrake is just a GUI and it's the encoder that doesn't scale well past 6-8 threads. Running multiple video encodes might be the only way to max out the 24 threads currently. I'm hoping future h.265 encoders utilize more threads since I will be converting a lot of x264 files at some point to save space.

My 3900x temps/power usage really climbs at speeds above 4.0ghz even with a NH-D15 cooler. I may have a poorly binned chip (or thermal paste application) but it doesn't boost past 4.05ghz (100% load) at stock settings and uses ~1.3v to do that with high 70's temps. I manually set clocks to 4.0ghz @ 1.16875v and temps decreased by ~10c with minimal performance loss in cinebench. Might be worth looking into.
 
I pulled the cooler and the contact looked good. I slapped on some paste that came with a Cryorig cooler as that is all I have on hand.
Temps look a few degrees cooler so far, 81 vs 85.
 
  • Like
Reactions: Mega6
like this
I pulled the cooler and the contact looked good. I slapped on some paste that came with a Cryorig cooler as that is all I have on hand.
Temps look a few degrees cooler so far, 81 vs 85.
Try without the side panel. I bet your case doesnt have adequate flow in and out.
 
I'll pull the cover off and check.

This is with the new paste,

View attachment 200067
I always understood that x264 would load as many cores as you could throw at it. Maybe x265 is different?

You really like those files small huh? Aren't those already like 4 gigs? I remember I did that a long time ago when I had a 720p plasma.
Bumped up to 1080 and regretted all the time I spent transcoding. Ever thought of just buying another drive? Or are these for some mobile device?
 
So I guess the stock cooler isn't adequate for this CPU, it does look pretty though with the fancy colors, lol.

View attachment 200034


I run the cooler on my 3700x with Corsair TM - 30 .. with the new bios AGESA 1004 and chipset drivers plus those windows updates ..

Set in bios pre CCX .. Ryzen Auto Overclock = 4550 and set power plan to Ryzen HP and my 3700x baseline in for gaming is 4.3 with turbos up to 4375 to 4.4 with that cooler on x470

It is free to do as it wants to and that is the out of box cooler .

 
Last edited:
I always understood that x264 would load as many cores as you could throw at it. Maybe x265 is different?

You really like those files small huh? Aren't those already like 4 gigs? I remember I did that a long time ago when I had a 720p plasma.
Bumped up to 1080 and regretted all the time I spent transcoding. Ever thought of just buying another drive? Or are these for some mobile device?
I watch most of my stuff on my 34" monitor so 2-4gb 720-1080p files are fine for me. Even on my 50 plasma 720p files look decent.

I was just randomly compressing these files for testing purposes and to keep the 3900x loaded with normal apps to see how it performs.

I do need to delete a lot of pr0n on my PC as I am running out of space, lol
HAL-X100-drivespace-11-2019.jpg
 
Handbrake limits you to 8 threads because it sucks.

The actual h265 codec supports far far more threads using wavefront parallel processing.

I can fully load my 3900x using better software. Handbrake is just total newbware.
 
Handbrake limits you to 8 threads because it sucks.

The actual h265 codec supports far far more threads using wavefront parallel processing.

I can fully load my 3900x using better software. Handbrake is just total newbware.

Is this better software a trade secret?

On a side note, I've run handbrake on a 24 thread machine using h.265 codec and I was loaded to around 80% which suggests it can scale well past 8 threads.
 
I use staxrip which can make full complete use of the h265 codec.
What settings do you have as I am only getting 30% CPU usage right now.

Also, the program gives a write error when trying to open files that are on a network share that doesn't have write access, which is kinda lame, why does it need to write back to the source instead of the local temp folder or the destination folder?
 
I personally use MeGUI as a front end for encoding. Handbrake is easier with some things, but it has historically had trouble scaling to higher core/thread count processors - and I've not heard that this has ever changed.
 
What settings do you have as I am only getting 30% CPU usage right now.

Also, the program gives a write error when trying to open files that are on a network share that doesn't have write access, which is kinda lame, why does it need to write back to the source instead of the local temp folder or the destination folder?

You have to specify where the temp folders are etc...

The settings depends. The best thing I can do is make a video for you locally and post it on youtube for you to see how. I will do that for you in a little bit.
 
My friend wanted me to run a test on the machine so he can compare it to his 4770 machine.
Handbrake uses all threads with the H264 codec. His 4770 took almost 2.5 minutes to render and this one took 35-40 seconds to render.
He said that that speed increase makes the upgrade expense worth it.

3900x-handbrake.jpg
 
My friend wanted me to run a test on the machine so he can compare it to his 4770 machine.
Handbrake uses all threads with the H264 codec. His 4770 took almost 2.5 minutes to render and this one took 35-40 seconds to render.
He said that that speed increase makes the upgrade expense worth it.

View attachment 200799
Might be a 264 vs 265 thing.
 
My friend wanted me to run a test on the machine so he can compare it to his 4770 machine.
Handbrake uses all threads with the H264 codec. His 4770 took almost 2.5 minutes to render and this one took 35-40 seconds to render.
He said that that speed increase makes the upgrade expense worth it.

View attachment 200799

2 more Differences from the OP.

1: You are at higher resolution. Higher resolution is allows more blocks per/frame, so more threads can be utilized fully.
2: You are using constant quality (better choice), and the OP is using Two Pass.
 
2 more Differences from the OP.

1: You are at higher resolution. Higher resolution is allows more blocks per/frame, so more threads can be utilized fully.
2: You are using constant quality (better choice), and the OP is using Two Pass.

I just did x265 with both constant quality and 2 pass, and still only get 55-70%. Like mentioned in earlier posts, the x265 encoder in Handbrake doesn't seem to scale well.
 
I just did x265 with both constant quality and 2 pass, and still only get 55-70%. Like mentioned in earlier posts, the x265 encoder in Handbrake doesn't seem to scale well.

Have you tried a higher resolution file/output? Find a 4K sample somewhere and re-encode without resize.
 
No one selects show kernel time to see the i/o, and update speed to high.....why???????????<rhetorical>
 
Yes Handbrake absolutely blows with h265. It under utilizes your CPU. It only uses like 15-25% of your GPU in Cuda/VCE enconding etc...
Its just a badly coded software for h265.

If you want to do 264 use handbrake. If you want to use 265 use Staxrip!

Also just because Handbrake is using 100% cpu on 4k doesn't mean its using the cores good. Lost of wasted processing. Also its hard to control Bframe counts and Bframe lookahead with handbrake.
 
Installed an H100i Pro RGB on the CPU and it keeps it under 70*C in Prime95 and Handbrake..

EDIT: been running Prime for 30 minutes or so and it's sitting at 60*C.
IMG_3899.JPG


h100i-prime95.jpg
 
Last edited:
Hmm... maybe another take on it. I don't think anything is wrong with ya'll systems and at the same time, you guys are not doing anything wrong either. Handbreak uses FFMPEG under the covers. A bit of a stretch here, but very possible the version of ffmpeg bundled with handbreak just needs to be recompiled to support the newer instruction sets for this CPU. Also possible, thread counts in handbrake are hard set. If I CLI my way to victory with FFMPEG and x264 I can easily set the amount of threads I want x264 to use with something like: ffmpeg -i somefile.wmv -c:a libfdk_aac -c:v libx264 -threads 1 transcoded.mp4

I'm doing almost the same thing above for a side project and I found the above information here: https://superuser.com/questions/792525/how-to-change-ffmpeg-threads-settings

I'm following this thread because I'm could potentially be using this cpu series for ffmpeg dev work for my side project.
 
Hmm... maybe another take on it. I don't think anything is wrong with ya'll systems and at the same time, you guys are not doing anything wrong either. Handbreak uses FFMPEG under the covers. A bit of a stretch here, but very possible the version of ffmpeg bundled with handbreak just needs to be recompiled to support the newer instruction sets for this CPU. Also possible, thread counts in handbrake are hard set. If I CLI my way to victory with FFMPEG and x264 I can easily set the amount of threads I want x264 to use with something like: ffmpeg -i somefile.wmv -c:a libfdk_aac -c:v libx264 -threads 1 transcoded.mp4

I'm doing almost the same thing above for a side project and I found the above information here: https://superuser.com/questions/792525/how-to-change-ffmpeg-threads-settings

I'm following this thread because I'm could potentially be using this cpu series for ffmpeg dev work for my side project.

H264 seems to run fine on this CPU it's H265 I was having concerns with. My buddy doesn't plan on using H265 anytime soon so it's not really an issue at the moment.
He did come by last night to play with the machine and make sure it loads his projects in Corel, Premiere and Indesign without issue, and it performed perfectly.
Also did a Premiere Pro export of a 2 hour edit he made and it did it in about 13 minutes, his 4770 does it in about 45 minutes, so he was really impressed.

He'll be bringing his 4770 system over Saturday for me to swap in the new board and cooler.
 
Hmm... maybe another take on it. I don't think anything is wrong with ya'll systems and at the same time, you guys are not doing anything wrong either. Handbreak uses FFMPEG under the covers. A bit of a stretch here, but very possible the version of ffmpeg bundled with handbreak just needs to be recompiled to support the newer instruction sets for this CPU. Also possible, thread counts in handbrake are hard set. If I CLI my way to victory with FFMPEG and x264 I can easily set the amount of threads I want x264 to use with something like: ffmpeg -i somefile.wmv -c:a libfdk_aac -c:v libx264 -threads 1 transcoded.mp4

I'm doing almost the same thing above for a side project and I found the above information here: https://superuser.com/questions/792525/how-to-change-ffmpeg-threads-settings

I'm following this thread because I'm could potentially be using this cpu series for ffmpeg dev work for my side project.

Not meaning to derail the thread but here's a possible setting you can use.

If you leave the thread option off ffmpeg will use all available threads for an x264 encode. I have 12c/24t available and can saturate all threads. I feed shell commands via AppleScript so I can drag'n'drop multiple files to do batch processing but the non-AppleScript command looks something like:

ffmpeg -y -i input.mp4 -c:v libx264 -q 22 -r 30 -f mp4 -preset medium -profile:v main -level 3.1 -strict -2 -c:a aac -ac 1 -movflags faststart output.mp4

The movflags option places the moov atom to the beginning of the resultant video file to allow the file to be played whilst downloading (pretend streaming).

I find the output to be a rather decent compromise between size and quality regardless of source (we tend to do a lot of training videos where you need non-artifacting Full Motion Video (FMV) and static content—slides and code). I use a very basic profile so as to maintain compatibility with a large amount of devices.
 
Not meaning to derail the thread but here's a possible setting you can use.

If you leave the thread option off ffmpeg will use all available threads for an x264 encode. I have 12c/24t available and can saturate all threads. I feed shell commands via AppleScript so I can drag'n'drop multiple files to do batch processing but the non-AppleScript command looks something like:

ffmpeg -y -i input.mp4 -c:v libx264 -q 22 -r 30 -f mp4 -preset medium -profile:v main -level 3.1 -strict -2 -c:a aac -ac 1 -movflags faststart output.mp4

The movflags option places the moov atom to the beginning of the resultant video file to allow the file to be played whilst downloading (pretend streaming).

I find the output to be a rather decent compromise between size and quality regardless of source (we tend to do a lot of training videos where you need non-artifacting Full Motion Video (FMV) and static content—slides and code). I use a very basic profile so as to maintain compatibility with a large amount of devices.

Not derailing either. Algrim is totally right, by default if you dont specify it, it'll use it all. Kinda leads me back to thinking the version of bundled ffmpeg with handbrake needs to be recompiled or updated for the new instruction sets.

this part is derailing tho.. If you are doing pretend streaming, poop your renders out to m3u8 instead of mp4. I've found that some web based players will download a ton of the file, even if the mov atom is up front before playing, and seeking can be awful. Not a big deal with an mp4 that's only a few megs but larger ones can make it seem like nothing is happening when the device you are playing it on is just downloading a lot of the file. If you poop it out to m3u8 with +faststart, seeking works really well with webbased players, and you only download the segments needed for that block of time you are looking at.
 
Back
Top