I received an email from a customer asking why Screenflick does not have real-time compression like iShowU. I wrote a pretty lengthy reply explaining (in as few technical details as possible) the reasons below. For you tech-heads who read it and think “But! But! That’s not entirely true!” — I know. There are a few details glazed over and statements without techy qualifications, but by and large everything here is true.

If you swear I’m completely dead wrong and believe “you could do xyz blah thingymajig and it’d be waaay faster!”, then by all means, send me an email and tell me off.

Here is my reply:

As for compressing during recording, this is a very complicated topic. iShowU records straight to a QuickTime movie with any video codec you choose. This can be useful, but can also seriously inhibit performance. The reason we didn’t do it in Screenflick (so far) is because by compressing to a “final” movie AFTER the recording, is that you can achieve a much higher frame rate when recording*. Real-time compression is slower because the compressor codecs used for creating a “final” movie are very very slow. (They’re designed to compress very well, not work very fast.)

I just did a couple of tests with my quad core Mac Pro which will illustrate the differences. (The test was simply to record the entire screen and rapidly drag a window around the screen in circles for 10 seconds or so.) Here are the results:

iShowU, recording my entire 1680×1050 screen using the H.264 video codec achieved a pretty consistent 11 frames per second and was 4.4 MB in size. That’s as fast as it can go on a *quad core Mac Pro*. Clearly that’s really really poor. This video is small and in a “final” format so you could go ahead and post it on the internet, but 10 fps is hardly ideal for video.

H.264 is a very slow codec, so I ran the test again with the “Apple Animation” video codec, which is quicker at compressing, but doesn’t result in as small of movie. Again, during a 10 second recording with iShowU, it was an average of 21 fps and was 48 MB in size. Faster, but still very slow, and quite big for a 10 second movie at just 21 fps!

The last test with iShowU was to use a video codec that is even faster, but is not a “final” video format. It’s called the “Apple Intermediate Codec” and is used for transferring video losslessly between different applications. iShowU’s result: 28 fps.

So if you’re using Animation or Apple Intermediate Codec you can get higher speeds, but to make the movie smaller you’d have to export it from QuickTime Player Pro (using H.264 or something else) to get the size down. That’d work, but then you’re compressing the movie again, so what’s the point of having real-time compression in the first place?

Now with Screenflick, it doesn’t try to do real-time compression. It tries to record your movie as fast as you tell it to. Using the same test again, Screenflick captured the movie at an average of 56 frames per second. That’s *twice* as fast as iShowU. The temporary recorded movie size is 222 MB, sure, but when you export the movie, it’s reduced down to 24 MB — 24 because you have to remember it’s nearly 6 times the frame rate of the iShowU movie which was only 4 MB. 6×4 = 24, so it’s about the same size per number of frames as the H.264 encoded movie from iShowU.

So the reason Screenflick doesn’t do real-time compression is because if you do, you can’t get nearly the same recording performance.

Now, Screenflick has its own drawbacks as well. The method Screenflick uses for its internal video compression is not very effective for recording very detailed video. (In other words, it’d be very effective at capturing the window in the application you’re currently using because it contains numerous areas of solid colors, but it wouldn’t be good at capturing a movie of a car chase.) Because it’s not very effective, it uses more hard drive space, and because hard drives are slow, Screenflick’s performance suffers because Screenflick can give the hard drive data much faster than the hard drive can write it.

We have, however developed another method which works better and can handle recording a full 1680×1050 video of a car chase in a movie trailer, a high quality 3d video game, etc at about 50fps. This will make its way into Screenflick as soon as its ready, but it’ll still require post-compression for the same reasons as stated above, and needs a multi-core/processor machine (which thankfully are very plentiful these days).

A very very long explanation, but I hope it answers your question