SOMEWHERE IN QUICKTIME

Choosing the Right Codec

JOHN WANG

As described in Chapter 3 of Inside Macintosh: QuickTime , the Image Compression Manager performs compression and decompression by invoking image compressor and decompressor components. These components, calledcodecs , present a standard interface to the Image Compression Manager using the Component Manager. But each codec is unique because each implements a different compression and decompression algorithm. Codecs can vary greatly in the three major characteristics that are used to judge image compression algorithms: compression ratio, compression speed, and image quality. QuickTime 2.0 ships with eight codecs that can be selected for use by your QuickTime application under various conditions. In addition, users or third-party products can install custom codecs into the system by simply placing them in the Extensions folder.

With all the choices for image compression and decompression, the only way to choose the best codec for a particular purpose is to have some understanding of all the codecs available on your system. Inside Macintosh provides general descriptions of the standard QuickTime codecs, but detailed information is important in making an intelligent codec selection. The way to find this detailed information is to communicate programmatically with the codec and request its capabilities through the codec call CDGetCodecInfo. As described inInside Macintosh: QuickTime Components, this call returns a compressor information structure.

For example, information about what pixel depths a compressor supports for storing image data is important to choosing the right codec. If your application creates and compresses a picture, the decision of whether to create the picture in 8-bit, 16-bit, or 32-bit color can be based partially on what pixel depths the compressor supports. If the compressed data can store only 16 bits of color information, it would be inefficient to create a picture with 32 bits of color.

Accompanying this column on this issue's CD is the sample application GetCodecInfoApp, which (by calling CDGetCodecInfo) allows you to easily obtain detailed information about codecs installed in your system. I'll discuss GetCodecInfoApp and point out some characteristics that should be considered in choosing a codec.

USING CODECS
There are actually two separate parts to a codec: one for the compression and one for the decompression. Not all codecs provide both; nevertheless, all compressor and decompressor combinations are referred to as codecs. One example of a decompression-only codec is the codec that comes with the QuickTake 100 digital camera from Apple. The hardware in the QuickTake 100 camera performs the compression and downloads compressed data to the Macintosh. The Macintosh only needs to perform decompression.

A compressor is a component of type compressor-ComponentType ('imco') and a decompressor is a component of type decompressorComponentType ('imdc'). Detailed information on writing a codec is provided in Chapter 4 ofInside Macintosh: QuickTime Components . But to select the appropriate codec to use, you don't need to do any programming; you can simply use GetCodecInfoApp, without any need to understand how it was written. This application creates a text file containing a report of all the codec components installed in your system. For example, the output for the Cinepak codec looks like this:

Compressor Name: Cinepak
------------------------------------
- version = 1
- revisionLevel = 1
- vendor = appl
- compressionAccuracy = 128
- compressionLevel = 128
- minimum height = 1
- minimum width = 1
- compress pipeline latency = 0
- compression capabilities:
	directly compresses 32-bit pixel maps
	supports temporal compression
	can recompress images without accumulating errors
	can rate constrain to caller defined limit
- compression format:
	can store images in 24-bit color
	can store images in 8-bit grayscale
	can store custom color table
	compressed data requires non-key frames to be
		decompressed in same order as compressed
- estimated compression speed:
640x480 32-bit RGB = 11485 milliseconds

Decompressor Name: Cinepak
------------------------------------
- version = 1
- revisionLevel = 1
- vendor = appl
- decompressionAccuracy = 128
- minimum height = 1
- minimum width = 1
- decompress pipeline latency = 0
- decompression capabilities:
	directly decompresses into 32-bit pixel maps
	supports temporal compression
	can recompress images without accumulating errors
	can rate constrain to caller defined limit
- decompression format:
	can decompress images from 24-bit color
		compressed format
	can decompress images from 8-bit grayscale
		compressed format
	can store custom color table
	compressed data requires non-key frames to be
		decompressed in same order as compressed
- estimated decompression speed:
640x480 32-bit RGB = 56 milliseconds

GetCodecInfoApp gets information about codecs by calling the codec's CDGetCodecInfo function, which all codecs must support; if you're writing a codec, it's important to report your capabilities with this function. To measure the codec's speed, the application actually passes it an image to compress or decompress, and reports the result.

