A brief survival guide to producing screencasts and podcasts

As part of my job in the GlassFish team, I’ve been producing a number of screencasts (recent ones for GlassFish 3.1 Milestone 1) as well as podcasts and a number of people have asked me what tools and process I use. This should by no means be considered as professionals created content, but I consider the work as “good enough”. Warning – I use a Mac and thus some of the following may not apply.


I clearly split the screencast process into recording and post-processing (the bulk of the work in my case). In my case I bought iShowU HD ($29.95) which I find simple and effective. It produces a number of different formats with compression such as MPEG 4 or H264. It does not produce flv/flash which I think is a bad idea anyway (dead-end format, hard to convert to anything else, let the publishing platform do the heavy lifting, see last section). Another popular choice is ScreenFlow but it’s more expensive ($99), has zooming and other effects I find overkill (I stopped using animations in my slides years ago), and I wouldn’t use its post-processing features since I simply use iMovie.

A precise script for the scenario is the first thing I work on. I then record the demo with minimal use of the pause/resume feature (and would rather start over when something went wrong). Most of the time I don’t record the entire screen. A typical setting is MPEG-4, 25 frames/sec, 768×432 with a fixed mouse mode. The resulting file is about 7.5MB per minute recorded. I don’t record the system audio and do a voice-over once I’m happy with the length and pace of the edited video (which often involves cutting down a number of lengthy parts). I usually use iMovie to add small (8-10 sec) intro and outro images with a title, logo and URL.


Most of the podcasts I publish on the GlassFish channel are interviews that I spend a little bit of time preparing. I usually go by a variation of the list of questions that I have written down (and sometimes shared with the interviewee). The ideal interview setup is when each person can record its own channel. When I’m remote this is possible if everyone has a descent recording tool (audacity for instance) and microphone (I use the buit-in one on the mac book pro) but it’s often nice to be in the same room for a better conversation-like result. Podcast editing can be a challenge when people talk at the same time on the same channel. I also do a number of interviews over skype with this call recorder ($19.95). In this case I can later split the channels which is great for post processing (and I don’t need to wait for people to send me their audio file…). The downside is that the quality is only as good as the skype conversation itself and that the splitting is done into two channels: me and the “other ones” (when talking with multiple people, they need to have the same level and shouldn’t speak at the same time).

It takes me about 2x to 3x the recording time to do a full editing (leveling, intro+outro, removing hum’s, making it more dynamic when possible, …) and this is all done with Audacity (open source). I usually place each channel left and right (+/-40% iirc). I then export the audio as MP3 (and remove the rather large files produced by the tool once published). The painful part for me is the metadata: file name, podcast name, show notes, picture, etc… I do this with iTunes but that requires still too many clicks IMO.


I try to create portable formats accepted by many other tools and services for publishing and conversion if necessary. For audio, mp3 is a no-brainer and for video, it’s pretty much anything except flash (once published both screencasts and podcasts are often made available using flash players anyway).

My screencasts now usually go out to YouTube. The distribution is large, embedding a player is trivial, the publisher tools are simple, and the reporting tools descent (# viewers, geography, …). I usually also make the larger original file available for offline viewing (and sometimes reuse it for time-constrained demos).

Podcasts are a little bit trickier to publish since I have the GlassFish Podcast available on the iTunes store and a more general syndication feed. I use feedburner which has a nice podcast feature to identify the enclosure (mp3) and make it podcatcher-friendly. It also has tools to help you troubleshoot a number of issues you’ll probably face when starting out. I publish the podcasts on blogs.sun.com which is powered by Apache Roller with direct link to the mp3 and a flash player for in-place listening. The Feedburner tracking features are nice and a bit more detailed than the Sun mediacast facility where I upload the mp3 file.

Just Slides

If you’re trying to push out a presentation content, you probably should look at slideshare which has an updated player, a download option, and a slidecast feature that’s quite easy to use (record on the fly or upload mp3 and chapter manually). Of course if you’re a JUG or if you’re looking for an even better user experience, there’s also parleys.

Author: alexismp

Google Developer Relations in Paris.

6 thoughts on “A brief survival guide to producing screencasts and podcasts”

  1. I notice an awful lot of the screencasts both for Netbeans and Sun in general feature Macs running OS X. Do you have any insights into the OS preference as opposed to say Linux or Solaris? I use a Macbook for most of my development, but mostly it’s so I can run Windows, Linux and Unix simultaneously so I can test different builds side by side.

  2. You’re correct about Mac OS being used a whole lot for creating screencasts. I think it’s partly due to more tools being available on the Mac (and some like iMovie there by default). Having said this I did a number of screencasts recording a virtualbox-powered Ubuntu or OpenSolaris images (I haven’t used Windows in the longest time). Maybe I should do some screencasts in other OS’s as well so people don’t feel excluded but that’s really just a feeling as the tools that I show behave the same across all OS’s.

  3. I’m more curious whether OS X is simply preferred for screencasting or if it is preferred by the developers in day-to-day operations. One of my favorite things about Netbeans is that the experience is so consistent across my development systems, so I’ve never felt excluded or any form of OS-envy as a result of any of the screencasts.

  4. In my personal case, I certainly enjoy the "it just works" part of mac os x.
    I think some of the underlying media/graphics-related features of this OS also make screencasting tools easier to write.
    So, short answer: both.

  5. The recordings at http://blogs.oracle.com/glassfishpodcast/ are a tremendous resource. Thanks for your work putting those together! It appears all the MP3 files are hosted at http://mediacast.sun.com/ and that site has the disconcerting announcement:
    "Please be advised that Mediacast (http://mediacast.sun.com) will be decommissioned on June 30, 2010. Between now and June 30, 2010, please move your content off this site and remove or update any links to content that is posted here. Content not moved by June 30, 2010 will be lost."
    What is your plan to ensure the existing resources don’t disappear? It would be a shame to lose all of this material.
    I get the impression Oracle is quite ham-handed in its integration approach. They would do well to take more care that existing Java resources at \*.sun.com don’t get lost. It has already started: The page at http://www.sun.com/events/javaee6glassfishv3/virtualconference/ used to be the hub for the informative talks (webcasts: audio + slides) from the Dec. 2009 virtual conference on Java EE 6 and GlassFish 3. Now the GlassFish Podcast blog is the only place that has this material (and only audio and static slides, no longer the synchronized webcasts from the original location). If it disappears from here, too, some really useful information about current Java technologies will be gone completely.
    BTW, the template for the GlassFish Podcast blog web pages does not have "previous"/"next" navigation links (neither on the main page nor on individual entry pages). It makes it cumbersome to view older entries because you have to construct the URL manually (by appending "?page=1") and you have to know how to do that in the first place. Just a heads-up.

Comments are closed.

%d bloggers like this: