Is that particularly impressive? My MacBook CD encodes SD @ 2000 kbps MPEG-4 at 2x real time as well, around 50-60 fps average.
Also, I wonder why MediaFork, iSquint (the only h.264 encoding apps I tested) use only about 130-158% CPU on my MB? they max out y G5 though... Do they have poor multi-core support or what?I mean if they used full 200% (or at least more real 190), it would help encoding speed so much!
Uhm, there are limits to how much utilization any app can have. There are 2 big reasons why MediaFork would not hit 200% on a MacBook:
- Slow DVD drive
- Slow HDD drive
Plus, right now, frames have to be rendered in order. So x264 can't easily be split across two processors except by x264 itself. However, you can throw AAC and muxing onto the second processor easily.
As a note, MediaFork/Handbrake does hit 200% on my Mac Pro, and I can max out my system by running two copies ripping two drives at about 350-375% CPU utilization.
Not all bottlenecks have to be in the CPU. The CPU could be starved by the DVD drive, or the app can't write to the HDD quickly enough to keep up with what the CPU is capable of.
This seems like it would only be useful for older/slower machines. My Mac Pro can already encode SD res 1500kbps .h264 in 2x real time.
I checked Activity Monitor while ripping DVD and drive activity shows only that under 1 MB/sec is being written, so I think its bad coding of app, not slow DVD/HD drive.
not that much faster though only 5-10FPS fasterHere is something interesting to try. Do a full disc rip with MacTheRipper, and then rip from that with Handbrake. I bet you will go faster.![]()
not that much faster though only 5-10FPS faster
I've never gotten mediafork/handbrake to utilize more than 200% of the CPU on my Mac Pro, even when the video_ts folder has been ripped to my hard drive.
Run multiple instances...The current builds only ever use 2 threads so you won't. You need a build that spawns more threads![]()
Run multiple instances...
The developer will probably get requests to support it via plugin. AppleTV support on the day it ships? Yeah they're a great developer.It doesn't look like it will work with VisualHub or similar, just Quicktime. If this is so you'd get a better performance boost just by using a different encoder.
I hope I'm wrong.
Remember one important thing: On the MacBook... read speeds for the DVD drive are fairly slow, and on inner tracks, max out at about 1-2MB/sec under OS X. Open Disk Utility, and make an image of the DVD. Watch activity monitor show that it is reading the same data at the same speed as Handbrake was.
I take Handbrake to my MacPro, and its much, much, faster reading DVD drive, and I get about 4-6MB/sec on inner tracks, and 10MB/sec on the middle tracks.
It isn't Handbrake in this case, it is your DVD drive and some sort of overhead that OS X is introducing with DVD reads. The CPU can't run full-tilt without being fed, and the DVD drive isn't feeding it that well. And it isn't like Handbrake can make x264 (the h.264 encoder library used) suddenly use all your CPU for you. That is what the x264 dev team should be doing, if it can.
Here is something interesting to try. Do a full disc rip with MacTheRipper, and then rip from that with Handbrake. I bet you will go faster.![]()
Sorry, I didnt have exact numbers when I said drive activity never gets past 1 mb/sec, I just remember it was very low. Now, after ripping a DVD I can say that drive activity show about 45 KB/sec transferes, so its even lower than I though.
But I'll try to copu DVD to hard drive first and then encode it to h.264, just to test the difference if there's any![]()