Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Kuray

macrumors regular
Original poster
Jul 24, 2010
135
1
When I convert video with HandBrake, my Processor is not being used fully.


It's used around %40-%50

Average Convert: 101 fps


Why it's happening?
I want my computer use its full process power, not half of it

MacBook Pro (15-inch, Early 2011)
Processor 2 GHz Intel Core i7
Memory 8 GB 1333 MHz DDR3
Graphics AMD Radeon HD 6490M 256 MB
Hard Drive 120 GB 6G SATAIII SSD
 
HB is fully using one core. It is not a multi-core app, so it can't use anymore.
 
Handbrake scaled on my old Core 2 Duo. I remember plenty of threads where it hit 4 cores. Though it was some time ago the solution on a Mac Pro was to run two instances of the application.
 
Handbrake scaled on my old Core 2 Duo. I remember plenty of threads where it hit 4 cores. Though it was some time ago the solution on a Mac Pro was to run two instances of the application.

Yeah, I have a Mac Mini Core 2 Duo, and running encodes in Handbrake, the CPU usually stays right around 180%.
 
Handbrake scaled on my old Core 2 Duo. I remember plenty of threads where it hit 4 cores. Though it was some time ago the solution on a Mac Pro was to run two instances of the application.

What do you mean by "two instances of the app"


Run 2 HandBrake and convert 2 different video at the same time ?
 
When I convert video with HandBrake, my Processor is not being used fully.


It's used around %40-%50

Average Convert: 101 fps


Why it's happening?
I want my computer use its full process power, not half of it

MacBook Pro (15-inch, Early 2011)
Processor 2 GHz Intel Core i7
Memory 8 GB 1333 MHz DDR3
Graphics AMD Radeon HD 6490M 256 MB
Hard Drive 120 GB 6G SATAIII SSD

Give us a screen shot while you are running handbrake of what the activity monitor looks like set to the CPU tab please.
 
HB is fully using one core. It is not a multi-core app, so it can't use anymore.

It most certainly is a multi-core aware app. Go encode a DVD, you'll see a spike in both (or all 4) cores. I think on something like the 12-core Mac Pro, it doesn't utilize all the cores, but on a dual or quad core machine, it should use all the cores.

OP, your problem isn't CPU usage, but likely other bottlenecks. Are you using your internal SuperDrive? It's not very fast, and it limits how much information the DVD can transfer in any given period of time. If your internal HDD is 5400 rpm, that's another bottleneck as that limits how fast the information can be written to your HDD. EDIT: Somehow I missed that you have an SSD, that's definitely not a bottleneck.

So your computer is working full speed on the information it's given, but that's not enough to shoot it up to 100% on both cores. I have a 52x DVD drive on USB 2 and it's WAY faster than my internal drive. HandBrake encodes are much faster from it than from my SuperDrive.
 
The early 2011 has a quad core with hyper threading, there are 8 threads, two per core.

For an app like handbrake, it doesn't make sense to use all 8 threads, since the CPU power is the same if only using 4 threads, and using all 8 would make the system unusable. With 4 threads as 100%, the activity monitor should report handbrake as using 400% CPU, and the ActivityMonitor should report the CPU as 50% load, 50% idle, since 4 threads are unused.
 
Handbrake is one of the most heavily threaded apps out there. It will take advantage of multiple cores.

The only sensible reply to this thread mentioned bottle necks. Are you ripping direct from the super drive? If you are converting a file from a local hard drive, then there must be an issue with your encoding profile settings. Try to set them to default, or check carefully, especially the advanced settings.
 
It most certainly is a multi-core aware app. Go encode a DVD, you'll see a spike in both (or all 4) cores. I think on something like the 12-core Mac Pro, it doesn't utilize all the cores, but on a dual or quad core machine, it should use all the cores.

OP, your problem isn't CPU usage, but likely other bottlenecks. Are you using your internal SuperDrive? It's not very fast, and it limits how much information the DVD can transfer in any given period of time. If your internal HDD is 5400 rpm, that's another bottleneck as that limits how fast the information can be written to your HDD. EDIT: Somehow I missed that you have an SSD, that's definitely not a bottleneck.

So your computer is working full speed on the information it's given, but that's not enough to shoot it up to 100% on both cores. I have a 52x DVD drive on USB 2 and it's WAY faster than my internal drive. HandBrake encodes are much faster from it than from my SuperDrive.

Fair enough, maybe I'm wrong, but it has only ever used one core on my machine.
 
Fair enough, maybe I'm wrong, but it has only ever used one core on my machine.

I've attached an image for proof. It's using 100% of both cores because the image is on my internal 7200 rpm HDD and not an optical drive.

OP, you might just be limited by the programming of HandBrake and codecs in use. It may be calculating as fast as the software can go. Hard to say, unless someone with a similar setup can share their experiences...
 

Attachments

  • HandBrake CPU Usage.png
    HandBrake CPU Usage.png
    233.3 KB · Views: 1,633
http://i.imgur.com/3MQ29.png
http://i.imgur.com/8bceZ.png
http://i.imgur.com/zJaIg.png
http://i.imgur.com/jd0uu.png

