I'm not too bright ...

Yep. Exactly what the title states. Sometimes, I brain fart and make things a lot more difficult that I have to.

Lo and behold, EyeTV has an option to output directly to QuickTime .mov files in either h.264 or "MPEG-4". I'm opting for MPEG-4 at the moment since my previous experience with h.264 taxed and put additional load on iMovie. Even when I was only doing voice overs for commentary.

And that sad truth? EyeTV outputs to QuickTime a lot faster than dumping it to h.264 native and running that file through MPEG Streamclip. So I think I found my work flow till I upgrade to FCPX.

EyeTV -> QuickTime -> iMovie -> turbo.264 HD to .mp4 for upload to YouTube.

Yep. This works for me. For now.

Visual Evidence - A picture is worth a thousand words ...

So here is the visual proof that I mentioned in a previous post. All the video clips were played in VLC and the screenshots were taken within the application.

Here is the original, h.264 "native" output from EyeTV that was recording the footage a 13.5mbps.

The image quality and clarity is what I expected when I maxed out the settings for capture.

Now, here is the turbo.264 HD export. It's cropped and the image is jaggy. Kind of confused as to why it would look like this, especially considering that it's all made by the same maker.

Clearly, there is something going under the hood that is making the output from the turbo.264 all screwy.

And here is the samples from h.264 native to MPEG Streamclip outputting to QuickTime @ 10240kbps.

Now this what I was expecting, even when compressed or at least changed into a format where iMovie could edit the file or at least manage simple edits without falling over itself. And in QuickTime, the file size may have grown a bit over what turbo.264 offered but it's still less than AIC.

This learning experience is becoming a real chore.

EUREKA! (And it didn't cost a cent?!)

The earlier post was written up yesterday but I didn't publish it since I wanted to add a couple of more thoughts, possibly comparison shots to illustrate the difference between output of various methods. But I ended up playing around with exporting different file formats last night and I finally got it "right". It's a nice compromise between file size, video quality and resource utilization when editing the files. So here is the process:

EyeTV export (native h.264/fastest option - I've set it to record at 13.5mbps constant quality) -> MPEG Streamclip export (QuickTime Movie - 10240kbps/10mbps which I'm still playing with this. I think I can lower it to possibly 8192kbps/8mbps stream and have "acceptable" video quality. The rest of the settings are the following - high quality, single pass and uncompressed 48khz stereo audio) -> iMovie.

With this process, I can edit and manage the clips in iMovie. If I want to save specific portions for a montage, I can export it out again to QuickTime to retain the video quality and keep the files in more manageable, smaller clips. If I want to export a project out for upload, I can use turbo.264 which will create the smaller file I'm looking for.

Only negative to this is the process time from MPEG Streamclip since encoding to QuickTime completely bypasses the turbo.264 unit. But I can deal with this. Whatever clips I end up capturing during a session, I can just queue up to convert to QuickTime overnight. Not a huge deal. Especially considering the upgrade in video quality. I think I prefer this compared to going HDV/AIC because from what I can tell, with AIC, I'm going to lose some quality anyway and considering the file sizes it creates, I don't feel that it's worth it at the moment. Now, whenever I get around to upgrading to FCPX and I invest in Compressor, I might try to encode in ProResLT and decide if the video quality is worth the file sizes. But that's in the future ... the question is if it's in the near or distance future.

Next blog post will be screenshots showing the difference in video quality between all the different outputs I was trying/dealing with. Stay tuned!

Shut up and take my money!

So I've been chugging along with the turbo.264 to convert the .m2ts/.ts that the Arcsoft capture software generated. It wasn't a bad system but I still needed to fire up the PC and keep my eye on it while it was capturing the stream. That and the fact that I needed to copy over those files to my Mac to encode.

I'm trying to simplify things and sometimes I forgot to hit capture on the PC and the copying process was slowing things down. An alternative was needed. Something all Mac based. Which costs money. Oh well.

There are a couple of options on using a Hauppauge HD PVR on a Mac but since I purchased this turbo.264 unit, why not get an Elgato product to complement it? So I purchased EyeTV.

Surprisingly, it's really nice compared to the Arcsoft software the came with the HD PVR (which makes sense - free vs pay). But it had features that I didn't know about like time shifting. Since it's supposed to be DVR software, it actually buffers whatever is on screen. I need to double check on how far it goes back but that's just dependent on how much disk space you give the software to buffer said stream. Pretty darn nifty.

Exports were ridiculously quick via it's native h.264 format. It dumps recordings in a mp4 container but it seems to be encoded in the same fashion that Handbrake does. Which means that editing and managing the clips created by EyeTV taxed iMovie quite a bit where as anything re-encoded by turbo.264 seems to be far more resource friendly. So I tried to export via turbo.264 from EyeTV and the results ... not so good.

It seemed to overscan the input and zoom in regardless of what I did to the settings. The exported file looked horrible. More so than the .m2ts/.ts to turbo.264 process that I was using before. I've opened a ticket with Elgato to see if this is a known problem since I couldn't find anything in the Knowledge Base. The odd problem is that if I took the native h.264 dump from EyeTV and used the turbo.264 encoding app seperately, the aspect ratio and overscan issue did not occur.

It's like a never ending struggle ...