Screencast frame-rate tips
-
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.
-
Don’t push your disk too hard.
There are two ways to make this mistake:
-
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.
-
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
- Use the Animation compressor.
- 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.
March 14th, 2007 at 08:07:42
Check out CGRegisterScreenRefreshCallback. That lets you register a CG callback function for updated screen rects. If you _know_ that the only rect that has changed is the one containing the mouse, you ought to be able to avoid both compression and disk space costs for the unchanged area.
Not that I’ve tried yet.
March 14th, 2007 at 10:11:48
Ken: That information is probably better delivered to the iShowU people. ;)
March 14th, 2007 at 11:09:36
Peter: from what you’ve written here, it sounds like iShowU is very unoptimized for screencasts (I think I’m using that term correctly — “screencast” means a movie of your screen, right?).
Snapz Pro X can *easily* handle full screen video capture of 30 fps, and it has been able to do so on most hardware for a while now, including, IIRC, G4s. (I couldn’t do it on my iMac G4 800 MHz, but their developers claimed I should have been able to, and from what they told me, I was running up against a very rare bug that they could never reproduce.) I’m taking a full-screen 30 fps screencast on my Intel Core Duo MacBook right now with no perceivable lag whatsoever, and the CPU usage for Snapz hovers around 10-15% when there’s not too many changes on the screen (i.e.: you’re just typing). If you’re moving around windows, Snapz’s CPU usage can jump to 50-60%, but that load is easily managed by today’s hardware. The only time where the CPU usage gets maxed out is when Snapz is actually encoding the video into a movie file after you’ve finished capturing the footage, and that’s not exactly surprising.
I’m not sure if your bandwidth argument holds up, because it seems to imply that you’re writing the contents directly to disk. But if you’re just caching the video in memory (and you have enough to do so), I don’t think bandwidth is an issue. I don’t see why you can’t take Ambrosia’s approach: put off the disk writing until later when you don’t need to worry about continuing to capture footage.
You might want to check out Snapz Pro X again on your Mac Pro, and compare performance to iShowU.
March 14th, 2007 at 11:41:08
Yes, it does.
It’s quite possible, as iShowU is the newcomer. Also, Snapz may be using the Quartz Services callback that Ken mentioned. I’ll give Snapz a try and report back.
Interesting.
With iShowU, I’ve used a RAM disk at times. The problem is that the Raw compressor fills my 64-MiB RAM disk in a few seconds. Over the course of an entire recording, it would probably fill the rest of my RAM too, if it could.
March 14th, 2007 at 11:53:11
Oh, by the way, I forgot to mention: Snapz Pro X isn’t even a universal binary, and yet it still can capture 30 fps full-screen captures (I forgot to mention my resolution: 1280×800). This seems to me to be a pretty impressive feat on the part of Ambrosia.
March 14th, 2007 at 12:01:16
Yeah, Snapz Pro is looking mighty at this point. They’re definitely doing something right.
And from the output of nm ‘Snapz Pro X.app/Contents/MacOS/Snapz Pro X’:
So it looks like they are using that. And iShowU isn’t—no such line.
January 21st, 2010 at 10:33:33
Thanks for the post – I was having dificulty capturing Google Earth images using IShowU, and after using your tips it’s working great!
January 21st, 2010 at 13:37:40
I actually don’t use iShowU anymore. It broke in Snow Leopard, and no update that existed at the time fixed it, so I jumped ship and went looking for something else.
The app I chose was Screenium. I like it even better than iShowU. It doesn’t let me choose a RAM disk for scratch storage, but it does use Animation for temporary recording. And, unlike iShowU, it does use a screen refresh callback.