The client application uses the ICM_COMPRESS_GET_FORMAT or ICM_COMPRESS_QUERY message to specify the input format and determine the compression (output) format. The client application sends ICM_COMPRESS_GET_FORMAT to have your driver suggest the compressed format. The client application sends ICM_COMPRESS_QUERY to determine if your driver supports a format it is suggesting.
Both messages have a pointer to a BITMAPINFO data structure in dwParam1. This structure specifies the format of the incoming uncompressed data. The contents of dwParam2 depend on the message.
To have your driver suggest the format, the client application determines the size of the buffer needed for the compressed data format by sending ICM_COMPRESS_GET_FORMAT. When requesting the buffer size, the client application uses dwParam1 to point to a BITMAPINFO structure and sets dwParam2 to NULL. Based on the input format, your driver should return the number of bytes needed for the format buffer. Return a buffer size at least large enough to hold a BITMAPINFOHEADER data structure and a color table.
The client application gets the output format by sending ICM_COMPRESS_GET_FORMAT with valid pointers to BITMAPINFO structures in both dwParam1 and dwParam2. Your driver should return the output format in the buffer pointed to by dwParam2. If your driver can produce multiple formats, the format selected by your driver should be the one that preserves the greatest amount of information rather than one that compresses to the most compact size. This will preserve image quality if the video data is later edited and recompressed.
The output format data becomes the ‘strf’ chunk in the AVI RIFF file. The data must start out like a BITMAPINFOHEADER data structure. You can include any additional information required to decompress the file after the BITMAPINFOHEADER data structure. A color table (if used) follows this information.
If you have format data following the BITMAPINFOHEADER structure, update the biSize member to specify the number of bytes used by the structure and your additional data. If a color table is part of the BITMAPINFO information, it follows immediately after your additional information.
If your driver cannot handle the input format, it returns ICMERR_BADFORMAT to fail the message.
If your driver receives ICM_COMPRESS_QUERY, the dwParam1 parameter points to a BITMAPINFO data structure containing the input format data. The dwParam2 parameter will either be NULL or contain a pointer to a BITMAPINFO structure describing the compressed format specified by the client application. If dwParam2 is NULL, your compression driver can use any output format. (The client application is just querying whether your driver can handle the input.) If dwParam2 points to a BITMAPINFO structure, the client application is suggesting the output format.
If your driver supports the specified input and output format, or it supports the specified input with NULL specified for dwParam2, return ICERR_OK to indicate the driver accepts the formats. Your driver does not have to accept the suggested format. 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 typically used, the client application requests a format with ICM_COMPRESS_GET_FORMAT.