Lacq’ing in Depth

As you may know from having read the Conduit Live manual (page 13 onwards), Conduit Live supports two capture modes: “raw” and “rendered”. Superficially they both do the same thing: both end up writing a QuickTime movie to disk, after all. But that’s pretty much where the similarity ends, in terms of implementation and performance.

In this post I’d like to explain in some more depth why exactly “rendered capture” is so much more performance-intensive. I’m also going to show the alternative: how to capture raw and render the final result from Conduit Live, without switching apps and with a reasonable overhead.

An essential part of Conduit Live’s capture performance is the involvement of QuickTime. As I wrote in my previous post, QuickTime is not just a media player, but a sprawling API that aims to provide a solution to all your media processing needs. Of course it’s impossible to satisfy everyone, but there are a lot of things that QuickTime does really well (partly because it’s been around for so long that its implementation has matured).

One of those things is that it handles the entire process of writing a captured video stream to disk as a .mov file. As long as Conduit Live doesn’t need to touch the video data, it can rely on QuickTime to do the disk writing in the background while Conduit Live receives a copy of the video data for its own display needs – it’s efficient multitasking. Here’s an illustration of the process:

So that’s for the “raw capture” mode. For “rendered capture”, we can’t rely on QuickTime on handling the diskbound video data behind the scenes anymore. Instead we need to have a compression connection and keep feeding the .mov file ourselves. To further complicate matters, the rendered image resides on the GPU, so before it can be compressed and written to disk, it needs to be pulled back to main memory. Here’s the illustration — comparing with the previous image, it’s easy to see why this mode introduces more performance bottlenecks:

Because the image needs to be recompressed, you must choose the QuickTime compression settings before capture can proceed. This is why Conduit Live pops up the QuickTime settings dialog when starting rendered capture, if you haven’t yet specified any compression settings. (A lot of QuickTime codecs are not suitable for this kind of realtime compression – please see manual page 14 for more information and some suggestions of codecs to use.)

So if rendered capture turns out to be too heavy, what can you do? One solution is to consider the whole pipeline: usually you’re going to want to edit the footage anyway; maybe add some graphics and so on. Wouldn’t it be nice to retain the ability to finetune the effect you made in Conduit later, instead of setting it in stone while capturing?

The Conduit plugins make this possible. When editing in Final Cut Pro, import the footage you captured in Conduit Live and then use the Conduit filter to apply the effect(s) used during capture. The Conduit filter offers the same node-based user interface as Conduit Live, so you can tweak everything at this stage before exporting the final result from FCP. (Conduit also works in Apple Motion and Adobe After Effects.)

If you don’t need to edit but would like to quickly render out the composited result, you can do it easily inside Conduit Live. Here’s how…

When you’re finished capturing, go to the Control Panel and switch the Source image input from “Live video” to “Image/movie”. Load the video file that you just captured:

Now you’ve got the freshly captured video in Conduit Live in timeline mode, so you can play it with the effect applied, go over the video frame by frame, mark In/Out points to trim it, etc. (If timeline mode doesn’t ring a bell, please read “Working with images” on page 4 in the manual!)

When you’re ready, just export the composite to a QuickTime movie. Conduit Live should render pretty fast, so hopefully this workflow can be practical even in high-pressure environments. If you disagree, I’d love to hear your insights!