Well, I picked up the Elgato turbo.264 a week ago at the local Apple store. I was hoping to use my now aging G5 iMac to help encode some of the video I’ve been pulling from my old DVDs and use them on my Apple TV. To save you some pain (and another trip to the store to return it) let me tell you where this little device will help – and surprisingly, where it’s actually a detriment.
What’s a waste of time
To start with, running the thing on just about any Intel-based Mac is a complete waste of time. The ONLY situation where it will save you time is if you’re still stuck using Quicktime to encode. Using anything else, such as Visual Hub or Handbrake, encoding times with turbo.264 are almost identical. Of course, it sort of frees up your processor (though still running at 80% of 200% in most tests), so if this is important to you, you can still get somebenefit from it. However, see the What’s Craptastic section for situations where it Just Doesn’t Work.
On both the Intel and G5 platforms, I ran into some video where it just totally bogged down the hardware, getting three frames a second. I thought it was just a data transfer limit, but similar sized videos didn’t have the same problem. This happened pretty consistently with videos already in “higher”-def H.264 (960×540, 2900 kbits/s), and oddly enough, playable on the Apple TV. It was still faster than Quicktime (but slower than Visual Hub on either platform.) So don’t expect everything to be speedy.
Again, on both platforms, using the turbo.264 to select and encode unencrypted VIDEO_TS video resulted in some strange behavior. On both platforms it ran at near real-time (22fps on average, just a little slower on the Intel platform using Handbrake, much, much faster than the G5’s 3fps.) But on every damn video, it doubled the run time shown for encoding. For instance, a 1:24:30 video showed up as being 2:49:00 long. It appears that this is a problem with multiple audio tracks. With a single track, everything showed up correctly. This didn’t seem to affect the actual encoding time, nor the resultant movie.
In addition, on the G5 platform I did discover that on certain DVDs, the turbo.264 would have BAD audio drift. At the 60 minute mark, it was off by seven seconds. When I saw this occur, there was also a point in the movie where the video went to hell, being completely scrambled. What was weird about this was that when I re-ran the encoding on the same video, it worked, no audio synch issues or video problems. Nice. Using the same files run through Handbrake it worked every time.
The only place where I could find where I would potentially use this thing was as a speed-up for encoding stuff from EyeTV. Since EyeTV uses Quicktime for encoding, it’s unnecessarily slow, even on the Intel platform. This thing brought their encoding up to par with Visual Hub. However, at least for me, $99 isn’t worth it since I can easily just drag the raw .mpg files to VisualHub manually.
Really, very little works well enough to be relied upon. On the G5 platform, most video (see above caveats) encoded pretty freaking fast, at least compared to just using the main processor alone. On average, I’d say it was consistently five times faster. However, don’t expect to get any work done while it’s encoding – the main processor was pegged at 100% usage at all times, unlike the Intel platform.
But the random encoding problems with DVD video, the slow encode times with certain video types, and the general unreliability of the platform just made me wish I didn’t spend the $99 on this. It went back to the Apple store.
Technorati Tags: os x, video