So here are the images.

Data(Movie) is read by SSD and output file is in the SSD so nothing about SuperDrive (BTW: I don't have SuperDrive because of using Data Doubler)

Read from SSD
Write to SSD
Just as I expected (see my post above). Handbrake will use 4 threads (one for each core), and thus up to a total of 400% CPU. Activity monitor considers this as 50% User, 50% idle, but really, it's using the full power of your quad core CPU. There is no benefit from splitting the work to 8 threads, since then two threads would have to share one core.
 
I've attached an image for proof. It's using 100% of both cores because the image is on my internal 7200 rpm HDD and not an optical drive.

OP, you might just be limited by the programming of HandBrake and codecs in use. It may be calculating as fast as the software can go. Hard to say, unless someone with a similar setup can share their experiences...



Which app are you using on the menu bar to show usage stats, disk space, etc?
 
Interesting... I just ran into this same issue on Windows 7.

Now Window reports CPU utilization differently than OS X. OS X gives you 100% per CPU, while Windows adds up all the CPUs (and virtual CPUs) so that the total sums to 100%....I think (I think it counts virtual CPUs too...?)

So anyway...yeah, Windows isn't reporting close to 100% CPU utilization like it used to on my Core 2 x2. It's showing an average of...well now it's shot up to an leverage of 76% utilization, but it was more like 50% earlier.

It DOES show that all 8 cores (actually 4 real, 4 virtual) are getting pegged pretty much equally though...so...does this mean that Handbrake actually CAN'T scale to multiple CPUs as perfectly as we thought/as it seems like it should be able to?

Anyone have some thoughts on this? It's interesting it's cross platform, and it's interesting the CPU utilization seems to shoot up and down, and that it seems like on a straight dual core CPU it has no trouble hitting 100%.

(Geez, now it's up to 98% utilization, which is what you'd expect.)

What's going on?

I mean I SERIOUSLY doubt it's the hard drive. I have an entire drive that's doing almost nothing but handling this program, and it can read and write WAY faster than my CPU can actually encode, so that can't be it.

Just something about the way the program encodes?

LOL...now Resource Monitor is showing 124% Maximum CPU frequency (because of Sandy Bridge's self-overclocking) + 99% CPU utilization...now THAT'S more what I'd expect, but...

For an app like handbrake, it doesn't make sense to use all 8 threads, since the CPU power is the same if only using 4 threads

Actually it's not. That's the whole point of SMT. Now I'm not sure how much it benefits an already efficient CPU like Sandy Bridge, but I know on my Pentium 4 it was a fairly decent boost, and...well actually I've seen Anandtech's numbers too...it does help. And anyway, in Windows at least you can view what's happening on all "8" CPUs, and it shows close to identical utilization on all of them. When it's only using like half of one, it's about the same on the other 7, so that doesn't seem to be what's going on, although it's what I thought at first. In fact at first I went through the settings to figure out how to tell it to use 8 threads! Although actually...I checked, and the Windows version is actually using FORTY ONE threads LOL.

and using all 8 would make the system unusable.

Nope, not at all. You can't even tell it's running on Windows, and presumably not OS X either. On modern OSes like NT and OS X, you can, and by default Handbrake does, run at a lower priority than other programs. So like using Firefox here, it gets all the CPU time it wants (usually just a couple percent max), so you can't even tell anything else is running.

Even if it was running at normal priority, it would still probably seem pretty much like your system's not running other stuff...well, with enough RAM at least!

EDIT: Okay, just to verify that this isn't the hard drive...at least probably not, it's reading about 2MB/s, not even quite that. Now sequential this hard drive can handle as much as...well, over 100MB/s.

ALTHOUGH of course this could be seeking around in the file? So maybe it IS being held back by the hard drive? Have enough separate threads asking for different areas of the file, and t hat could start cutting in to what the drive can handle, maybe?

What do you guys think? Anyone have this on an SSD?

Technically I could try this on my Macbook Air, or move the file to my SSD and do it from there to see if it changes, but...
 
What do you guys think? Anyone have this on an SSD?

Won't make any difference. HandBrake shouldn't bottleneck on the drive.

It's perfectly normal to see varied CPU usage throughout an encode. It will vastly depend on what settings your doing, and the input and output resolutions and the complexity of the source (which will likely vary as it encodes through a source)

In 0.9.5, decoding is single threaded, so you could be intermittantly bottlenecking on this, along with some of the older single threaded filters too if you have them enabled.

We enabled the new multi-threaded decoders in ffmpeg a while ago, so you can grab a nightly build and see if that helps at all.
 
A faster hard drive or more RAM will not help your encode times. The two seconds difference between the 4 different quad core minis is basically inconsequential and can be discared.

encodeclip.png
 
Sorry to revive an old thread, but I have new information! Strangely, if I encode to H.264 (using x264) in Handbrake, it uses all 8 of my cores quite effectively with nearly 800% CPU usage, limited only by other apps using the rest of the cycles. Wow, it rips through that encoding job. If I encode to MPEG-2 or MPEG-4 (using FFmpeg), it uses only around 225% CPU, obviously not splitting up the task very well. What's going on?
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.