Introduction

Back in the dim and distant days when Windows 3.1 was the greatest thing in GUIs and Video for Windows was just hitting the streets, Microsoft introduced the concept of the FOURCC (Four Character Code) as a means to identify a video datastream format unambiguously (but see here for more history - FOURCCs go back further than Microsoft). Every compression format and pixel layout to be used in Video for Windows would have a unique FOURCC value assigned to it and applications would be able to pass video frames between file and codec merely by making sure that the FOURCC of the source frames matched a FOURCC supported by the codec.

Realising that many IHVs would require FOURCCs for their own proprietary pixel formats and compression algorithms, Microsoft also decreed that new formats must be registered with them to ensure the uniqueness of any FOURCCs being used. Microsoft would take the responsibility of ensuring that no two registered FOURCCs clashed. As a result, many FOURCC definitions were registered and the number of codes in the big wide world increased well beyond the original four or five that had been defined when Video for Windows originally appeared.

This system actually worked pretty well - applications could handle many different data types without actually having to know anything at all about the format. The problem, however, was that some people did need to know the format. Despite the fact that each FOURCC had been registered by Microsoft, the actual definitions (which pixel component goes where) appear to have been filed too safely and it now appears that no-one in Microsoft is able to provide this information to, for example, writers of DCI (Display Control Interface) and DirectDraw drivers or image processing tools who would like to support existing pixel formats (If you are trying to register a FOURCC, please read my suggestions on how we can keep the registration process going). Until recently, it was not even possible to get a list of the registered FOURCCs themselves but Microsoft has now posted this information on their main web site at http://www.microsoft.com/hwdev/devdes/fourcc.htm.

In an attempt to alleviate the confusion (and minimise the effort I seem to be expending passing this information to Microsoft employees and others who frequently ask me for it), this site sets out to document as many of the raw pixel format FOURCCs as possible. Most of this information was originally gleaned during research for the Brooktree Mediastream DCI driver (which, incidentally, supported 13 pixel formats) but some definitions have been picked up from other FOURCC users also keen to see their formats published.

Please note that these pages deal mainly with raw pixel formats, those containing RGB or YUV samples, and not compressed formats such as Cinepak and Indeo. I have listed all the compressed FOURCCs that I am aware of but made no attempt to describe the data format, partly because the information is generally proprietary and subject to huge license fees but mostly because I probably wouldn’t understand it anyway.

If you are aware of any FOURCC not listed in these pages, please contact me with the information and I will add it on the next revision. You may also use the registration page to tell me about your FOURCC.

This site is not affiliated to Microsoft, nor do they endorse it, etc. etc. etc........

Data Types

It came as a huge surprise recently to discover that some of you readers are actually UNIX users (or, at least, are not familiar with the Windows SDK data types) and that there was some confusion over my use of the types WORD and DWORD. As a result, I have adopted the convention of u_int32 (DWORD to Windows people) to represent an unsigned, 32 bit integer and u_int16 (WORD in Windows SDK jargon) to represent an unsigned, 16 bit integer.

Confusion Minimisation  Notes

1. The FOURCC relates purely to the layout of RGB or YUV samples in system memory and not the way those pixels are ultimately displayed or the way they may be transmitted across, for example, a communication link. It also has nothing to do with file formats although FOURCCs are used to determine the type of video frames in an AVI file.
2. Pixel formats are often described in general terms such as YUV 4:11 or YUV 4:2:2. These terms are, however, too general to fully define the format since there are multiple ways that individual components can be ordered even after the sampling periods have been defined (for example, YUV 4:2:2 can be used to describe UYVY, YUY2 and YVYU pixel formats). FOURCCs explicitly tie down the component placement in memory, thus providing enough information to fully understand the image format.

Contents Overview

Intro | RGB Formats | YUV Formats | Compressed Formats
Chips | Samples | Register | Links | Credits | Help

Last updated 12/10/2002