The following two block diagrams show the architecture of a video compression and decompression driver. While the diagrams show separate compression and decompression drivers, an actual driver usually combines both functions. The following illustration shows the architecture of a decompression driver:
The following illustration shows a similar architecture for the compression driver:
The decompression driver and compression driver blocks represent your compression and decompression driver. The client-application block represents the system and application software that uses the services of your compression and decompression driver. Application software will always use the system software to access compression and decompression drivers.
The source of information used for decompression is represented by the AVI file block. Other sources of images can be used in place of this block. AVI files are RIFF files that contain audio and video data. The client-application maintains the RIFF format when it reads and writes the file. (Your driver will send and receive video data. The client-application will add and remove the RIFF tags.)
Compression drivers receive uncompressed data from the video source. Typically the video source is a disk file but it could also come from other video sources such as a video capture device. The video data can be either still bitmaps or motion video frames.
While a previous block diagram showed the decompression driver returning the uncompressed video to the client-application, your driver can have the capability to write directly to the display or display driver. These devices can replace a Windows video driver or work in conjunction with it. The following illustration shows a decompression driver with the ability to write to the video display:
These drivers handle a set of messages, the ICM_DRAW messages, in addition to the decompression messages defined for the services that return the decompressed video to the client-application.