Idle Time

As you may be aware, I’ve used iShowU in the past to record screencasts. Yesterday, after iTunes 9 came out, I went to record a screencast of one of its features, but was stymied because iShowU, even as of 1.74 (its current version), stopped working in Snow Leopard.

So, on Twitter, I solicited recommendations for a new screen-recording tool.

iShowU doesn’t work under Snow Leopard. What’s a good replacement?

(Not ScreenFlow, not QTX)

After some of the nominations came in, I wrote a list of features I require:

My requirements:

1. A rectangle, not necessarily whole screen
2. Animation codec
3. Size presets
4. Good UI

…

QuickTime X fails at the first three points: It can only record the whole screen, and only in H.264. Its UI is “good” through extreme simplicity, which it achieves through (presumably deliberate) lack of features.

ScreenFlow‘s exclusion is special. I’ve always been put off by a passage from its marketing copy:

ScreenFlow has advanced algorithms that only encode areas of change on your screen.

OK, so either they’re unnecessarily sucking up my CPU with “advanced algorithms”, or they’re using a Quartz screen-refresh callback (like they should be doing) and calling it “advanced algorithms”. Neither possibility impresses me.

Here are the other contenders, in order by nomination.

Snapz Pro X, nominated by Steve Streza, fails point four, as I harshly told him in reply. (Sorry!) As I said in my reply, it’s designed for taking static pictures; every time I’ve used it, I’ve found that that UI doesn’t work well for creating movies. I don’t remember whether it satisfies points two and three or not.

Camtasia, nominated by Chris McQueen, has been around on Windows for a long time, but recently joined the Mac market as well. It looks nice, but it’s way too pro-caliber for me. On the other hand, if I didn’t already have Final Cut Express, I’d probably take a harder look at it for its editing tools.

(Say, I wonder if my old version of Final Cut Express (3.5) works in Snow Leopard. Hrm.)

This is the point in the timeline where I published my list of requirements.

I dismissed Screen Mimic, nominated by Rob Rix, for three reasons: First, I’d already found my winner, which strangely received no nominations. Second:

Flash-based screen recording for OS X

It’s not as bad as that makes it sound (well, not as far as I can tell without downloading the demo, anyway). What they mean by “Flash-based” appears to be that it can export the recording as Flash video as well as QuickTime. It’s probably a nice enough app, but the idea that it’s designed around Flash put me off.

The third reason was that there are no screenshots. I know these are screen-recording apps and it’s good to eat your own dog food, but static pictures are good, too. I can load and look at a full-res static picture much more quickly than I can load up even a half-res video. The faster I get to like your app, the more likely you are to make a sale; conversely, throw delays in front of me, and I’m likely to give up.

The final nomination, from Uli Kusterer, was Screenflick. It looks nice enough, but fails point 3 (presets).

The winner, which I found independently, is Screenium. It’s simple, it satisfies all of my requirements, it works in Snow Leopard, the trial limitation is pretty good (full quality, but no more than 30 seconds per recording), and the price is only $29. It even has a button to set the target rectangle to that of a specific window, which was perfect for the video I had in mind at the time. Plus, it has QuickTime export built-in, so I no longer have to use QTAmateur for that.

Here’s the video, which I recorded using Screenium’s trial mode. (If you don’t want Vimeo’s scaled-down version, hit the download link in the lower-right for the full-res QuickTime movie I uploaded. That’ll be up for about a week.)

Thanks again to everyone who replied for all of their nominations.

Make RAM Disk is a simple app to create and mount a RAM disk on Mac OS X 10.4 or later. It encapsulates my previously-stated series of terminal commands into a tiny little app—just launch it and go.

I use my RAM disk for three things:

• Download holding area. I have Mail, Safari, OmniWeb, and Adium all set to download files to the RAM disk. If I decide I don’t want to keep the download, I just leave it there until shutdown (only works on my desktop Mac).
• iShowU storage. I create a 1-GiB RAM Disk named “iShowU temp” which iShowU is set to use as its scratch disk. Using a RAM disk for this helps your recording frame rate.
• Xcode build folder. On my laptop, I symlink the project’s build folder over to the RAM disk (e.g., mkdir /Volumes/RAM\ Disk/Adium-build && ln -s /Volumes/RAM\ Disk/Adium-build build). This cuts out a lot of the disk grinding that happens during a build, which I believe helps my battery life.

Enjoy!

1. Don’t push your CPU too hard.

   This means not using codecs like H.264 and MPEG-4. Do your compression after you record the screencast. While you’re recording, you want frame-rate—don’t worry about size on disk.

2. Don’t push your disk too hard.

   There are two ways to make this mistake:

   1. Try to record too many pixels.

      On my Mac Pro with the stock SATA drive, I can’t record full-screen at more than 20 fps. Can’t do it. The bandwidth just isn’t there.

      Two good baselines are 800×600 and 640×480. The latter is iPod size (actually, twice the resolution of an iPod, but whole factors scale better), but it’s hard to use OS X that way, so it’s generally best to only record part of the screen if you want to record 640×480. If you don’t want to do that, you’ll be using 800×600. That’s what I do in the Adium screencasts.

      The other advantage is that—until Resolution Independence comes—your UI elements will show up bigger in the final product if you record the screen at smaller dimensions.

   2. Try to record too many bytes.

      Even once you get your screen resolution right, it’s still possible to push too many bytes to disk. The easiest way to do this is to use the Raw compressor, identified by iShowU as “Apple None”. The Raw compressor does no compression, meaning that all those frames coming in practically all at once can swamp your disk’s bandwidth.

Solutions

1. Use the Animation compressor.
2. Record at 800×600 and use the Animation compressor, or use a RAM disk (or both!).

The Animation compressor is easy on your CPU, so it won’t swamp that, and a fairly significant amount of compression, so it won’t swamp your disk either. And it’s lossless, so you won’t be sacrificing quality. (Use the highest quality setting. Lesser quality settings are lossy, without a significant gain in compression. Again, do your compression afterward—you want picture quality and frame-rate at the time of recording.)

UPDATE 2007-09-29: Added link to Make RAM Disk. Alternatively, if you feel like creating your RAM disk the hard way, here’s the hard way.

So I’m looking at making some screencasts in iShowU. I noticed that, thanks to QuickTime, it supports rather a lot of codecs:

Dizzying, isn’t it?

So I asked the Goog about some of the codecs, and also more generically about screencast codecs. H.264 is a popular choice, but I found no comparison to other codecs nor any discussion of what any of the codecs is particularly good at.

I also had a small amount of previous experience with the difference between codecs. I’ve watched two of rentzsch‘s screencasts: “Introduction to Core Data” and “Embedded Cocoa Frameworks”. The former is 1024×768 using H.264; the latter is 800×600 using Sorenson 3. “Introduction to Core Data” looked flawless; “Embedded Cocoa Frameworks”, OTOH, had noticeable artifacts. I wondered at first what the difference was, and after I found out, whether there wasn’t a better codec with which to implement screencasts.

Part of the problem is that there really isn’t a codec that’s been well-optimized for screencasting. Video codecs have historically been optimized for, well, video — that is, video shot with a camera. Screen images usually don’t change much except to follow mouse movements; a compressor specifically optimized for recording the screen should make a big difference in screencast file sizes. Are you listening, Apple? (Or Ambrosia?)

Anyway. In order to find the perfect (so far) screencast codec, I recorded a brief screencast using iShowU in demo mode using the None (no-compression) codec, and used QTAmateur by Michael Ash to export it to all the other codecs.

The results? Well, you’ll just have to read the screencast codec showdown for yourself. ☺