The Image Compression Manager function GetCodecInfo can also be used to obtain information about codecs, but only for compressor codecs; you won't be able to get information about decompression-only codecs with GetCodecInfo. *

An example of a characteristic you can determine with GetCodecInfoApp is what pixel depths the decompressor can decompress directly into. This is important because it affects the speed of the image decompression. If the codec can't decompress directly into the destination pixel map, the Image Compression Manager will have to decompress into an offscreen buffer and move the image data into the destination after converting the pixel depth. This results in additional memory and processor bandwidth requirements. If you know exactly what pixel depths a decompressor supports, you can set up the destination for the best performance.

Most codecs support only a limited number of pixel depths for the compressed data storage format. For example, the Video Compressor will store image data only in 16-bit color. If you compress a 32- bit color image, you'll lose information, since the compressed format will store the equivalent of 16 bits of data. The pixel depth for the compressed data storage format also determines which of the different compression settings are available -- for example, the pixel depth pop-up menu for Compression Settings displayed by the standard image-compression dialog component (used, for example, by Picture Compressor, an application that's part of the QuickTime Starter Kit) will only allow you to choose Color for the Video Compressor. The Animation Compressor is one of the few compressors that will store compressed data in nearly all pixel depth formats: Black and White, 4 Grays, 4 Colors, 16 Grays, 16 Colors, and so on.

When compressing movies, you'll often want to select a codec that supports temporal compression; not all codecs do. Temporal compression is the use of frame differencing to compress consecutive image frames by skipping data that doesn't change from frame to frame. Temporal compression is useful only for sequences of images stored as QuickTime movies. Knowing which codecs support temporal compression will allow you to choose the best codec for compressing sequences.

If you're compressing pictures with scientific data, it may be extremely important that there be no image quality loss. In this case, you'll want to look for a codec that supportslossless compression. For example, the Photo Compressor (JPEG codec) is a lossy codec because even at the highest quality setting, there may still be some loss of image quality. On the other hand, the Animation Compressor is lossless at higher quality settings and will preserve every pixel value.

There are many additional features a codec may support that are important to know. For example, certain codecs will support data spooling so that only portions of the compressed data need to be read into memory at any one time. This can be a requirement when working with very large compressed images that will be displayed in systems with limited memory. Another example is support for stretching to double size during decompression. This is extremely useful, since the performance is much greater if the scaling is performed during decompression rather than as a separate step after decompression.

SOME RECOMMENDATIONS
For most video clips, the Cinepak Compressor is the recommended codec. As you can see from GetCodecInfoApp's report, this codec is very slow in compression. However, its decompression speed and compression level are excellent, making it the best choice for most video data for CD-ROM playback.

An alternative to Cinepak is the Video Compressor. Since its compression speed is fairly quick, it's better for an application that requires fast compression.

If your source material is animation graphics in a movie, there are several compressors that may do the job. The Animation Compressor and Graphics Compressor may be equally suitable. In this case, you may need to experiment to determine which is the best codec to use. Finally, if you're compressing photo images, the Photo Compressor is the best codec to use. It has only moderate compression and decompression speed, but the compression ratio and quality are excellent and the compression ratio scales accordingly with image quality. If you want better image quality at the expense of larger compressed data size, you can easily achieve this with the Photo Compressor.

PRESSING ON
If you're writing a codec, you can see from this column that it's very important to properly report the codec's capabilities; GetCodecInfoApp may be useful for you to verify that your codec is doing this properly. For the rest of you, I hope this column has provided some insight on how to choose the right codec for producing the best movies and compressed images.

JOHN WANG (AppleLink WANG.JY) used to be a proud member of the PIGs (Printing, Imaging, and Graphics group) in Apple's Developer Technical Support group. But he decided that there are other challenges in life and programming. So now John spends his entire day waiting for MPW to compile code that he's writing in his software engineering role in the Image Capture group. Just in case you fail to notice, we're sure he'd like us to point out that he makes a gratuitous plug for his group's product, the QuickTake 100 digital camera, in this column. *

Thanks to Peter Hoddie, Don Johnson, Kent Sandvik, and Nick Thompson for reviewing this column. *