Tutorial: Encoding for Screencams
Editor's Note: This article appears in the October/November issue of Streaming Media magazine. Click here for your free subscription.
In the August/September issue of Streaming Media, I described how to script, record, and edit a screencam presentation for fun or profit. In this article, I’ll detail which codec does the best job compressing screencams for internet delivery, which encoding parameters work best and why, and which encoding tools do the best job producing the compressed screencam.
By way of background, the starting point for all encodings was a file I exported from my video editor in Apple Animation format. I detailed how I produced the file and why I used the Apple Animation codec in the previous article.
Which Codec Is Best?
Many times when producing screencams, the target codec is fait accompli. That is, you have to encode into Silverlight or Flash format for website design or other similar reasons. Of course, today, with H.264-capable Flash player penetration exceeding 80%, you can consider both VP6 and H.264 when producing for Flash. In addition, some casual producers won’t be locked into a codec decision beforehand and just want to use the best technology for the job. So let’s discuss which is best.
When I’m producing screencams, I define best using four parameters. First, the technology must easily enable random access to various points in the video file to accommodate viewers who want to skip or repeat a section. All codecs meet the first test, and you can drag, stop, and restart any of the formats at will. Obviously, to a degree, this will only be possible if the player you create offers these controls. But within Windows Media Player, FLV Player, and QuickTime Player, I could move to any point within the file and start playback with no lag or distortion.
Second, I consider the convenience of the player itself. For example, I find the QuickTime Player most usable since you can open multiple windows and use the arrow keys to drive frame-by-frame progress in either direction, a function that is critical for file analysis, if not tutorial viewing. I won’t discuss the FLV player in detail since most Flash-based tutorials will use a custom Flash player, but it does support multiple open instances.
Unfortunately, though previous versions of the Windows Media Player did let you open multiple instances at once, you can’t do so with current versions, meaning that your viewers can’t open more than one tutorial at a time. Media Player also doesn’t enable frame-by-frame access via the arrow keys. Again, this is more of a problem for file analysis than for tutorial viewing, but in case anyone in Redmond,Wash., is reading, arrow key support would be awesome.
How many folks have the player is always an issue, and if you’re targeting Mac and Windows customers, Flash has a big advantage there. I personally think that Silverlight is a better option than Media Player for cross-platform, browser-based applications because at least it’s Microsoft’s own playback module. Though the Flip4Mac Windows Media plug-in has worked well for me on my Macs, no one knows its overall penetration.
Finally, when considering a codec for a screencam video, you also need to consider comparative quality at the selected data rate. To test quality, I encoded the same 1024x768 @ 15 fps test file to the same ridiculously low data rate: 200Kbps with 32Kbps audio. I’ll delve more into the specific encoding parameters that I used with each encoder later. I produced each format with a range of encoders, again discussed later, and compared the best-quality file available for each codec.
I produced the H.264 and FLV files on my own, but I borrowed heavily from Ben Waggoner’s excellent tutorial, "Encoding Screen Recordings for Silverlight in VC-1 With Expression Encoder 2," when producing the VC-1 files. You can read the tutorial at http://on10.net/blogs/benwagg/21750; I’ll describe how I diverged from his procedures in the VC-1 section of this article.
The Envelope Please
Both H.264 and VP6 were much clearer than VC-1. Interestingly, all implementations of VC-1 began well but seemed to lose their way somewhere after the halfway point, starting with small pockets of distortion, such as that shown in the figure, that often worsened into highly noticeable color artifacts. While VP6 and H.264 had occasional bad stretches, they typically lasted only a moment or two and, if they were in a portion of the screen away from the cursor motion, were often unnoticeable.
Companies and Suppliers Mentioned