The two different video FourCCs in an AVI

[LigH]

Okay, AVI is not really a "new" or "alternative" A/V container... ;)

This question may still be placed well here -- I'd like to know in detail the meaning of two distinct but related fields in the AVI header.

Looking into an AVI file with e.g. a hex editor or a robust text viewer, you can see two different FourCCs -- one directly following the chunk ID "vids", and another a little bit later in the header.

The XviD codec, for example, uses lower case letters "xvid" for the first one, but upper case letters "XVID" for the second. If you set up the codec to use an alternate FourCC ("DX50" or "DIVX"), it changes only the second one. Analysis tools (like VirtualDub - File - Info, GSpot, or MediaInfo) seem to use only the second one as well.

Can anyone explain the distinct meanings of them?

I suspect something like "legacy VfW AVI header" vs. "extended OpenDML header", or "DirectShow related fields"...

[LoRd_MuldeR]

First of all in an AVI/RIFF file there are many FourCC's. The file consists of "chunks" and each chunk is identified with a FourCC.
Also there are special "LIST" chunks that contain another FourCC (the type of the list) followed by an arbitrary number of chunks (the content of the list).
Lists can also contain lists, which results in a hierarchical structure. Last but not least the outermost list has a "RIFF" FourCC instead of "LIST".

In an AVI file each stream has a StreamHeader plus a StreamFormat chunk:

RIFF ('AVI '
LIST ('hdrl'
'avih'(<Main AVI Header>)
LIST ('strl'
'strh'(<Stream header>)
'strf'(<Stream format>)
'strd'(additional header data)
.
.
.
)
.
.
.
)
LIST ('movi'
.
.
.
)
['idx1'<AVIIndex>]
)

The format of the Steam Header is as follows:

typedef struct {
FOURCC fccType;
FOURCC fccHandler;
DWORD dwFlags;
DWORD dwReserved1;
DWORD dwInitialFrames;
DWORD dwScale;
DWORD dwRate;
DWORD dwStart;
DWORD dwLength;
DWORD dwSuggestedBufferSize;
DWORD dwQuality;
DWORD dwSampleSize;
} AVIStreamHeader;

And the meaning of the two FourCC's in the stream header is described here:

The stream header specifies the type of data the stream contains, such
as audio or video, by means of a four-character code. The fccType field
is set to ``vids'' if the stream it specifies contains video data. It is
set to ``auds'' if it contains audio data.

The fccHandler field contains a four-character code describing the
installable compressor or decompressor used with the data.

So this is where you will find "vids" followed by the fccHandler describing the compression format (e.g "xvid"). This is the first appearance of your FourCC :)


The format of the Stream Format chunk depends on the type of stream:

A stream format (``strf'') chunk must follow a stream header (``strh'')
chunk. The stream format chunk describes the format of the data in the
stream. For video streams, the information in this chunk is a BITMAPINFO
structure (including palette information if appropriate). For audio
streams, the information in this chunk is a WAVEFORMATEX or
PCMWAVEFORMAT structure. (The WAVEFORMATEX structure is an extended
version of the WAVEFORMAT structure.) For more information on this
structure, see the New Multimedia Data Types and Data Techniques
Standards Update.

By looking at an AVI file in the Hex-Editor it seems to second appearance of the FourCC is in the BITMAPINFOHEADER structure in the Stream Format chunk ;)

For details have a look here:
http://msdn.microsoft.com/en-us/library/dd183376(VS.85).aspx

I assume that the FourCC would be in the "biCompression" filed of the BITMAPINFOHEADER structure. Still this info appears redundant to me :confused:


Source:
http://www.opennet.ru/docs/formats/avi.txt

[LigH]

I know that all RIFF chunk IDs are FourCCs too - therefore I referred to "video FourCCs" in the title.

Comparing the two fields, it seems to me that the video stream info FourCC describes the VfW Codec which was used to encode but is rather informative; the bitmap compression FourCC instead describes the required decoder and appears to be more important for players based on DirectShow as well as video editors using VfW (Registry: vidc.XVID=xvidvfw.dll).

I remember that e.g. HuffYUV generated with some earlier ffvfw / ffdshow VfW part version stored "hfyu" as video stream info, but "FFDS" as decoder info, which was useful because the ffvfw implementation was not completely compatible to BenRG's (e.g. could also be YV12, which is not possible with the original). Here, "FFDS" ensures using ffdshow/ffvfw as decoder, but gives the hint that out of all codecs implemented in libavcodec, HuffYUV was selected to encode the video.

And so it is also possible to limit XviD to the features defined in the DivX Network profiles, change the compression FourCC to "DX50", and have it decoded by the DivX decoder filter (or hardware decoder), but still document that the XviD codec was used, by maintaining the "xvid" encoder FourCC.

[SeeMoreDigital]

Hi LigH,

While carrying out your investigations, have you looked at the different video FourCC information for DV in .AVI streams?

[LigH]

No... I hardly have any DV sources, I have only read about different FourCCs used by different cameras or codecs (e.g. ffdshow supports quite a bunch) but don't own a "sample collection".

As standardised as DV should be, "dvsd" and "dvhd" could have been all we need... but you know:

The most important advantage of standards is that you can choose between so many.