|
|
| Home > Photo, Video, Graphics > graphics > |
AVI Graphics Format Overview |
Section 2 of 14 - Prev - Next
All sections - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 - 14
31 1D joyGetPos (0000ABAA)
32 1E joyGetPosEx (0000ABFD)
33 1F joyGetThreshold (0000AC5C)
34 20 joyReleaseCapture (0000ACA8)
35 21 joySetCapture (0000ACFC)
36 22 joySetThreshold (0000AE06)
37 23 mci32Message (00007566)
38 24 mciDriverNotify (00007006)
39 25 mciDriverYield (00008727)
40 26 mciExecute (0000D92C)
41 27 mciFreeCommandResource (000035CE)
42 28 mciGetCreatorTask (0000DCD5)
43 29 mciGetDeviceIDA (0000DCA3)
44 2A mciGetDeviceIDFromElementIDA (0000DBC6)
45 2B mciGetDeviceIDFromElementIDW (0000DBF5)
46 2C mciGetDeviceIDW (00005372)
47 2D mciGetDriverData (0000158B)
48 2E mciGetErrorStringA (0000DA46)
49 2F mciGetErrorStringW (0000352F)
50 30 mciGetYieldProc (0000E1F3)
51 31 mciLoadCommandResource (00002A75)
52 32 mciSendCommandA (000015D4)
53 33 mciSendCommandW (000014A1)
54 34 mciSendStringA (00004927)
55 35 mciSendStringW (00004A24)
56 36 mciSetDriverData (000058BD)
57 37 mciSetYieldProc (000034C9)
58 38 mid32Message (0000BDFD)
59 39 midiConnect (0001019E)
60 3A midiDisconnect (0001018C)
61 3B midiInAddBuffer (0001004A)
62 3C midiInClose (0000FF42)
63 3D midiInGetDevCapsA (0000FCCC)
64 3E midiInGetDevCapsW (0000FC71)
65 3F midiInGetErrorTextA (0000FDEB)
66 40 midiInGetErrorTextW (0000FDB2)
SetInfo (0000EBF4)
140 8A mmioStringToFOURCCA (0000ED9A)
(00008BC5)
Under Windows 3.x and Windows 95, the DLL MMSYSTEM.DLL (short for
MultiMedia System) contains the multimedia API's.
Return to Top
Video for Windows
Video for Windows is an entire system for handling video
in Microsoft Windows. It was part of MS Windows 3.1 The
original Video for Windows is a collection of 16 bit
windows utilities, dynamic link libraries, and other
components.
The AVI file and file format is a central part of Video
for Windows.
Microsoft Visual C++ 5.0 has a Video for Windows
include file Vfw.h which contains the various API's that
make up Video for Windows:
* COMPMAN - Installable Compression Manager.
* DRAWDIB - Routines for drawing to the display.
* VIDEO - Video Capture Driver Interface
*
* AVIFMT - AVI File Format structure definitions.
* MMREG - FOURCC and other things
*
* AVIFile - Interface for reading AVI Files and AVI Streams
* MCIWND - MCI/AVI window class
* AVICAP - AVI Capture Window class
*
* MSACM - Audio compression manager.
Microsoft released a Video for Windows 1.0 for
Windows 3.1 in November 1992, followed by Video for Windows 1.1. There
have been several versions of Video for Windows 1.1
identified by a trailing alphabetical character such as
1.1e The last and most recent version of Video for
Windows 1.1 for Windows 3.x is Video for Windows 1.1e
This is available by ftp from Microsoft.
Microsoft has provided a 32-bit version of Video for Windows
for Windows 95, while threatening to replace Video for Windows with
ActiveMovie. This version has 32 bit versions of the Video
for Windows codecs such as Cinepak. Other DLL's in the
Video for Windows 95 are also 32-bit How much of the Video for
Windows in Windows 95 is 32 bit code is not clear; many of the
codecs are clearly 32 bit codecs. Nor is it clear how much has been
changed or modified besides the convesion to 32-bit code.
Windows NT 3.5, 3.51 and Windows NT 4.0 include a Video for Windows for
NT. Presumably this is strictly 32-bit. It is not clear how
much code is shared between the NT Video for Windows and the
Windows 95 Video for Windows. Note that hardware device
drivers are different between Windows 95 and NT 3.5/3.51/4.0.
ActiveMovie 1.0 and DirectShow (formerly ActiveMovie 2.0) are
32-bit successors to Video for Windows for both Windows 95
and Windows NT. These support AVI files. ActiveMovie started
out life under the code name Quartz; early Beta releases of
ActiveMovie were known as Quartz.
ActiveMovie 1.0 is bundled with Windows 95b (OEM Service Release 2.x)
and Internet Explorer 3.x/4.x for Windows 95. It can also be downloaded
and installed in Windows 95 separately. Note that ActiveMovie 1.0
does NOT completely replace Video for Windows. For example, ActiveMovie
1.0 does not provide a video capture mechanism. Video capture still
uses Video for Windows capture drivers.
ActiveMovie 1.0 is a 32 bit software component that can run in NT's
user mode. It runs under Windows NT 4.0 as well as Windows 95.
DirectShow (ActiveMovie 2.0) will supposedly add a number of new
features including video capture support, kernel mode streaming, and
miscellaneous other features.
VIDEO FOR WINDOWS under WINDOWS NT 4.0
Under NT 4.0, Video for Windows is implemented as a collection of
32-bit DLL's in the Microsoft 32-bit Common Object File Format or COFF
format. These are usually located in the \WINNT\SYSTEM32 directory
where Windows NT stores most of the system DLL's, drivers, and so
forth.
MSVFW32.DLL ( Microsoft Video for Windows DLL - NT 4.0 )
AVIFIL32.DLL ( AVIFILE API for Reading and Writing AVI Files and Streams )
AVICAP32.DLL ( AVI Capture Window Class )
MCIAVI32.DLL ( Video for Windows MCI Driver )
MSACM32.DRV ( Microsoft Audio Compression Manager )
MSACM32.DLL ( more Microsoft Audio Compression Manager )
MSRLE32.DLL ( Microsoft RLE Video Codec )
IR32_32.DLL ( Intel Indeo 3.2 Video Codec )
MSVIDC32.DLL ( Microsoft Video 1 Codec )
ICCVID.DLL ( Cinepak for Windows 32 - Radius )
What is in MSVFW32.DLL?
MSVFW32.DLL includes the DRAWDIB, Installable Compression
Manager or ICM, and MCI Windows components of Video for
Windows. Other components are stored in other DLL's.
This is a dump of the functions exported by MSVFW32.DLL
Version 4.00
Microsoft (R) COFF Binary File Dumper Version 5.00.7022
Copyright (C) Microsoft Corp 1992-1997. All rights reserved.
Dump of file msvfw32.dll
File Type: DLL
Section contains the following Exports for MSVFW32.dll
0 characteristics
31EC70E9 time date stamp Tue Jul 16 21:49:45 1996
0.00 version
2 ordinal base
47 number of functions
47 number of names
ordinal hint name
3 0 DrawDibBegin (00001E14)
4 1 DrawDibChangePalette (00008C30)
5 2 DrawDibClose (0000888A)
6 3 DrawDibDraw (000010A6)
7 4 DrawDibEnd (00008BEC)
8 5 DrawDibGetBuffer (00008EFC)
9 6 DrawDibGetPalette (00002F97)
10 7 DrawDibOpen (00003E0A)
11 8 DrawDibProfileDisplay (00003EBA)
12 9 DrawDibRealize (00001D49)
13 A DrawDibSetPalette (00001C0D)
14 B DrawDibStart (00002EEB)
15 C DrawDibStop (00002F42)
16 D DrawDibTime (00008C2B)
17 E GetOpenFileNamePreview (0000C7DC)
18 F GetOpenFileNamePreviewA (0000C7DC)
19 10 GetOpenFileNamePreviewW (0000C6A5)
20 11 GetSaveFileNamePreviewA (0000C7EC)
21 12 GetSaveFileNamePreviewW (0000C7CC)
22 13 ICClose (000035E0)
23 14 ICCompress (00004CE5)
24 15 ICCompressorChoose (00005F61)
25 16 ICCompressorFree (00005615)
26 17 ICDecompress (00004D4B)
27 18 ICDraw (0000106A)
28 19 ICDrawBegin (00001B95)
29 1A ICGetDisplayFormat (00004D8E)
30 1B ICGetInfo (00004C60)
31 1C ICImageCompress (00005A96)
32 1D ICImageDecompress (00005D2A)
33 1E ICInfo (00002FEB)
34 1F ICInstall (00004574)
35 20 ICLocate (0000372E)
36 21 ICMThunk32 (0000841C)
37 22 ICOpen (0000337C)
38 23 ICOpenFunction (00003B53)
39 24 ICRemove (0000488B)
40 25 ICSendMessage (00001000)
41 26 ICSeqCompressFrame (000059A7)
42 27 ICSeqCompressFrameEnd (00005907)
43 28 ICSeqCompressFrameStart (000056E4)
44 29 MCIWndCreate (0000C988)
45 2A MCIWndCreateA (0000C988)
46 2B MCIWndCreateW (0000C8CC)
47 2C MCIWndRegisterClass (0000C83F)
48 2D StretchDIB (00009D13)
2 2E VideoForWindowsVersion (000041D1)
Summary
8000 .data
3000 .rdata
2000 .reloc
3000 .rsrc
11000 .text
VIDEO FOR WINDOWS FOR WINDOWS 95
Microsoft distributed a new Video for Windows for Windows 95
while emphasizing Quartz/ActiveMovie/DirectShow in its
marketing.
Video for Windows 95 Files
MSRLE32.DLL (32-bit Microsoft RLE Video Codec)
IR32_32.DLL (32-bit Indeo 3.2 Video Codec)
ICCVID.DLL (32-bit Radius Cinepak Video Codec)
MSVIDC32.DLL (32-bit Microsoft Video 1 Video Codec )
MSVIDEO.DLL (16-bit Video for Windows DLL)
MCIAVI.DRV (16-bit AVI Video MCI Driver)
AVIFILE.DLL (16-bit AVIFILE)
AVICAP.DLL (16-bit AVICAP)
AVICAP32.DLL (32-bit AVICAP)
MSVFW32.DLL (32-bit Video for Windows DLL - with VfW API)
AVIFIL32.DLL (32-bit AVIFILE)
SUMMARY
Video for Windows 1.0 (Windows 3.x)
Video for Windows 1.1 (a-e) (Windows 3.x)
Video for Windows (Windows 95 - has 32-bit codecs and other 32-bit DLL's)
Video for Windows (Windows NT 3.5, 3.51, and 4.0)
Quartz (Betas of ActiveMovie) (Windows 95)
ActiveMovie 1.0 (Windows 95 and NT 4.0)
ActiveMovie 2.0 (DirectShow) (probably Windows 97/98/Memphis and NT 5.0)
Return to Top
WAVE
The Microsoft Windows audio (sound) input/output system, commonly
referred to as Wave or WAVE, predates Video for Windows, which is
wrapped around WAVE in various ways. The audio tracks in AVI files
are simply waveform audio (or WAV) data used by the wave system.
Video for Windows parses the AVI files, extracts the WAV data, and
pipes the WAV data to the WAVE system. Video for Windows handles the
video track if present.
Traditionally, audio input and output devices such as Sound Blaster
Cards have a WAVE audio input/output driver to play WAV (waveform
audio) files.
The simplest waveform audio files consists of a header followed by
Pulse Coded Modulation (PCM) sound data, usually uncompressed 8 or 16
bit sound samples. WAVE also provides a mechanism for audio codecs.
See elsewhere in the AVI Overview for further information on audio
codecs and audio compression.
WAVE is present in Windows 3.1 and Windows 95. A different WAVE
system is present in Windows NT 3.5, 3.51, and 4.0 At least the
hardware device drivers for sound cards must be different in NT.
ActiveMovie appears to be replacing WAVE.
Return to Top
What is the AVI File Format?
AVI Files are a special case of RIFF files. RIFF is
the Resource Interchange File Format. This is a general
purpose format for exchanging multimedia data types
that was defined by Microsoft and IBM during their
long forgotten alliance.
Kevin McKinnon writes:
In fact, RIFF is a clone of the IFF format invented by Electronic Arts in
1984. They invented the format for Deluxe Paint on the Amiga, and IFF
quickly became the standard for interchange on that platform,
maintained eventually by Commodore right up 'til it's demise. EA also
ported Deluxe Paint to the PC platform and brought IFF with it.
IFF even used the 4-character headers (FourCC), though at the time it was
simply called a LONGWORD that some clever people decided to pair into
four charcter because they looked good in #define's. ;)
RIFF is so close to IFF that the good IFF parser routines will (mostly)
correctly parse RIFF files.
----End of Kevin----
Further information on the IFF format is available at:
http://www.ipahome.com/gff/textonly/summary/iff.htm
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 file
The '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.) in
the AVI file. An AVI file can contain zero or one video stream and
zero, one, or many audio streams. For an AVI file with one video and
one 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 only
video data. I have seen video only uncompressed AVI files that did
not use the 'rec ' list, only '00db' chunks. The 'rec ' list is used
for 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 chunks
belonging to stream 0 would use the identifier '00dc'. A chunk of
video data contains a single video frame.
Alexander Grigoriev writes ...
John,
##dc chunk was intended to keep compressed data, whereas ##db chunk
nad(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) writes
MJPEG compressed data in ##db chunks, whereas Adobe Premiere writes
frames compressed with the same MJPEG codec as ##dc chunks.
----End of Alexander
The ##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 as
it appears in the AVI file. A player application should display the
video frames at the frame rate indicated in the headers. The
application should play the audio at the audio sample rate indicated
in the headers. Usually, the streams are all assumed to start at
time zero since there are no explicit time stamps in the AVI file.
The lack of time stamps is a weakness of the original AVI file
format. The OpenDML AVI Extensions add new chunks with time
stamps. Microsoft's ASF (Advanced or Active Streaming Format), which
Microsoft claims will replace AVI, has time stamp "objects".
In principle, a video chunk contains a single frame of video. By
design, the video chunk should be interleaved with an audio chunk
containing the audio associated with that video frame. The data
consists of pairs of video and audio chunks. These pairs may be
encapsulated in a 'REC ' list. Not all AVI files obey this simple
scheme. There are even AVI files with all the video followed by all
of 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 each
chunk within the 'movi' list. The 'idx1' index supports rapid
seeking 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 following
information:
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 single
frame in the sound data chunk and the video data chunk.
Other chunks are allowed within the AVI file. For example, I have
seen 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 simply
ignored by the AVI parser. AVI can be and has been extended by adding
lists and chunks not in the standard. The 'INFO' list is a registered
global form type (across all RIFF files) to store information that
helps 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 has
typically been uncompressed Windows PCM. With the advent of
the WorldWide Web and the severe bandwidth limitations of the
Internet, there has been increasing use of audio codecs. The
wFormatTag field in the audio 'strf' (Stream Format) chunk
identifies the audio format and codec.
OpenDML AVI File Format Extensions
The Open Digital Media (OpenDML) Consortium has defined an OpenDML
AVI File Format Extensions which extend AVI to support a variety of
features required for professional video production. These include
support for fields (not just frames), file sizes larger than 1 GB,
timecodes, and many other features. Microsoft has reportedly
incorporated OpenDML AVI support in DirectShow 5.1 (ActiveMovie 5.1).
It is also used by various professional video applications for the PC,
in particular Matrox's DigiSuite software.
The Open Digital Media Consortium AVI File Format Extensions
add new lists and chunks to the AVI file which contain extra
data such as timecodes not incorporated in the original AVI
standard.
OpenDML appears to have been spearheaded by Matrox to improve AVI
for professional video authoring and editing. Matrox makes a variety
of PC video products such as DigiSuite for professional and broadcast
video authoring and editing. The OpenDML AVI File Format Extensions
are primarily for the Motion JPEG AVI files used for professional
video authoring and editing. The OpenDML effort seems to have been
pushed to one side with the advent of ActiveMovie, NetShow, Advanced
(formerly Active) Streaming Format (ASF) Files, and other Microsoft
initiatives.
On Oct. 2, 1997, the OpenDML AVI File Format Extensions Version 1.02
specification document (dated February 28, 1996) was available at
the Matrox Electronic Systems, Ltd. Web site at:
http://www.matrox.com/videoweb/odmlff2.htm
The specification is in Adobe Portable Document Format (PDF). Since
Matrox seems to rearrange their site from time to time and one can't
always find the specification, I've included a link to a copy of the PDF
version of the specification on my Web site.
PDF OpenDML AVI File Format Extensions Specification Document
Get Adobe Acrobat Reader (PDF Viewer)
Where to get the exact AVI specification?
Microsoft Visual C++ 5.0 has a Video for Windows include
file Vfw.h which gives the exact AVI data structures such as
the various headers used in AVI files. The file also has
comments explaining the structure of the AVI file.
Video for Windows refers to the AVI Format by the mnemonic
AVIFMT. At one time, the format information was apparently
stored in an AVIFMT.H header file. The format
information now appears consolidated in Vfw.h
In addition to the Video for Windows header files, Chapter Four of the
Video for Windows Programmer's Guide, "AVI Files", gives a detailed
specification of the AVI file format.
Return to Top
AVI and Windows Bitmaps (DDB, DIB, ...)
Microsoft Windows represents bitmapped images internally and in files
as Device Dependent Bitmaps (DDB), Device Independent Bitmaps (DIB), and
DIB Sections. Uncompressed 'DIB ' AVI files represent video frames as
DIB's. Various multimedia API's that work with AVI use Windows
bitmapped images.
Prior to Windows 3.0, Windows relied on Device Dependent Bitmaps for
bitmapped images. A DDB is stored in a format understood by the
device driver for a particular video card. As the name suggests, DDB's
are 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 Device
Dependent Bitmaps.
With Windows 3.0, Microsoft introduced the Device Independent Bitmap or
DIB, the reigning workhorse of bitmapped images under Windows. The DIB
provided a device independent way to represent bitmapped images, both
monochrome and color.
Windows retains DDB's despite the introduction of the DIB. For
example, to use a DIB, you might call:
hBitmap = CreateDIBitmap(...)
CreateDIBitmap creats a DDB from a DIB, returning the GDI HBITMAP
handle of the DDB for further GDI calls. At a low level, Windows
and 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 header
is 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 color
table of RGBQUAD data structures. True color (24 bit RGB) images
do 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 the
bitmapped image)
A Windows .BMP file is a DIB stored in a disk file. .BMP files prepend
a 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 DIBSection
was originally introduced in Windows NT to reduce the number of
memory copies during blitting (display) of a DIB.
Return to Top
Meet the Codecs
The video data in an AVI file can be formatted and compressed in
a variety of ways. Video for Windows 1.1e comes with several
compressors:
Intel Indeo (version 3.2)
Microsoft Video 1
Microsoft RLE (Run Length Encoding)
Cinepak
AVI is not restricted to these compressors. They
are the compressors provided with Video for Windows.
These compressors are the Old Guard, the video codecs
from the early days of Video for Windows and QuickTime (Cinepak originated
with the Macintosh and QuickTime). During this period the
focus of video was playback from hard drives and CD-ROM's.
The advent of the WorldWide Web and Internet Mania
has created a New Wave of audio and video codecs, trying to
apply "advanced" technologies such as sophisticated motion
estimation and compensation, wavelets, fractals, and other
techniques to achieve extremely low bitrates (such as
28.8 Kbits/second for phone lines) for the Internet.
The Old Guard
Full Frames (Uncompressed)
Users can store AVI files with uncompressed frames. No codec is
required for this.
The Four Character Code (FOURCC) for this is 'DIB ', DIB for
the Microsoft Device Independent Bitmap.
NOTE: Unfortunately, at least three other Four Character Codes are
somtimes used for uncompressed AVI videos:
'RGB '
'RAW '
0x00000000 ( a FOURCC whose hexadecimal value is 0 )
Color Formats
Not all uncompressed bitmap images and AVI frames are the same!
A variety of color formats for image pixels exist. Some of these
color formats are essentially standard and supported on all systems.
Some color formats (such as 8 bit grayscaleY8) require special
drivers to display or capture.
Color Formats are also known as IMAGE FORMATS or PIXEL FORMATS. Some
components of Microsoft Windows identify Color Formats with a Four
Character Code (FOURCC) such as 'RGB8' or 'YUY2'. Some components such
as the Windows Device Independent Bitmap or DIB do not use Four Character
Codes for color formats.
24 BIT RGB (DE FACTO STANDARD)
24-bit RGB is the most well-known color format. All common graphics
programs support 24-bit RGB. In 24 bit
RGB a pixel is represented as three bytes, one byte for the red
component, one byte for the green component, and one byte for
the blue component.
255 0 0 (a bright red pixel in 24 bit RGB)
0 255 0 (a bright green pixel in 24 bit RGB)
0 0 255 (a bright blue pixel in 24 bit RGB)
0 0 0 (a black pixel in 24 bit RGB)
255 255 255 (a white pixel in 24 bit RGB)
128 128 128 (a gray pixel in 24 bit RGB)
... and so forth.
Other color formats include:
8 bit grayscale Y8
9 bit YUV9
12 bit BTYUV 4:1:1
12 bit YUY12
16 bit YUY2 4:2:2
8 bit RGB (uses a color palette)
15 bit RGB (16 bits with most significant bit zero, 5 bits for red, 5 bits for green, and 5 bits for blue)
16 bit RGB (16 bits with 5 bits for red, 6 bits for green, and 5 bits for blue)
(24 bit RGB - described above)
32 bit RGB (most significant byte is zero, 8 bits for red, 8 bits for green, and 8 bits for blue)
Original DIB Color Formats
In the Windows 3.1 Software Development Kit, DIB's were defined to
allow values of 1,4,8, and 24 bits per pixel in the biBitCount
field of the BITMAPINFOHEADER. The biCompression field was allowed
the values BI_RGB, BI_RLE4 (for run length encoding of 4 bit per pixel
images), and BI_RLE8 (for run length encoding of 8 bit per pixel
images). That was it. This original specification of the DIB
provided the 8 bit RGB and 24 bit RGB color formats described
above.
The original DIB specification had no support for 16 bit per pixel
formats, 32 bit per pixel formats, or special encodings like YUV.
Not surprisingly, the original formats and specification of the DIB
are the most widely supported in software.
New DIB Color Formats and More Complexity
Microsoft added support for 16 bit per pixel and 32 bit per pixel
images to the DIB specification. These formats are identified by
Section 2 of 14 - Prev - Next
All sections - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 - 14
| Back to category graphics - Use Smart Search |
| Home - Smart Search - About the project - Feedback |
© allanswers.org | Terms of use