Specifying the Input Format and Determining the Decompression Format

Depending on how the client application will use the decompressed data, it will send either ICM_DECOMPRESS_GET_FORMAT or ICM_DECOMPRESSEX_QUERY to specify the input format and determine the decompression format. The client application sends ICM_DECOMPRESS_GET_FORMAT to have your driver suggest the decompressed format. The client application sends ICM_DECOMPRESSEX_QUERY to determine if your driver supports a format it is suggesting.

The ICM_DECOMPRESS_GET_FORMAT message sends a pointer to a BITMAPINFO data structure in dwParam1. This structure specifies the format of the incoming compressed data. The input format was obtained by the client application from the ‘strf’ chunk in the AVI file. While the output format is specified by dwParam2, your driver must use the message to determine how the parameter is defined.

If your driver receives ICM_DECOMPRESS_GET_FORMAT, both dwParam1 and dwParam2 point to BITMAPINFO data structures. The input format data is contained in the dwParam1 structure. Your driver should fill in the dwParam2 BITMAPINFO data structure with information about the format it will use to decompress the data. If your driver can handle the format, return the number of bytes used for the dwParam2 structure as the return value. If your driver cannot handle the input format, or the input format from the ‘strf’ chunk is incorrect, your driver should return ICERR_BADFORMAT to fail the message.

If you have format information in addition to that specified in the BITMAPINFOHEADER structure, you can add it immediately after this structure. If you do this, update the biSize member to specify the number of bytes used by the structure and your additional information. If a color table is part of the BITMAPINFO information, it follows immediately after your additional information. Return ICERR_OK when your driver has finished updating the data format.

If your driver receives ICM_DECOMPRESSEX_QUERY, dwParam1 points to an ICDECOMPRESSEX data structure containing the input format data. If lpbiDst is NULL, your decompression driver can use any output format. In this case, the client application is querying whether your driver can decompress the input format, and the output format doesn’t matter. If lpbiDst points to a BITMAPINFO structure, the suggested format will be the native or best format for the decompressed data. For example, if playback is on an 8-bit device, the client application will suggest an 8-bit DIB.

If your driver supports the specified input and output format (which might also include stretching the image according to the values specified for the xDst, yDst, dxDst, dyDst, xSrc, ySrc, dxSrc, and dySrc members), or if it supports the specified input with NULL specified for lpbiDst, return ICERR_OK to indicate the driver accepts the formats.

Your driver does not have to accept the formats suggested. If you fail the message by returning ICERR_BADFORMAT, the client application suggests alternate formats until your driver accepts one. If your driver exhausts the list of formats usually used, the client application requests a format with ICM_DECOMPRESS_GET_FORMAT.

If you are decompressing to 8-bit data, your driver also receives the ICM_DECOMPRESS_GET_PALETTE message. Your driver should add a color table to the BITMAPINFO data structure and specify the number of palette entries in the biClrUsed member. The space reserved for the color table is always 256 colors.