Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Is that particularly impressive? My MacBook CD encodes SD @ 2000 kbps MPEG-4 at 2x real time as well, around 50-60 fps average.

Thats just regular MP4, but he is talking about MP4 with h.264 encoding, which is much more CPU-intensive.

BTW, my MacBook Core2Duo 2 GHz encodes DVDs to 1400kbps 640wide videos for iPod at about 35 fps (using MediaFork). Originals are PALs, so they are at 25 fps, so encoding is about 40% faster than real time.

My iMac averages at about 10-12 FPS though, but it has only one CPU core...

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? :confused: I mean if they used full 200% (or at least more real 190), it would help encoding speed so much!
 
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? :confused: 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.
 
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.

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.
 
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.

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. ;)
 
not that much faster though only 5-10FPS faster

Which is about right though, and indicates you are much closer to full CPU usage.

A MacBook in theory would max out at about 40fps when using H.264.

Heck, my Mac Pro jumps from about 30-40 to 50-60 when running from a DVD ripped by Mac the Ripper, using about 300% CPU usage.
 
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.
 
I am also using a build from their source tree, so it might have updated libraries which better utilize multiple cores.
 
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.
 
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.
The developer will probably get requests to support it via plugin. AppleTV support on the day it ships? Yeah they're a great developer.
 
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 :)
 
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 :)

It should be low, though. DVD drives are slow, and because of the pipeline used in Handbrake, 190+% CPU utilization is unrealistic. Right now, I get about 160% CPU utilization, with spikes reaching 185%, or dipping down to 140%, depending on which part of the scene is being looked at... This is with my 2Ghz MacBook. My Mac Pro averages at 300% CPU utilization with a single copy of Handbrake, with faster drives.

And remember, when encoding at 2Mbps, you are getting about 256KB/sec written to disk. Take into account that the OS will cache writes until they get large (over a MB or two)... and your write speed will seem very, very slow.

That said, the DVD drive in the MacBook gets about 1/5th the read speeds that I see in my Mac Pro, from any app. That right there will slow down Handbrake a bit. Performance monitoring is NOT an easy thing to do, nor tracking down the root cause of why an app isn't speedy. Trust me, I work in the industry for a living.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.