|
|
|
Compressing Video and Screen Animation for CD-ROM
|
By Ben Waggoner, August 15, 2002
I recently finished creating a CD for a two-CD training package that explains how to use Discreet's Cleaner 5.1 compression software. Cleaner is a great tool, an opinion I'd hold even if I didn't once work for the developer. But, surprisingly, I had to use a lot of other applications to prepare the video and audio for the discs.
I'm a very experienced compressionist, but I must constantly create new solutions to new problems when I work with compressed video. Every project is a challenge. But as I gain experience, I learn to see paths more quickly around the problems, and I get better final results.
In this article, I'll explain how I made the video and screen animations for the tutorial CD-ROM and the promotional Web site. The tricks I used to solve my problems will help you solve problems in your own projects.
But first, a short advertisement. My Cleaner 5.1 training CD-ROMs are available for $189.95 from Safer Seas. You can learn more about them on the company's Web site at www.saferseas.com.
I was working with straightforward media: video introductions to each section, animated screen captures showing Cleaner's interface as I work with it, and a navigation interface written in Macromedia Director (www.macromedia.com).
The first half of the disc explores some of Cleaner 5.1's newer and more complex features, such as inverse telecine and Sorenson 3.1 Pro integration. The second half has two long tutorials that explain the development of two different projects from source files through finished compressed media (with source files on the disc so users can follow along). I created the tutorial videos, and Producer Mark Kasserman of Safer Seas edited all of the live video and did the Director programming.
Before the video was edited, I wrote the final script and recorded the voice-over at Portland, OR, sound studio Digital One (www.digone.com), with Michael Carter engineering. Carter and Kasserman sweetened and slowed the audio. I talk fast, so they slowed down the audio by 8 percent and inserted some audio gaps to simplify syncing my voice-over to the screen activity and improve end-user comprehension.
In the end, we had a total of about two-and-a-half hours of audio. I took the sweetened audio tracks into BIAS Peak (www.bias-inc.com) and edited them into short sections to be synced to the screen recordings.
We also shot talking-head intros for each section of the tutorial. Kasserman edited and finished these intros in Canopus DVStorm with StormEdit (www.canopuscorp.com). We wanted to keep the Director code as similar as pos-sible for both the Mac and Windows versions of the title and wanted to use the same file format for both versions. QuickTime remains the best choice for cross-platform CD-ROM playback and has been used in other Safer Seas titles, so we decided to encode our instructional video to QuickTime.
For the Mac version, I recorded screen activity with the ancient and hard-to-find Motion Works Cameraman utility. I'll use Ambrosia Software's excellent Snapz Pro (www.ambrosiasw.com) for my next Mac recording project because it's better than Cameraman and available for Mac OS 9 and OS X. Both Cameraman and Snapz can record straight from the Mac computer screen into QuickTime with the Animation codec. There aren't any good straight-to-QuickTime recording apps for Windows, so I used Tech Smith Camtasia Producer (www.techsmith.com), which records AVI files. Then I converted those files to QuickTime.
Recording the screen animations was the most time-consuming part of production. For each clip, I queued up the narration audio on one computer. Then, on another computer, I set Cleaner to the correct starting point, hit record in the screen recording app, waited a few seconds until I saw my hard drive lights blinking so I knew recording had started, and hit play on the other computer.
Then I performed a weird type of theater with the mouse as I synced screen activity in Cleaner to the voice-over narrations. The audio files varied from a few seconds to several minutes, and any mistake during a take meant I had to start another take from the start. Alas, I'm a terrible actor both on stage and on computer. Recording most clips required many takes. I spent two long weeks getting through all of them.
After those two weeks, the Mac video files were finished. But I still had to convert the Windows Camtasia files. I tried doing this via Cleaner, but it would always crash. Camtasia comes with a format conversion utility, but it consistently corrupted the first few frames of each file, requiring manual trimming in QuickTime Player Pro (www.apple.com/quicktime). That's not a difficult process, but I had to trim each file.
Next I encoded audio tracks. My original plan was to use Cleaner's batch encoding. However, a bug in Cleaner 5.1's MP3 support cut off the last fraction of a second on each file, often taking out some of my last word. As a workaround, I tried encoding files as QuickTime movies with MP3 audio, but then the last half of each audio file went missing. After I wasted a day on these bugs, I used the Mac's free iTunes application to encode the files to 48kbps (kilobits per second) 44.1kHz mono MP3 audio. MP3 easily compresses cleanly recorded speech, and the compressed files sound almost as good as the originals.
With the individual audio and video files finished, I next brought them together. Using QuickTime Player Pro, I opened each audio file, copied its contents, then opened the corresponding video file and hit Add to paste in the audio track. When I saved, I had a new self-contained file with both the video and sweetened audio.
In a few cases, I wound up with an audio file that ran a little longer than the video file. I didn't want to change the audio speed or recompress the video. So instead of doing a simple Add to place the audio over the video, I used Player Pro's Add Scaled command. Add Scaled temporally scales the video by slightly increasing the video's frame rate to match the audio duration-a wonderful example of QuickTime's power for this kind of work.
The next step was to prepare the video introduction files. StormEdit can't render progressive video, so we applied an adaptive deinterlace filter in Cleaner to improve the quality of the video's static portions. We also applied different gamma settings for the Mac and Windows versions of the CD to optimize playback on each platform.
We wanted 640x480 playback so users working with the demo files would see the same size of window as I use in the tutorial video. We compressed some test files with Sorenson Video Pro 3.1, but we found that the Director Player and Sorenson Video required more CPU power than our target playback computer would provide. We decided to use the On2 VP3 QuickTime codec (www.on2.com) because its decoder isn't as CPU intensive.
The VP3 codec is part of the QuickTime Component Download program, so many users already have it installed. But to be safe, we included an installer for the codec on the CD-ROM.
We set the VP3 codec so it wouldn't drop frames or use its much faster but slightly lower quality Fast Compress mode. The codec produced excellent quality video, although some elements, particularly moving text, had rough edges from being deinterlaced. Concerns about playback performance compelled me to use 44.1kHz mono IMA audio, which is easy for a computer to decode. Because the introductions totaled only a few minutes of video footage, the bigger file sizes didn't eat up a lot of disc real estate.
Knowing the video file's final size, we calculated 210MB of space was left for the MPEG-2 tutorial files. It's always wise to leave extra room for last-minute additions, so we compressed the tutorial files to 200MB. All of the encoding was done with Heuris MPEG Power Professional 2.5 (www.heuris.com). Cleaner 5.1 with its Charger add-in can produce MPEG-2 video with almost as good quality, but Heuris got the job done in five hours instead of 30. Given the total duration of our two source files, we wanted a 5900kbps playback rate, and assigned a 5500kbps rate for video and a 384kbps rate for audio.
To match the files as closely as possible to the source I used in the tutorial, we encoded the DV files at 720x480 pixels with 48kHz audio and the Media 100 files at 640x480 with 44.1kHz audio. In my testing, Cleaner 5.1 consistently crashed when it opened MPEG-2 files with 48kHz audio, so I re-encoded that file at 44.1kHz to work around the problem
. And that was that for the CD-ROM.
As we got close to the shipping date, we decided to put some sample video on the Safer Seas Web site. The CD-ROM files weren't going to cut it-even a short segment would take up 40MB. For the Web, we needed to encode the files in a different way.
We stuck with QuickTime as the playback format but chose a different codec. Again, the content drove our codec decision. Because most of the tutorial's video shows software running on a computer, we didn't choose a codec aimed at optimizing naturalistic images. The QuickTime Graphics codec is lossless like Animation, but offers about twice the compression. However, it only uses an 8-bit color palette, providing only 256 indexed colors. Selecting the right palette is critically important. See the "Using 8-Bit Conversion" sidebar to learn why.
We wanted to post a section of video that was interesting and reasonably easy to compress. The start of the second tutorial-with its video introduction and full walk-through of preprocessing and RealVideo settings-was perfect. Back in the 8-bit era, the tool of choice for 8-bit down-sampling was Equilibrium's DeBabelizer (www.equilibrium.com). After years without an update, DeBabelizer 5 recently shipped, so I decided to give that a try.
But DeBabelizer couldn't correctly read the Animation codec source files, apparently due to some problem with interframe-compressed sources, so I needed to convert the source files to an intraframe compresed format. For this task, Cleaner 5.1 also produced files with image corruption. So I used trusty, old QuickTime Player Pro to export the Animation files as a QuickTime movie compressed with the all-keyframe lossless PNG codec. This gave me a pixel-for-pixel duplicate of the source that De-Babelizer could read. The clip we selected had nine distinct sections, but a single QuickTime movie can have multiple sections of video, each with its own palette, so I left the video in nine files for the moment.
We wanted to make an optimized 8-bit palette for each section, then flatten each section to that palette. Unfortunately, DeBabelizer doesn't provide a single feature for this. Instead, I made a script in DeBabelizer, which was a simple process. My script chained together two of De-Babelizer's Batch Animation functions-SuperPalette and Save-so DeBabelizer first generated the palette and then applied it to the movie.
SuperPalette opens each frame in a movie and generates a new palette with the best set of 256 colors to reproduce the movie. With only 256 possible colors, the process is an approximation. For video showing software UIs that use only a few colors, it's easy to get a good 256-color palette. However, for video showing natural imagery, SuperPalette must throw away many colors. The video clip we picked had relatively monochromatic video, so our final 256-color palette looked okay.
One useful trick with 8-bit color is to include the OS system colors in the palette. On the Mac, for example, this lets the colors of the Apple menu under OS 9 come through correctly. The trick can slightly reduce the number of colors that DeBabelizer can assign to the SuperPalette, but the application may have chosen at least some of the system colors for the palette and the trade-off is generally worth it to give users a visual experience they're used to.
Now that we had the palette, we needed to resave the movie with that palette. So I first made a DeBabelizer script that applied the palette through the Set Palette and Remap Pixels commands. I turned off dithering entirely so each of the video's pixels would be converted to its best match out of the 256 available colors. This ensured that flat fields with the same color on the source remained flat in the output, even if the color wasn't an exact match. If dithering had been turned on, different source pixels of the same color might get dithered to different colors on the converted file.
Then I set up a Save script to read every frame in the source, apply my remapping script, and save out the file as a QuickTime movie encoded with the Graphics codec. Finally, I made another script that made the SuperPalette and Save steps into a single process. De-Babelizer doesn't easily support variables so I manually changed the name of the source file in the script for each file that got processed. There were only nine source files each for Mac and Windows, so that wasn't a big problem.
The bulk of my work was done, but I still needed to convert the video opener, audio, and narration for the Web. For the video opener, I had Cleaner 5.1 make a 320x240 Sorenson Video 3.1 file set to play back at 640x480 pixels. Using pixel doubling keeps data rate and playback requirements down but still yields a file that plays back at full resolution. Because the opening video segment included music, I encoded the audio as 48kbps 44.1kHz mono VBR MP3. The bug I mentioned earlier kept Cleaner 5.1 from encoding the narration MP3 files. File size was critical, so I used LAME (Lame Ain't an MP3 Encoder; www.mp3dev.org), an open-source, command-line MP3 encoder that I compiled from source code under Mac OS X. One great thing about LAME is that you can encode VBR audio with a specific target data rate. I used this command to encode the narration for the screen animations:
lame -q0 --abr 20 --resample 11.025
The command breaks down like this: Use the slowest, highest-quality encoding mode (-q0), with a variable bitrate that averages 20kbps (--abr 20), and a sample rate of 11.025kHz (--resample 11.025). LAME produced files with a slightly higher data rate than requested, around 23kbps on average, but with adequate sonic quality.
Following the same technique as I used for the CD-ROM files, I employed QuickTime Player Pro to add the MP3 audio files to the video files. I now had 10 files for each platform: an opening video section and nine tutorial sections. Again using QuickTime Player Pro, I pasted all of the movies together and saved the resulting file as a self-contained movie. This gave me a single 640x480-pixel file with one section of pixel-doubled 320x240 introductory video and 48kbps audio, and nine sections lower-frame-rate, screen-recording video running at 640x480-pixels with 20kbps audio. QuickTime has no trouble playing back this kind of mixed media.
I ended up with two files around 7MB each. Not bad, but I could go lower yet. QuickTime files have an elements index that, in a movie as complex as these, can amount to a significant amount of data. QuickTime lets you compress this Movie Header, reducing the overall file size. More important, the space gets saved off the front of the file, so it significantly reduces the start-up time for playback of progressive downloads on the Web. In addition, you can save the file with Disable Saving on, so folks can't modify the final file.
Cleaner 5.1 can flatten an existing file without recompression while creating a compressed movie header and applying Disable Saving. However, a Cleaner 5.1 bug reset the resolution of my pixel-doubled opening video to playback at 320x240 rather than 640x480, ruining the pixel-doubling effect.
Totally Hip's invaluable LiveStage Pro (www.totallyhip.com) came to the rescue. Although my task was trivial for this interactive QuickTime authoring program, LiveStage perfectly imported my QuickTime movie and exported it with a compressed Movie Header and with saving disabled.
And that's that. The Web videos have provided a great taste of the project in a modem-downloadable file. The CD-ROM is selling well. However, the paradoxical nature of the project hasn't escaped me. Although Cleaner remains a powerful tool, I encountered a variety of bugs in Cleaner 5.1 that kept me from using it to develop its own tutorial material. I hope that Discreet will be able to squash those pests in future releases.
Reducing the number of colors from the millions of possibilities in a 24-bit RGB source to a palette of only 256 specific colors can greatly reduce a compressed video's file size. But to achieve optimum results, you must precisely choose the 256-color palette. Your software should be able to generate a palette with the optimum colors for the specific content you're using. A default 256-color palette won't do the job.
Most software defaults to dithering the video when converting from 24-bit color to 8-bit, causing areas that originally had a single color to be dithered into a pattern of different colors. This may look good with photographic sources, but it looks terrible with screen shots and results in larger compressed files. For the best results, you must flatten the image to 256 specific colors, not dither it.
|
|
|
|
|
|