Machine Type: Macbook, 2gb ram
CPU Speed: 2.16ghz
Number of CPUs: 2
Ipod Presets
Min/Max or Average Frames Per Second (FPS): Average ~ 15fps
I'm not running anything on the side, and this process runs going 130% of my cpu. I just bought this computer this weekend. Shouldnt it be going faster? I hear of other people with settings similar to the ipod preset and they are blazing at ~30-40??? Anything I should change/look for?
2.16ghz Core2Duo MacBook: soooo slow!!!
Forum rules
Guide to Posting Benchmarks
Guide to Posting Benchmarks
-
Deleted User 134
I have a similar set-up and get a higher frame-rate with higher quality settings.
One thing I have noticed is that sometimes HandBrake doesn't fully utilise the CPU until I pause it, put my MacBook to sleep, wake it back up and then un-pause HandBrake -- I have no idea why but this works for me.
One thing I have noticed is that sometimes HandBrake doesn't fully utilise the CPU until I pause it, put my MacBook to sleep, wake it back up and then un-pause HandBrake -- I have no idea why but this works for me.
So i'm currently trying to use my 2Ghz intel core 2 duo with 1gb memory to import Toy Story....
It's encoding at roughly 0.6 FPS.
a quick CPU usage check shows around 6%.
why is this so slow?
and what can i do to fix it?
i'm not very familiar with all the terms involved with handbrake, i'm a relatively new user.
It's encoding at roughly 0.6 FPS.
a quick CPU usage check shows around 6%.
why is this so slow?
and what can i do to fix it?
i'm not very familiar with all the terms involved with handbrake, i'm a relatively new user.
MacBook CPU 9% Frame Rate 6?! Help
I am having the same problem. I have used HB for years now. Suddenly, I am getting cpu usage around 9-10% and frame rates at 6! The result is 6 hour conversions with h264 @ 2500 which ultimatly fail. There is absolutly nothing else running on the MacBook 2ghz! I checked the monitor--nothing. I have ran every single maintence script known to man (Onyx) and nothing. I even archived and reinstalled the OS. Nothing. No other app is having this problem. For some reason, HB will not utilize the CPU. Can someone please help?
Thank you.
Thank you.
Nope, Unless there is a wide spread issue, which there is not, its not something that will get much attention apart from someone coming along and writing a patch.is anyone working on this?
Could be something to do with the Super Drive. Apple released an update about a week ago that resolved a few reading issues on super drives. You could always try digging this out see if there is any improvement.Can someone (a developer?) substantiate this claim?
I just joined this forum, so please bear with me. I have no real time to volunteer on HandBrake, but I would if I did. I hope this helps the developers.
This is a followup to an oldish posting because I found no bug issued?
I tend to think this is a wide spread, real issue. I can roll back to an older version and fully utilize both cores of my MacBook (2.0 C2D) with about 190% CPU (most of the rest to the overhead of the OS). Under this new release, I see about 120% to 130% utilized by HandBrake and most of the rest as idle.
My 2 cents follows ...
I believe the threading model has been broken. One strong possibility is this occurred in a move to support more than one Core2Duo. I'm no expert in threading on unix, but I am on Windows CE threading and if you use the wrong OS synchronization object you can have this kind of effect. I think it would be safe to assume that in any real OS with Intel hardware (my C2D knowledge is not great), the synchronization you use will be inherently more complicated when you span separate CPU's. When moving to support more than one physical CPU with your model, you likely have to give something up and not use the simplest and most efficient synchronization object, but you should still be able to use a synchronization object simpler than those required to synchronize processes.
It is not an uncommon mistake to use overkill in a synchronization object and not spot it because profilers won't discover any waste. That is it one reason why I believe this a likely scenario.
I could be way off in my guess of what is going on here, but I do believe there is a major issue with a very simple fix enabling the latest release to utilize most of the CPU horsepower it has available.
Should I post this in the bug forum ???
DM
This is a followup to an oldish posting because I found no bug issued?
I tend to think this is a wide spread, real issue. I can roll back to an older version and fully utilize both cores of my MacBook (2.0 C2D) with about 190% CPU (most of the rest to the overhead of the OS). Under this new release, I see about 120% to 130% utilized by HandBrake and most of the rest as idle.
My 2 cents follows ...
I believe the threading model has been broken. One strong possibility is this occurred in a move to support more than one Core2Duo. I'm no expert in threading on unix, but I am on Windows CE threading and if you use the wrong OS synchronization object you can have this kind of effect. I think it would be safe to assume that in any real OS with Intel hardware (my C2D knowledge is not great), the synchronization you use will be inherently more complicated when you span separate CPU's. When moving to support more than one physical CPU with your model, you likely have to give something up and not use the simplest and most efficient synchronization object, but you should still be able to use a synchronization object simpler than those required to synchronize processes.
It is not an uncommon mistake to use overkill in a synchronization object and not spot it because profilers won't discover any waste. That is it one reason why I believe this a likely scenario.
I could be way off in my guess of what is going on here, but I do believe there is a major issue with a very simple fix enabling the latest release to utilize most of the CPU horsepower it has available.
Should I post this in the bug forum ???
DM
sr55 wrote:Nope, Unless there is a wide spread issue, which there is not, its not something that will get much attention apart from someone coming along and writing a patch.is anyone working on this?
Could be something to do with the Super Drive. Apple released an update about a week ago that resolved a few reading issues on super drives. You could always try digging this out see if there is any improvement.Can someone (a developer?) substantiate this claim?
I don't.dm wrote:I tend to think this is a wide spread, real issue.
Um...version numbers? Settings? Encoder? *Anything at all* ?I can roll back to an older version and fully utilize both cores of my MacBook (2.0 C2D) with about 190% CPU (most of the rest to the overhead of the OS). Under this new release, I see about 120% to 130% utilized by HandBrake and most of the rest as idle.
-
Cavalicious
- Moderator
- Posts: 1804
- Joined: Mon Mar 26, 2007 12:07 am
Hmmm....I can say that I'm seeing similar issues with CPU utilization with later svns. I had plan on testing this out a little this weekend since I have multiple builds ready to go.
I didn't make a fuss about it because I wasn't 100% sure the apple Intel update didn't cause this. None the less, symptoms were simple:
Before (not sure which build yet): High 90s - 100%
After (need to find where diff is): High 70s - mid 80s
- Like I said, I'll have to do more testing (when I get time).
I didn't make a fuss about it because I wasn't 100% sure the apple Intel update didn't cause this. None the less, symptoms were simple:
Before (not sure which build yet): High 90s - 100%
After (need to find where diff is): High 70s - mid 80s
- Like I said, I'll have to do more testing (when I get time).
MacBook2,1 / Mac OS X 10.4.10 (8R2218) / 1Gb / Intel Core 2 Duo / 2GHz
Handbrake Version 0.9.0 / 2000 kbps / Normal or Quicktime or small variations to those parameters (generally high quality).
Compared (as best I could) to rollback with Version 0.8.5b1 which used approx 190% cpu.
I saw the NEW update after my post and I just tested Version 0.9.1 with Normal and Quicktime. CPU utilization has gone down to about 115% from 120-130 of prior version.
So with all the fixes, throughput/performance is now actually worse than that of version 0.9.0. CPU to complete a task may actually be less though, but I'd sacrifice all the cpu I had to to get the job done quicker, as the frame rate was less with the latest and greatest.
I gave you some very good advice about the potential problem. I have seen this mistake done before and it sometimes takes a lot of time, if ever, before anyone recognizes the issue. Fortunately with dual cores it is easier to see this in action with simple OS tools. If I am on target, HandBrake is using the wrong type of synchronization for it's threads and it really would be a very simple fix. It could be something else, but I'd be surprised if it had nothing to do with the threading model. I guess totally messing up how you do I/O could do this also, but it would have to be a very gross error to cause the encoder to be starved of data.
DM
Handbrake Version 0.9.0 / 2000 kbps / Normal or Quicktime or small variations to those parameters (generally high quality).
Compared (as best I could) to rollback with Version 0.8.5b1 which used approx 190% cpu.
I saw the NEW update after my post and I just tested Version 0.9.1 with Normal and Quicktime. CPU utilization has gone down to about 115% from 120-130 of prior version.
So with all the fixes, throughput/performance is now actually worse than that of version 0.9.0. CPU to complete a task may actually be less though, but I'd sacrifice all the cpu I had to to get the job done quicker, as the frame rate was less with the latest and greatest.
I gave you some very good advice about the potential problem. I have seen this mistake done before and it sometimes takes a lot of time, if ever, before anyone recognizes the issue. Fortunately with dual cores it is easier to see this in action with simple OS tools. If I am on target, HandBrake is using the wrong type of synchronization for it's threads and it really would be a very simple fix. It could be something else, but I'd be surprised if it had nothing to do with the threading model. I guess totally messing up how you do I/O could do this also, but it would have to be a very gross error to cause the encoder to be starved of data.
DM
jbrjake wrote:I don't.dm wrote:I tend to think this is a wide spread, real issue.Um...version numbers? Settings? Encoder? *Anything at all* ?I can roll back to an older version and fully utilize both cores of my MacBook (2.0 C2D) with about 190% CPU (most of the rest to the overhead of the OS). Under this new release, I see about 120% to 130% utilized by HandBrake and most of the rest as idle.
-
Cavalicious
- Moderator
- Posts: 1804
- Joined: Mon Mar 26, 2007 12:07 am
Did you install the Apple Intel Update that was released recently? Besides that, I believed I noticed it around the time awk's addition was commited (not blaming him). I'll still have to do more testing.dynaflash wrote:Running a atv preset encode to test right now on my C2D Macbook Pro.
MenuMeters has both cores running right up to 95% to 100 %. Not sure why some of you are experiencing issues.
EFI Firmware Update 1.2 for C2D dated 9/27
dm,
Each part of the pipeline runs in it's own thread, each thread consumes all the buffers it can any time it can until either it has consumed all the input buffers or the output queue is full, at which point it sleeps for a while and then continues.
The length of the fifos we can and do tune in order to determine how much processing each thread does before voluntarily relinquishing the CPU or being pre-emptivly scheduled out. The time that we sleep is also tuneable, but the values we are using appear to be very good as-is.
This is a work in progress. Do expect changes. In the past we were optimised for single CPU systems, and now we are optimised for 4 CPU systems. In the future it will scale depending on the number of CPUs and maybe other factors.
Cheers, Ed.
Each part of the pipeline runs in it's own thread, each thread consumes all the buffers it can any time it can until either it has consumed all the input buffers or the output queue is full, at which point it sleeps for a while and then continues.
The length of the fifos we can and do tune in order to determine how much processing each thread does before voluntarily relinquishing the CPU or being pre-emptivly scheduled out. The time that we sleep is also tuneable, but the values we are using appear to be very good as-is.
This is a work in progress. Do expect changes. In the past we were optimised for single CPU systems, and now we are optimised for 4 CPU systems. In the future it will scale depending on the number of CPUs and maybe other factors.
Cheers, Ed.
Ten four good buddy, all systems updated, all cores maxed.Cavalicious wrote:Did you install the Apple Intel Update that was released recently? Besides that, I believed I noticed it around the time awk's addition was commited (not blaming him). I'll still have to do more testing.dynaflash wrote:Running a atv preset encode to test right now on my C2D Macbook Pro.
MenuMeters has both cores running right up to 95% to 100 %. Not sure why some of you are experiencing issues.
EFI Firmware Update 1.2 for C2D dated 9/27
dynaflash wrote:Ten four good buddy, all systems updated, all cores maxed.Cavalicious wrote:Did you install the Apple Intel Update that was released recently? Besides that, I believed I noticed it around the time awk's addition was commited (not blaming him). I'll still have to do more testing.dynaflash wrote:Running a atv preset encode to test right now on my C2D Macbook Pro.
MenuMeters has both cores running right up to 95% to 100 %. Not sure why some of you are experiencing issues.
EFI Firmware Update 1.2 for C2D dated 9/27
I just tried ATV and got 180% +/- so I dug into this further. Normal and Quicktime also worked with high utilization this time, so what was up? Found the problem (I think) and it's not in the encoder, but the deinterlace phase. They are options accessed in a separate window that I tend to enable by default and not change beyond that. Changing/Switching the encoder does not reset this either, which seems very reasonable.
So enabling Fast (ah .. the default deinterlace technique with the older version of HandBrake that I rolled back to) and Slow seem to be well load balanced btwn the cores with high CPU utilization. Slower & Slowest seem underutilized and are poorly load balanced btwn the cores (one core maxed and the other well underutilized). I'm guessing the last two are not multithreaded at all and I gather from the documentation that this is not HandBrake code.
If it's ever fixed, the penalty probably won't be nearly sooo bad to enable either of those options, but until then I doubt that 8 cores will speed this up substantially ...
Does this ring a bell for the others with this issue?
DM
So wait a sec here...you enable one of the deinterlacing settings I labeled "slow", "slower", and "slowest" and then you complain about how slow it is? I'm not sure how we could make it any more clear that high quality deinterlacing is a slow process than embedding that reality in the filter names.
Now do you see why I asked you for settings from the start?
Now do you see why I asked you for settings from the start?
-
Cavalicious
- Moderator
- Posts: 1804
- Joined: Mon Mar 26, 2007 12:07 am
Uh, yes, it's wrong.Cavalicious wrote:Is it wrong to assume that while more(different) advanced setting will take longer to encode, but said encode should still utilize Cores/CPUs at the same level they would without said advance settings?
Different settings == different code being run == different levels of optimization. For example, the esa motion est. method for x264 isn't threaded.
But that's not what happened here, is it? dm was claiming that the *same settings* in different versions had different CPU utilizations, and that is simply not true.
-
Cavalicious
- Moderator
- Posts: 1804
- Joined: Mon Mar 26, 2007 12:07 am
Ah, makes sense...
But, I haven't changed my settings (other than VBV numbers) but have seen the same issue. I just didn't do enough testing to mention it to the devs...trying to weed out false positives.
That said (along with your explanation above) I can now understand why my HD encodes only average 75% utilization (code optimization, right). But this doesn't explain why I see a drop with my DVD sources with later SVNs.
Again, I need to find a previous build that works, and compare.
But, I haven't changed my settings (other than VBV numbers) but have seen the same issue. I just didn't do enough testing to mention it to the devs...trying to weed out false positives.
That said (along with your explanation above) I can now understand why my HD encodes only average 75% utilization (code optimization, right). But this doesn't explain why I see a drop with my DVD sources with later SVNs.
Again, I need to find a previous build that works, and compare.
dm,
1) de-interlacing should *not* be on by default, turn it off unless the source in interlaced. Check the wiki for why.
2) de-interlacing is single threaded and *will* cause a bottleneck in the pipeline.
3) You have annoyed me a tad by not saying up front that you were enabling de-interlacing. You had me doing various tests etc to try and reproduce what you were seeing.
Next time compare apples with apples please.
Cheers, Ed.
1) de-interlacing should *not* be on by default, turn it off unless the source in interlaced. Check the wiki for why.
2) de-interlacing is single threaded and *will* cause a bottleneck in the pipeline.
3) You have annoyed me a tad by not saying up front that you were enabling de-interlacing. You had me doing various tests etc to try and reproduce what you were seeing.
Next time compare apples with apples please.
Cheers, Ed.
-
JonLeibowitz
- Posts: 2
- Joined: Fri Oct 12, 2007 8:06 pm
-
Bear Hunter
- Posts: 47
- Joined: Fri Oct 05, 2007 11:13 pm
MBP 2.2 GHz Intel Core2Duo running HB 0.9.1. All updates installed...maxes out my CPU everytime only have 1-3% idle at any given point.
Under preferences it had "set de-interlace to on at launch". I had been doing conversions using CRF at 66-70%. Frame rate avg. was about mid 20's. It takes a little over 2hrs to convert a movie. After reading this..I have turned off de-interlace at launch and we will see how it does.
Under preferences it had "set de-interlace to on at launch". I had been doing conversions using CRF at 66-70%. Frame rate avg. was about mid 20's. It takes a little over 2hrs to convert a movie. After reading this..I have turned off de-interlace at launch and we will see how it does.