Domain of the Bored

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. ☺