biHeight and Video Formats in DirectShow
A problem with inverted video images in the capture, compression, and display of video in Video for Windows (VfW) and Microsoft DirectShow requires the collective efforts of video-capture IHVs to solve. The problem is related to inconsistent use of the biHeight variable, which is part of the BITMAPINFOHEADER structure in GDI and the VIDEOINFOHEADER structure in DirectShow.
This article is for IHVs who have written a video capture driver or codec and for ISVs whose applications work with images at the image level, such as digital video editors. This article discusses the issues and presents a set of rules to follow to ensure correct image orientation.
Inconsistent use of both image orientation and of biHeight to describe orientation by components such as capture drivers and rendering filters can cause inverted images when these components are directly connected in a DirectShow filter graph.
Resolving this problem will allow the video capture industry to achieve consistency among devices for proper orientation of images and for use of biHeight to describe orientation. Direct connection of a capture device to a rendering device can also result in improved video performance, because the ability to transfer an image directly to the Microsoft DirectDraw surface avoids a buffer copy operation.
On This Page
 | Background of the Image Inversion Problem |
| Where Image Inversion Occurs |
| Where Image Inversion is Not a Problem |
| Proposed Solution for biHeight Problem |
Background of the Image Inversion Problem
Video capture began in Windows with VfW, which initially only used red-green-blue (RGB) images identified with a +biHeight and a bottom-up orientation. This follows conventions used in standard device-independent bitmaps.
Later, some VfW capture drivers produced YUV and other formats with a top-down orientation, which means the lowest video address is in the upper-left corner but still uses +biHeight. In VfW, YUV data produced by a capture driver always passes through a codec provided by the vendor, resulting in RGB. Because codecs were required components for capture drivers that produced YUV data, some capture driver writers also felt safe in using the codec to correct inverted images.
DirectDraw also defines a top-down image orientation but does not use a BITMAPINFOHEADER structure to describe its surfaces. DirectShow (the service that allows a capture driver to connect directly to a renderer) passes one of these DirectDraw surfaces to a component such as a codec to fill in. DirectShow determines whether the orientation is top-down or bottom-up, and it advertises the biHeight value that corresponds to that orientation.
When DirectShow provides DirectDraw rendering surfaces (which always use a top-down orientation), it follows convention by advertising a -biHeight so the codec or capture driver knows that the lowest video address is in the upper-left corner. If the source does not follow convention and instead supplies video in a bottom-up orientation to the renderer, then the image is inverted.
Inconsistent exposure of biHeight values in capture drivers and codecs that are components in DirectShow filter graphs can result in upside-down images when this video source connects directly to a renderer that is rendering onto a DirectDraw surface.
Where Image Inversion Occurs
Image inversion can occur where software components hosted in a DirectShow filter graph produce a video format whose properties exactly match the format properties of the DirectDraw surface to which they are connected.
For example, consider a capture driver that is typically connected to a codec that corrects the inverted video by flipping the image before the image is displayed. If this capture driver is used in a DirectShow filter graph--and if DirectShow determines that the capture driver format properties exactly match format properties that the DirectDraw renderer accepts--then DirectShow will connect the capture driver to the renderer without using the codec. Without the codec, the image will not be flipped and therefore will be displayed upside down.
In this example, DirectShow eliminated the codec and avoided a buffer copy operation. DirectShow has no way of determining that the capture driver used biHeight differently to describe its orientation, resulting in inverted video. Any video format exposed by a driver and also supported as a DirectDraw surface format can have this problem.
Where Image Inversion is Not a Problem
Image inversion is not a problem for VfW capture drivers used only within a VfW environment, because data produced by a capture driver always passes through a codec supplied by the same vendor. This codec treats the data as a private format and does whatever is necessary to support the +biHeight format required by VfW.
Image inversion is also not a problem for drivers that produce private compressed formats, because their data must always be sent through a codec for decompression and rendering. JPEG, which is always encoded with a +biHeight, is an example of a private format.
Proposed Solution for biHeight Problem
The following rules are proposed to solve this problem:
| • | RGB pixel formats can be described with a BITMAPINFOHEADER that has a -biHeight value to indicate that the vertical orientation of the image is top-down. However, using the sign of biHeight to indicate orientation is only valid for RGB (uncompressed) formats. For compression types described with a FOURCC code in the biCompression field, the FOURCC code uniquely identifies the compression and orientation. It is not valid to describe the orientation with the sign of biHeight. For backward compatibility, WDM-based capture minidrivers are strongly recommended to advertise +biHeight for RGB. |
| • | Common YUV formats such as UYVY, YV12, and YUY2 are top-down oriented. It is invalid to store an image with these compression types in bottom-up orientation. The sign of biHeight for such formats must always be set as positive by drivers producing such formats, and the sign must be ignored by any driver receiving such formats. For proprietary compression formats with an associated FOURCC, any orientation is acceptable, but must always be the same for all bitmaps of that FOURCC. |
Call to action for biHeight problem:
| • | If you are a hardware or software vendor creating video capture and display components that do not use private compressed formats, follow the proposed rules to ensure correct image orientation. |