The Elgato Turbo.264 is a Mac hardware accelerator, a "USB Stick" smaller than a cell phone. It is designed to speed up a Mac conversion of videos in assorted formats, including the MPEG-2 "muxed" format used for TiVoToGo files, to the space-stingy MPEG-4/h.264 format iTunes uses and also can sync to your iPod, iPhone, or Apple TV. The same h.264 format works with the Sony PlayStation Portable.I bought a T.264 for $89.99 at Amazon.com. I wanted it since I am doing a lot of converting of TV shows recorded on my TiVo Series3 DVR. I'd like to play them, via iTunes on my MacBook Pro, on my Apple TV.
The T.264 simply plugs directly into a USB 2.0 port on the Mac (or, if access is tight, Elgato supplies a short cable to make the connection). If your Mac is an older one with USB 1.4, not 2.0, the T.264 will work with it, but its ability to speed up conversions is crippled.
The T.264 comes with its own general purpose Turbo.264 video conversion software, but I'm not using that. I'm using Roxio's Toast 9 Titanium, for the simple reason that Toast's various software applications can transfer encrypted TiVo files to the Mac, decode them, edit them, and convert them ... using the T.264, if available. Toast 9 presently has an introductory price of $79.99.
I'm also using the T.264 with a combination of TiVo Butler to transfer and decode the recordings and MPEG Streamclip 1.9.1 to edit and convert them. More on that combination, both of whose software pieces are free, as we go along.
The T.264 hardware/software combo piggybacks on Apple's $19.99 QuickTime MPEG-2 Playback Component, which some converters don't plug into. (Elgato's conversion app, when you first open it, creates yet another add-on QuickTime module called Elgato Turbo.component, which I assume provides the MPEG-2 to h.264 conversion capability.) For the T.264 hardware to come into play, the video conversion software you are using must leverage Elgato's proprietary QuickTime component and Apple's QuickTime MPEG-2 component. Toast 9 does so. So does MPEG Streamclip.
TiVo Butler does not. So although it is capable of converting .tivo files to MPEG-4/h.264 files, it does it the slow way, not using the accelerator. Also, TiVo Butler has no way to edit the files prior to conversion.
The degree to which the T.264 speeds things up varies with a number of factors, some of which are a mystery to me. One of the factors is the CPU speed of your Mac itself. Obviously, if your Mac is super-fast at doing a software-only h.264 conversion, the amount of speedup you get with the T.264 is accordingly reduced. My MacBook Pro Intel Core Duo laptop saw a 20% speedup when I performed a test conversion, once with the T.264 and once without, in Toast.
It looks as if the speedup is much greater with MPEG Streamclip, which plugs into the Apple QuickTime MPEG-2 Playback thingy. Streamclip seems to do things a lot differently than the other software that I have tried. You open in Streamclip (say) a decoded .mpg file produced by TiVo Butler (which has been set up not to do the conversion itself). Then after optionally editing it in Streamclip to remove unwanted parts, you select File->Export to Other Formats to get Apple TV-compatible output. You see a complex dialog:
If you choose Apple TV (Elgato Turbo.264) as the format, you get the T.264 speedup. If you choose just Apple TV, you don't.
In one test I made, it took 55 minutes to export a small file without the Turbo, 14 minutes with. But there was an anomaly with the former test, in which the output video frame size could not be changed from an erroneous 960 x 540 pixels, for some reason. That meant Streamclip was wasting time scaling the video up from the original 640 x 480. Hence the timing comparison was almost certainly not valid.
Unfortunately, there are other problems with using the T.264 as well. One is a propensity to ruin portions of the video output by making the picture look like a mosaic of small, single-color square tiles. In my tests, this can happen with either Toast or MPEG Streamclip as the converter.
What seems to be happening is very possibly a mix-up concerning quantization.
All MPEG, whether MPEG-4/h.264, MPEG-2, or otherwise, deals in square "macroblocks" that are 16 pixels by 16 pixels. Every MPEG video frame is a collection of macroblocks. Each macroblock consists of four 8x8 blocks of "luma" information about black and white (and shades of gray), augmented by two 8x8 blocks of color information. (The latter are each spread over the entire four luma blocks.)
MPEG encoders perform complex math that changes each 8x8 block of pixels into a set of 64 coefficients, each of which is then "quantized" be dividing it by a number from an 8x8 matrix or table of quantizers. Each division's remainder is thrown away and the quotient is provided in the output stream. The decoder then receives the quotient and multiplies it by (supposedly) the original quantizer. The decoder is supposed to find the original quantizer matrix in the encoded MPEG stream it receives, and use it to perform the requisite inverse quantization. (There are also numbers provided in the MPEG stream which tell the decoder to add or subtract a constant amount from the quantizers in the matrix, until further notice.)
When something goes wrong, the quantization or the inverse thereof can come up with the wrong numbers. If all the numbers -- except one that is treated differently, the so-called DC coefficient, which tells what the average brightness or color is -- turn out to be zero, there is no brightness or color variation within the block. That's what I'm seeing in some portions of the video output from the Turbo.264.
Tests indicate that it happens every time I try to convert a particular input file that is prone to this problem, in exactly the same portion(s) of the video.
I have also found that editing the input stream to snip off most of the earlier and later video material and just include a problem portion can, depending on exactly how the brackets are set, avoid the problem. But if the editing brackets are set fairly wide, the problem recurs.
Undoubtedly, the trigger for the problem must be something that is messed up in the original input file ... not an unusual circumstance with TiVo recordings. That something may well be much earlier in the video stream than the point where the mosaic output begins.
For this reason concerning mosaic video output, I cannot really recommend the Elgato Turbo.264 for TiVoToGo users until Elgato tracks down the bug and fixes it. And that's a pity, since the product is otherwise a useful one.
