As you can see below, I posted a screencast earlier today. I’ve been wanting to get into videoblogging for a while, but video’s a new thing for me and I wasn’t happy with my previous attempts. Screencasting, though, looks like it might be right up my alley. I’m hoping to post more OS X tips, as well as a series on Mac applications and on web-related things.
The whole screencasting process was pretty straightforward; however, I did learn a thing or two along the way that might be useful to others, so I thought I’d get these thoughts down while they’re fresh.
SCREEN CAPTURE SOFTWARE
I started recording using Jing, but abandoned that program because of the limited options available for setting the video size, audio encoding, etc. For down-and-dirty screencasts, I’d definitely give Jing another try, but I just didn’t think it’d work for me for this project.
Instead, I recorded this screencast using Screenflick, which I found to be dead easy to use. Screenflick (formerly Screencast; $29) has all the features I need and a very nice user interface, and even includes Mouseposé-type functionality for showing mouse clicks and screen presses during recording. I recorded at 800×600px, which is a little larger than I might have liked, but ended up as a good balance between file size and viewable screen real estate.
I also have a copy of SnapzProX that I picked up from MacHeist, and I plan to give that a try in the future.
SUPPORTING SOFTWARE
I created my script in Scrivener, but I could have used any other text editor just as well. Scrivener was open on the left side of my screen, just outside the boundaries of my recording area. TextEdit served as my quickie slide display, but I might use Stickies next time for a bit of color and for the simplified window.
After recording, I tried to add titles with iMovie 6, but the new interface has me a flummoxed. The only thing I really wanted to add was my website and email address, so for the sake of getting something posted I figured I’d just roll with the raw video as I shot it and worry about the other bits next time.
VisualHub handled the conversion of the video from .mov to .flv, and WordTube is the plugin I’m using with WordPress to display the flash file.
I used Panic Software’s most excellent Transmit to upload the video to my blog’s uploads directory on Dreamhost.
AUDIO HARDWARE
I used an inexpensive Radio Shack omnidirectional dynamic mic, mounted on a boom mic stand and plugged into a Griffin iMic, which is in turn plugged into my MacBook Pro. I don’t get quite as much gain as I might like out of this setup, but I think the audio is certainly acceptable, and the rig is pretty simple; no mixer or external drives to deal with.
THE PROCESS
I knew I’d want to keep the video as small as possible, but attempts to record at 480×320 just weren’t working. I couldn’t display enough of the preferences panes that people could see what I was talking about. So I settled on 800×600 and 30fps. I’ll probably play with frame rates in the future to keep the file size down, too.
After several failed attempts at recording off the cuff, I had a fairly good idea of what I wanted to say, so I wrote a brief outline of all my talking points in Scrivener. I probably won’t shortcut this process next time as, in essence, my first attempts were research for the final recording. Once that research was done, the final recording was pretty easy.
After I had finished the recording, I set Screenflick’s video compression to H.264 (medium quality, millions of colors, 30fps) and audio settings to AAC (44.100kHz, Mono, 64 kbps). Clicking the Save icon put a Quicktime .mov file on my desktop.
Once I had weighed the different options for hosting, sharing, and displaying the video online (see below), I used VisualHub to convert the mov file to an swf, which I uploaded to WordPress only to find out that that’s not the best format to use with WordTube, as the whole file has to load before it will start playing. I wanted the file to play as it loads, so I re-converted the mov to an flv file, and that worked as I expected.
Note that I also had VisualHub re-size the video to 550×412 to fit the space on my blog. This, I discovered, was actually a little too large when in the single post view, so next time I’m going to shoot for a width of around 500px.
SHARING THE VIDEO
I looked at blip.tv, Vimeo, Viddler, Kyte, and Ooyala (thank you, Deepak). Each of these are essentially video hosting sites; the first four emphasize their directory and community features, while Ooyala is meant more for the serious videoblogger who’s willing to pay a small amount for hosting in return for some advanced analytics and monetization tools.
In the end, I decided that I wanted to host the files myself and keep the videos on my site exclusively. I could see making a different choice for two reasons: 1) if I start blowing through my bandwidth allocation; and 2) if I decide that facilitating conversation around my video is more important to me. For now, especially because I’m still in a learning mode with this, I want to keep things on my own site.
I also want to say that I think there’s a benefit to keeping my video in the context of my own site. Or, I should say, in NOT having my video as part of a larger pool of videos. Hmmm… this is hard to describe as it’s more a feeling I have than a complete thought. I think what I’m trying to say is that you can get a more complete understanding of the screencast through the images and colors on my blog and through the surrounding content than you can if the screencast is part of a general mishmash of competing content.
Or something. Maybe I’ll return to that thought later. Anyway…
CONCERNS
Even though my site gets a pretty low amount of traffic and Dreamhost has a pretty generous hosting plan, I’m concerned about my bandwidth. If I decide later that I still don’t want to post my screencast on one of the hosting services like blip.tv or Viddler, I’ll probably look into getting an Amazon S3 account.
I’ve also got to be careful about the information I display. I realized after the fact that I opened up Keychain Access for the world to see. I don’t think there’s anything incriminating in there, but unintentionally revealing private data is definitely something I have to be more careful about next time.
At just over 14 minutes, I think the screencast is a little long. In future I’ll try to keep them to around 5 minutes. That should make the whole process faster, which will definitely keep me motivated to produce more.
Finally, the video I end up with isn’t really iPhone friendly. I do most of my video viewing on my iPhone these days, so I want to look into ways to make sure other iPhone users can download this content easily. That might mean using a different screen ratio and posting a link to the quicktime file in addition to embedding the flash file.
WORKFLOW
Even with a lot of starting and stopping and lots of time spent on research and troubleshooting, I started recording at about 7:30 last night and posted the video just after noon today. So the whole process took between 7 and 8 hours… not bad for a first attempt, actually. My goal is to get that down to an hour or so, which I think is definitely possible if I keep the screencasts shorter and refine my technique. Next time, I’ll try the following workflow and let you know how it goes.
- Research
- Outline
- Prepare the environment (hide icons, change background, etc.)
- Record (800×600px)
- Save as H.264 video (try 15-20 fps), AAC audio (mono)
- Transcode from mov to flv using VisualHub (resize to 500×375px)
- Upload flv to wp-content/uploads folder and add the file to the WordTube plugin database
- Post
- Pour a glass of wine and watch an episode of the Thunder Show
I’d love to hear from you: is this useful information? Do you have any ideas or tips for me? Comment here, or email me.
