WAVE
The Microsoft Windows audio (sound) input/output system, commonlyreferred to as Wave or WAVE, predates Video for Windows, which iswrapped around WAVE in various ways. The audio tracks in AVI filesare simply waveform audio (or WAV) data used by the wave system.Video for Windows parses the AVI files, extracts the WAV data, andpipes the WAV data to the WAVE system. Video for Windows handles thevideo track if present.Traditionally, audio input and output devices such as Sound BlasterCards have a WAVE audio input/output driver to play WAV (waveformaudio) files.The simplest waveform audio files consists of a header followed byPulse Coded Modulation (PCM) sound data, usually uncompressed 8 or 16bit sound samples. WAVE also provides a mechanism for audio codecs.See elsewhere in the AVI Overview for further information on audiocodecs and audio compression.RIFF Files
RIFF files are built from (1) RIFF Form Header 'RIFF' (4 byte file size) 'xxxx' (data) where 'xxxx' identifies the specialization (or form) of RIFF. 'AVI ' for AVI files. where the data is the rest of the file. The data is comprised of chunks and lists. Chunks and lists are defined immediately below.(2) A Chunk(4 byte identifier) (4 byte chunk size) (data) The 4 byte identifier is a human readable sequence of four characters such as 'JUNK' or 'idx1'(3) A List'LIST' (4 byte list size) (4 byte list identifier) (data) where the 4 byte identifier is a human readable sequence of four characters such as 'rec ' or 'movi'where the data is comprised of LISTS or CHUNKS.AVI File Format
AVI is a specialization or "form" of RIFF, described below:'RIFF' (4 byte file length) 'AVI ' // file header (a RIFF form)'LIST' (4 byte list length) 'hdrl' // list of headers for AVI fileThe 'hdrl' list contains:'avih' (4 byte chunk size) (data) // the AVI header (a chunk)'strl' lists of stream headers for each stream (audio, video, etc.) inthe AVI file. An AVI file can contain zero or one video stream andzero, one, or many audio streams. For an AVI file with one video andone audio stream:'LIST' (4 byte list length) 'strl' // video stream list (a list)The video 'strl' list contains:'strh' (4 byte chunk size) (data) // video stream header (a chunk)'strf' (4 byte chunk size) (data) // video stream format (a chunk)'LIST' (4 byte list length) 'strl' // audio stream list (a list)The audio 'strl' list contains:'strh' (4 byte chunk size) (data) // audio stream header (a chunk)'strf' (4 byte chunk size) (data) // audio stream format (a chunk)'JUNK' (4 byte chunk size) (data - usually all zeros) // an OPTIONAL junk chunk to align on 2K byte boundary'LIST' (4 byte list length) 'movi' // list of movie data (a list)The 'movi' list contains the actual audio and video data. This 'movi' list contains one or more ... 'LIST' (4 byte list length) 'rec ' // list of movie records (a list) '##wb' (4 byte chunk size) (data) // sound data (a chunk) '##dc' (4 byte chunk size) (data) // video data (a chunk) '##db' (4 byte chunk size) (data) // video data (a chunk)A 'rec ' list (a record) contains the audio and video data for a single frame. '##wb' (4 byte chunk size) (data) // sound data (a chunk) '##dc' (4 byte chunk size) (data) // video data (a chunk) '##db' (4 byte chunk size) (data) // video data (a chunk)The 'rec ' list may not be used for AVI files with only audio or onlyvideo data. I have seen video only uncompressed AVI files that didnot use the 'rec ' list, only '00db' chunks. The 'rec ' list is usedfor AVI files with interleaved audio and video streams. The 'rec 'list may be used for AVI file with only video. ## in '##dc' refers to the stream number. For example, video data chunksbelonging to stream 0 would use the identifier '00dc'. A chunk ofvideo data contains a single video frame.Alexander Grigoriev writes ...John,##dc chunk was intended to keep compressed data, whereas ##db chunknad(sic) to be used for uncompressed DIBs (device independent bitmap),but actually they both can contain compressed data. For example,Microsoft VidCap (more precisely, video capture window class) writesMJPEG compressed data in ##db chunks, whereas Adobe Premiere writesframes compressed with the same MJPEG codec as ##dc chunks.----End of AlexanderThe ##wb chunks contain the audio data.The audio and video chunks in an AVI file do not contain time stamps or frame counts. The data is ordered in time sequentially asit appears in the AVI file. A player application should display thevideo frames at the frame rate indicated in the headers. Theapplication should play the audio at the audio sample rate indicatedin the headers. Usually, the streams are all assumed to start attime zero since there are no explicit time stamps in the AVI file.The lack of time stamps is a weakness of the original AVI fileformat. The OpenDML AVI Extensions add new chunks with timestamps. Microsoft's ASF (Advanced or Active Streaming Format), whichMicrosoft claims will replace AVI, has time stamp "objects".In principle, a video chunk contains a single frame of video. Bydesign, the video chunk should be interleaved with an audio chunkcontaining the audio associated with that video frame. The dataconsists of pairs of video and audio chunks. These pairs may beencapsulated in a 'REC ' list. Not all AVI files obey this simplescheme. There are even AVI files with all the video followed by allof the audio; this is not the way an AVI file should be made. The 'movi' list may be followed by: 'idx1' (4 byte chunk size) (index data) // an optional index into movie (a chunk) The optional index contains a table of memory offsets to eachchunk within the 'movi' list. The 'idx1' index supports rapidseeking to frames within the video file. The 'avih' (AVI Header) chunk contains the following information: Total Frames (for example, 1500 frames in an AVI) Streams (for example, 2 for audio and video together) InitialFrames MaxBytes BufferSize Microseconds Per Frame Frames Per Second (for example, 15 fps) Size (for example 320x240 pixels) Flags The 'strh' (Stream Header) chunk contains the following information: Stream Type (for example, 'vids' for video 'auds' for audio) Stream Handler (for example, 'cvid' for Cinepak) Samples Per Second (for example 15 frames per second for video) Priority InitialFrames Start Length (for example, 1500 frames for video) Length (sec) (for example 100 seconds for video) Flags BufferSize Quality SampleSize For video, the 'strf' (Stream Format) chunk contains the following information: Size (for example 320x240 pixels) Bit Depth (for example 24 bit color) Colors Used (for example 236 for palettized color) Compression (for example 'cvid' for Cinepak) For audio, the 'strf' (Stream Format) chunk contains the followinginformation: wFormatTag (for example, WAVE_FORMAT_PCM) Number of Channels (for example 2 for stereo sound) Samples Per Second (for example 11025) Average Bytes Per Second (for example 11025 for 8 bit sound) nBlockAlign Bits Per Sample (for example 8 or 16 bits) Each 'rec ' list contains the sound data and video data for a singleframe in the sound data chunk and the video data chunk. Other chunks are allowed within the AVI file. For example, I haveseen info lists such as 'LIST' (4 byte list size) 'INFO' (chunks with information on video) These chunks that are not part of the AVI standard are simplyignored by the AVI parser. AVI can be and has been extended by addinglists and chunks not in the standard. The 'INFO' list is a registeredglobal form type (across all RIFF files) to store information thathelps identify the contents of a chunk. The sound data is typically 8 or 16 bit PCM, stereo or mono,sampled at 11, 22, or 44.1 KHz. Traditionally, the sound hastypically been uncompressed Windows PCM. With the advent ofthe WorldWide Web and the severe bandwidth limitations of theInternet, there has been increasing use of audio codecs. ThewFormatTag field in the audio 'strf' (Stream Format) chunkidentifies the audio format and codec.AVI and Windows Bitmaps (DDB, DIB, ...)
Microsoft Windows represents bitmapped images internally and in filesas Device Dependent Bitmaps (DDB), Device Independent Bitmaps (DIB), andDIB Sections. Uncompressed 'DIB ' AVI files represent video frames asDIB's. Various multimedia API's that work with AVI use Windowsbitmapped images.Prior to Windows 3.0, Windows relied on Device Dependent Bitmaps forbitmapped images. A DDB is stored in a format understood by thedevice driver for a particular video card. As the name suggests, DDB'sare not generally portable.The structure of a DDB is:typedef struct tagBITMAP { // bm LONG bmType; /* always zero */ LONG bmWidth; /* width in pixels */ LONG bmHeight; /* height in pixels */ LONG bmWidthBytes; /* bytes per line of data */ WORD bmPlanes; /* number of color planes */ WORD bmBitsPixel; /* bits per pixel */ LPVOID bmBits; /* pointer to the bitmap pixel data */} BITMAP; Usually the pixel data immediately follows the BITMAP header.(BITMAP header)(Pixel Data)The HBITMAP handles used by GDI are handles to Device Dependent Bitmaps.The GDI function BitBlt and StretchBlt are actually using DeviceDependent Bitmaps.With Windows 3.0, Microsoft introduced the Device Independent Bitmap orDIB, the reigning workhorse of bitmapped images under Windows. The DIBprovided a device independent way to represent bitmapped images, bothmonochrome and color.Windows retains DDB's despite the introduction of the DIB. Forexample, to use a DIB, you might call:hBitmap = CreateDIBitmap(...)CreateDIBitmap creats a DDB from a DIB, returning the GDI HBITMAPhandle of the DDB for further GDI calls. At a low level, Windowsand GDI are still using DDB's.The DIB files have a standard header that identifies the format, size,color palette (if applicable) of the bitmapped image. The headeris a BITMAPINFO structure.typedef struct tagBITMAPINFO { BITMAPINFOHEADER bmiHeader; RGBQUAD bmiColors[1];} BITMAPINFO;The BITMAPINFOHEADER is a structure of the form:typedef struct tagBITMAPINFOHEADER{ // bmih DWORD biSize; LONG biWidth; LONG biHeight; WORD biPlanes; WORD biBitCount DWORD biCompression; /* a DIB can be compressed using run length encoding */ DWORD biSizeImage; LONG biXPelsPerMeter; LONG biYPelsPerMeter; DWORD biClrUsed; DWORD biClrImportant; } BITMAPINFOHEADER; bmiColors[1] is the first entry in an optional color palette or colortable of RGBQUAD data structures. True color (24 bit RGB) imagesdo not need a color table. 4 and 8 bit color images use a color table.typedef struct tagRGBQUAD { // rgbq BYTE rgbBlue; BYTE rgbGreen; BYTE rgbRed; BYTE rgbReserved; /* always zero */} RGBQUAD; A DIB consists of(BITMAPINFOHEADER)(optional color table of RGBQUAD's)(data for thebitmapped image)A Windows .BMP file is a DIB stored in a disk file. .BMP files prependa BITMAPFILEHEADER to the DIB data structure.typedef struct tagBITMAPFILEHEADER { // bmfh WORD bfType; /* always 'BM' */ DWORD bfSize; /* size of bitmap file in bytes */ WORD bfReserved1; /* always 0 */ WORD bfReserved2; /* always 0 */ DWORD bfOffBits; /* offset to data for bitmap */} BITMAPFILEHEADER; Structure of Data in a .BMP File(BITMAPFILEHEADER)(BITMAPINFOHEADER)(RGBQUAD color table)(Pixel Data)The Win32 API documentation from Microsoft provides extensive information on the data structures in a DIB.In Windows 95 and Windows NT, Microsoft added the DIBSection to provide a more efficient way to use DIB's in programs. The DIBSectionwas originally introduced in Windows NT to reduce the number ofmemory copies during blitting (display) of a DIB.
