|
| Home > Photo, Video, Graphics > graphics > |
| AVI Graphics Format Overview |
Section 5 of 14 - Prev - Next
All sections - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 - 14
Cinepak). Typically, some blocks (hopefully many) are similar to other blocks although usually not identical. The encoder identifies a class of similar blocks and replaced these with a "generic" block representative of the class of similar blocks. The encoder encodes a lookup table that maps short binary codes to the "generic" blocks. Typically, the shortest binary codes represent the most common classes of blocks in the image. The Vector Quantization (VQ) decoder uses the lookup table to assemble an approximate image comprised of the "generic" blocks in the lookup table. Note that this is inherently a lossy compression process because the actual blocks are replaced with a generic block that is a "good enough" approximation to the original block. The encoding process is slow and computationally intensive because the encoder must accumulate statistics on the frequency of blocks and calculate the similarity of blocks in order to build the lookup table. The decoding process is very quick because it is lookup table based. In Vector Quantization, the lookup table may be called a codebook. The binary codes that index into the table may be called codewords. Higher compression is achieved by making the lookup table smaller, fewer classes of similar blocks in the image. The quality of the reproduced approximate image degrades as the lookup table becomes smaller. Vector Quantization is prone to blocking artifacts as compression is increased. Vector Quantization is an entire sub-field in signal and image processing. It goes well beyond the brief description above and is applied to other uses than video compression. The standard reference book on Vector Quantization is: Vector Quantization and Signal Compression A. Gersho and R. Gray Boston, MA : Kluwer, 1992 Like many image and signal processing books, this is heavy on abstract math.A Simple Example
Consider the following 4 by 4 blocks of pixels. Each pixel has a value in the range of 0-255. This is a grayscale image for simplicity. (Block 1) 128 128 128 128 128 128 128 128 128 128 128 128 128 128 128 128 (Block 2) 128 127 128 128 128 128 128 128 128 128 127 128 128 128 128 128 (Block 3) 128 127 126 128 128 128 128 128 127 128 128 128 128 128 128 128 In practice, the blocks will look the same to a human viewer. The second and third blocks could be safely replaced by the first block. By itself, this does not compress the image. However, the replacement block (Block 1) could be represented by a short index into a lookup table of 4x4 blocks. For example, the index, in this case, could be 1. Lookup Table[1] = 128 128 128 128 128 128 128 128 128 128 128 128 128 128 128 128 The original image could be converted into a lookup table and a series of indexes into the lookup table, achieving substantial compression. In video, the same lookup table could be used for many frames, not just a single frame. Return to TopDiscrete Cosine Transform
VIDEO CODECS THAT USE DCT Motion JPEG Editable MPEG MPEG-1 MPEG-2 MPEG-4 H.261 H.263 H.263+ STRENGTHS AND WEAKNESSES 1. Blocking artifacts at high compression. 2. Ringing at sharp edges. Occasional blurring at sharp edges. 3. Computationally intensive. Only recently has it been possible to implement in real time on general purpose CPU's as opposed to specialized chips. OVERVIEW The Discrete Cosine Transform (DCT) is a widely used transform in image compression. The JPEG still image compression standard, the H.261 (p*64) video-conferencing standard, the H.263 video-conferencing standard and the MPEG (MPEG-1, MPEG-2, and MPEG-4) digital video standards use the DCT. In these standards, a two-dimensional (2D) DCT is applied to 8 by 8 blocks of pixels in the image that is compressed. The 64 (8x8 = 64) coefficients produced by the DCT are then quantized to provide the actual compression. In typical images, most DCT coefficients from a DCT on an 8 by 8 block of pixels are small and become zero after quantization. This property of the DCT on real world images is critical to the compression schemes. In addition, the human eyes are less sensitive to the high frequency components of the image represented by the higher DCT coefficients. A large quantization factor can and usually is applied to these higher frequency components. The de facto standard quantization matrix (a matrix of 64 quantization factors, one for each of the 64 DCT coefficients) in the JPEG standard has higher quantization factors for higher frequency DCT coefficients. The quantized DCT coefficients are then run-length encoded as variable length codes that indicate some number of zero coefficients followed by a non-zero coefficient. For example, a run-length code might indicate 4 zero coefficients followed by a non-zero coefficient of level 2. Short variable length codes (e.g. 0110) are used for common combinations of runs of zero and levels of the non-zero coefficient. Longer variable length codes (e.g. 0000001101) are used for less common combinations of runs of zero and levels of the non-zero coefficient. In this way, substantial compression of the image is possible. The Discrete Cosine Transform itself is best explained as a 1 dimensional (1D) DCT first. The 2D DCT is equivalent to performing a 1D DCT on each row of a block of pixels followed by a 1D DCT on each column of the block of pixels produced by the 1D DCT's on the rows. The one dimensional Discrete Cosine Transform is applied to a block of N samples (pixels in an image or sound pressure samples in an audio file). The Discrete Cosine Transform is an NxN matrix whose rows are sampled cosine functions: DCT(m,n) = sqrt( (1 - delta(m,1) ) / N ) * cos( (pi/N) * (n - 1/2) * (m-1) ) where DCT(m,n) is the 1D DCT Matrix m,n = 1,...,N pi = 3.14159267... N = number of samples in block delta(m,1) = 1 if m is 1 0 otherwise cos(x) = cosine of x (radians) * = multiply Naively, performing a DCT on a block of N samples would require N*N multiplies and adds. However, the DCT matrix has a recursive structure that allows implementation with order N log(N) multiplies and adds (many fewer). This makes the DCT practical for implementation on current CPUs and DSPs. Return to TopDiscrete Wavelet Transform (DWT)
Video Codecs Using the Discrete Wavelet Transform: VDONet's VDOWave VxTreme Intel Indeo 5.x (possibly) Intel Indeo 4.x STRENGTHS AND WEAKNESSES 1. Most video and image compression implemented using the Discrete Wavelet Transform does not exhibit the blocking, also known as tiling, artifacts seen with the block Discrete Cosine Transform. 2. DWT based video and image compression often outperforms block DCT compression if evaluated using the Peak Signal to Noise Ratio (PSNR) or Mean Squared Error (MSE) metric (these are mathematically equivalent). 3. The subjective quality of video or images compressed with DWT can appear better than block DCT methods for the same compression ratio. 4. Wavelet compression exhibits blurring and ringing artifacts at sharp edges as compression increases. This is an inherent weakness of the method, shared with the Discrete Cosine Transform which also exhibits the same type of artifacts. The ringing artifacts are also known as contouring, mosquito noise, and the Gibbs effect. OVERVIEW The Discrete Wavelet Transform essentially consists of passing a signal, such as an image, through a pair of filters, a low pass filter and a high pass filter. The low pass filter yields a coarse or low resolution version of the signal. The high pass filter yields an added detail or difference signal. The outputs of the two filters are then downsampled by two. Thus, at this point the downsampled outputs have the same number of bits as the input signal. The parameters of the two filters are selected so that when the upsampled output of the low pass filter is added to the upsampled output of the high pass filter, the original signal is reproduced. The output of the high pass filter, the added detail signal, may then be fed into another pair of filters and the process repeated. A simple example of the discrete wavelet transform is the Haar wavelet transform. The input signal is x[n], a series of samples indexed by n. Haar Low Pass Filter (the average of two successive samples) g[n] = 1/2 * ( x[n] + x[n+1] ) Haar High Pass Filter (the difference of two successive samples) h[n] = 1/2 * ( x[n+1] - x[n] ) Note that: x[n] = g[n] - h[n] x[n+1] = g[n] + h[n] The output sequences g[n] and h[n] contain redundant information. One can safely downsample by two, that is omit the even or odd samples, and still reproduce the original input signal x[n]. Usually the odd samples are omitted. The complete input signal x[n] can be reproduced from g[0], g[2], g[4], .... h[0], h[2], h[4], .... alone. x[0] = g[0] - h[0] x[1] = g[0] + h[0] x[2] = g[2] - h[2] x[3] = g[2] + h[2] and so on. The output of the low pass filter is a coarse approximation of the original input signal. When the input signal is an image, this means a - sometimes blurry - low resolution version of the original image. The output of the high pass filter is an added detail or difference signal. When combined with the coarse approximation, as described, the original input signal is exactly reproduced. The coarse approximation is sometimes called a base layer and the added detail is sometimes called an enhancement layer. The output of the high pass filter, h[n], can be fed into another pair of filters, repeating the process. The Discrete Wavelet Transforms used in wavelet image and video compression iterate the process many times. So far, no compression has occured. The transform produces the same number of bits as the input signal. The output values are called transform coefficients or wavelet transform coefficients. The Haar wavelet is used primarily for illustrative purposes. More complex filters are used for most real wavelet implementations. Compression is typically achieved by applying some form of quantization, scalar quantization in simple implementations and vector quantization in more complex implementations, to the added detail signals. Some type of entropy coding may be applied to the quantized transform coefficients. For example, in the crude Haar wavelet example, the input signal x[n] might be a series of 8 bit samples such as a raster scan of a gray scale image. One could continue to use 8 bits for the output of the low pass filter, g[n]. However, use only 6 bits (divide by 4) for the output of the high pass filter, h[n] - the detail signal. This is scalar quantization. Further, the output of the high pass filter in the Haar case will tend to be peaked toward zero, that is small coefficients will be more common than large coefficients. Thus, some form of entropy coding of the detail signal h[n] is possible. In fact, for most natural images, the low pass signal g[n] will be correlated with previous samples g[n-1] except at edges. g[n] will tend to be close to or the same as g[n-1]. Objects tend to have a continuous surface material, such as skin, with a constant surface reflectance, a texture. The texture can be a simple constant color level or a complex periodic or quasi-periodic pattern, for example wallpaper or marble. Thus the low pass signal g[n] could be encoded as a difference from previous samples g[n-1] to achieve further compression. For image coding, the notion is that the human visual system is less sensitive to fine details in the image than to the gross features. Thus quantization can be applied to the detail signals more strongly. Return to TopContour-Based Image Coding
Video Codecs Using Contour-Based Image Coding: Crystal Net's Surface Fitting Method (SFM) may be an example of Contour-Based Image Coding. The emerging ISO standard MPEG-4 incorporates some ideas associated with Contour-Based Image Coding. OVERVIEW A contour is a line representing the outline of a figure, body, or mass. A texture is a representation of the structure of a surface. Contour-based image coding represents images as contours bounding textured regions. Since contours frequently correspond to the boundaries of objects in a scene there is a close relationship between contour-based image coding and object-based image coding. Object-based image coding represents an image as a collection of objects. For example, once contours and textures have been extracted from an image, the contours can be encoded as the control points of a spline - a polynomial function used to represent curves - fitted to the contour. The textures can be encoded as the transform coefficients from a spatial frequency transform such as the Discrete Cosine Transform or the many variants of the Discrete Wavelet Transform. Compression can be achieved through entropy coding of scalar or vector quantization of the control parameters of the spline and the transform coeffecients used for the texture. Contour-Based Image Coding is a very leading edge image coding technology (May, 1999). Extracting contours, also known as edge or line detection, remains an unsolved problem in computer science. Whereas human viewers have an easy sense of what is and is not a contour or line in a scene, computer algorithms - so far - miss some contours, as defined by humans, and also find spurious contours, as defined by humans. Extracting contours is one of a number of pattern recognition and reasoning tasks that seem almost effortless in humans but have proven difficult - impossible so far - to emulate with computers. A number of edge detection and image segmentation algorithms exist that could be applied to the contour extraction in contour-based image coding. In principle, contour based image coding could circumvent the problems that transform coding methods such as the Discrete Cosine Transform (JPEG, MPEG, H.261, H.263, DV, etc.) and the Discrete Wavelet Transform (Intel Indeo, VDONet VDOWave, etc.) encounter at sharp edges, achieving higher compression.Frame Differencing
VIDEO CODECS THAT USE FRAME DIFFERENCING Cinepak STRENGTHS AND WEAKNESSES 1. Generally can achieve better compression than independent encoding of individual frames. 2. Errors accumulate in successsive frames after a key frame, eventually requiring another key frame. (see below) OVERVIEW Frame Differencing exploits the fact that little changes from frame to frame in many video or animation sequences. For example, a video might show a ball flying through the air in front of a static background. Most of the image, the background, does not change from frame to subsequent frame in the scene. In frame differencing, the still image compression method such as vector quantization is applied to the difference between the frame and the decoded previous frame. Often, most of the difference is zero or small values which can be heavily compressed. Most often, frame differencing uses "key frames" which are frames compressed without reference to a previous frame. This limits accumulated errors and enables seeking within the video stream. In the widely used Cinepak, a key frame is often set every 15 frames. Cinepak movies usually use frame differencing combined with vector quantization. If the compression scheme is lossy (vector quantization is lossy), errors will accumulate from frame to frame. Eventually these errors will become visible. This necessitates key frames! Return to TopMotion Compensation
VIDEO CODECS THAT USE MOTION COMPENSATION ClearVideo (RealVideo) Fractal Video Codec from Iterated Systems VDOWave from VDONet VxTreme MPEG-1,2, and 4 H.261 H.263 H.263+ STRENGTHS AND WEAKNESSES 1. Motion compensation achieves high video compression in video generally superior to frame differencing. 2. The encoding phase of motion compensation (known as motion estimation) is computationally intensive. MPEG-1 with IP and B frames cannot be encoded in real time without dedicated hardware, a silicon implementation of motion estimation. 3. The motion compensation scheme used in the international standards MPEG, H.261, and H.263 works best for scenes with limited motion such as talking heads. In general, video with heavy motion such as sports video is hard to compress with motion compensation. OVERVIEW Motion Compensation codes for motion within a scene such as a ball moving across a background. The block Discrete Cosine Transform (DCT) based international video standards MPEG-1, MPEG-2, MPEG-4, H.261, and H.263 use motion compensation. Iterated Systems ClearVideo (Real Video) fractal Video Codec, VDOWave from VDONet, and VxTreme's video codec use forms of motion compensation. Motion Compensation refers to a number of ideas and algorithms. The motion compensation method used in MPEG and related international standards (H.261 and H.263) is described below. This motion compensation works for translational motion only. This is suited for objects moving across a background or panning of the camera. It does not work well for spinning objects, resizing objects, or camera zooms. Alternative forms of motion compensation exist which handle rotational, scaling, skewing, and other kinds of motion in a scene. Recognizing objects such as a flying ball in a scene is an unsolved problem in image processing and understanding. A way to exploit the motion of the ball to achieve image compression is to partition the image into blocks (16x16 pixels in MPEG-1). Code a "motion vector" for each block which points to the 16x16 pixel block in a previous (or future) frame that most closely approximates the block being coded. In many cases this reference block will be the same block (no motion). In some cases this reference block will be a different block (motion). The encoder need not recognize the presence of a ball or other object, only compare blocks of pixels in the decoded and reference frames. COMPRESSION IS ACHIEVED BY SENDING OR STORING ONLY THE MOTION VECTOR (AND A POSSIBLE SMALL ERROR) INSTEAD OF THE PIXEL VALUES FOR THE ENTIRE BLOCK. Note that the reference block can be anywhere in the image. The coded or "predicted" blocks must form a partition or tiling of the image (frame) being decoded. A reference block can be any 16x16 pixel block in the reference frame (image) that most closely approximates the coded or "predicted" block. The reference frame must be decoded prior to the current frame being decoded. However, the reference frame need not be PRESENTED before the current frame being decoded. In fact, the reference frame could be a future frame!! MPEG allows for this through so-called B (bi-directionally predicted) frames. In the example of the ball in front of a static background, no motion occurs in most of the blocks. For these cases, the motion vectors are zero. Motion compensation for these blocks is then equivalent to frame differencing, where the difference between the block and the same block in a previous (or future) frame is coded. For the block or blocks containing the moving ball, the motion vectors will be non-zero, pointing to a block in a previous (or future) frame that contains the ball. The displaced block is subtracted from the current block. In general, there will be some left over non-zero values, which are then coded using the still image compression scheme such as Vector Quantization, the Block Discrete Cosine Transform, or the Discrete Wavelet Transform. MPEG style motion compensation does not require recognition of the ball. An encoder simply compares the block being coded with displaced blocks in the reference frame (a previous or future frame). The comparison can use mean squared error or some other metric of differences between images. The encoder selects the displaced block with the smallest mean squared error difference! At no point has the encoder recognized an object in the image. In MPEG, the motion vectors are encoded as variable length codes for greater compression. The encoding process is called Motion Estimation. This finds the motion vector (or vectors) for each block. The decoding process is called Motion Compensation. Motion Compensation achieves greater compression than simple Frame Differencing. ILLUSTRATIVE EXAMPLE: Predicted Region Reference Region (the current frame being decoded) (a previously decoded frame) _________ _________ | | | | | | | * | | | | * | (moving ball) | 4 | -4 | | | | | | | | | | _________ _________ | | | | | | | 0 | 0 | | | | (no change) | | | | | | | | | | | | _________ _________ The asterisk (*) represents a ball flying across the scene from right to left. Four blocks with associated motion vectors (4, -4, 0, and 0). The upper left block looks like the upper right block in the reference region (where the ball was). The upper right block looks like the upper left region in the reference region. The lower left and lower right blocks were unchanged. In this simple example, the vertical displacement is zero and is ignored. In this simple example, the region can be decoded using the motion vectors alone. In more general cases, there is an error between the frame predicted using motion vectors alone and the actual frame. This error is coded using a still image compression scheme such as the block Discrete Cosine Transform (DCT). In this simple example, the previously decoded frame is also previous in the presentation order. The previously decoded or reference frame precedes the current frame in time. In general, keep in mind the distinction between decode order and presentation order. The reference frame could be a future frame. Return to TopAudio Codecs
The sound tracks in an AVI file are Microsoft Waveform Audio (WAV) files. The Waveform Audio files can be uncompressed PCM (Pulse Code Modulated) audio or compressed with many different audio codecs (compressor/decompressors). The windows multimedia system uses the terms WAVE or waveform audio to refer to audio that consists of digitally sampled sound. In contrast to notes of music as in MIDI, another type of audio incorporated in the Windows multimedia system. The WAV, WAVE, or waveform audio system (different authors use all three to refer to the Microsoft Windows audio system) predates Video for Windows. Video for Windows was wrapped around WAVE. Various compromises were made to insure backward compatibility with existing WAVE applications, drivers, and files. Keep this in mind as there are various differences between the audio system and the video system described in other sections of this overview. To play a waveform audio (WAV) file or the sound track of an AVI compressed with a codec, the codec must be installed in the Audio Compression Manager under Windows. Windows PCM files (uncompressed) are always supported. The Audio Compression Manager (ACM) is the software system in Windows that manages waveform audio codecs and filters. Different audio codecs are identified with different waveform audio tags, 32 bit numbers. Wave audio format tags are registered with Microsoft. The following list of registered wave audio formats if from the mmreg.h file in the Win32 SDK. mmreg.h is the Registered Multimedia Information Public Header File /* WAVE form wFormatTag IDs */ #define WAVE_FORMAT_UNKNOWN 0x0000 /* Microsoft Corporation */ #define WAVE_FORMAT_ADPCM 0x0002 /* Microsoft Corporation */ #define WAVE_FORMAT_IBM_CVSD 0x0005 /* IBM Corporation */ #define WAVE_FORMAT_ALAW 0x0006 /* Microsoft Corporation */ #define WAVE_FORMAT_MULAW 0x0007 /* Microsoft Corporation */ #define WAVE_FORMAT_OKI_ADPCM 0x0010 /* OKI */ #define WAVE_FORMAT_DVI_ADPCM 0x0011 /* Intel Corporation */ #define WAVE_FORMAT_IMA_ADPCM (WAVE_FORMAT_DVI_ADPCM) /* Intel Corporation */ #define WAVE_FORMAT_MEDIASPACE_ADPCM 0x0012 /* Videologic */ #define WAVE_FORMAT_SIERRA_ADPCM 0x0013 /* Sierra Semiconductor Corp */ #define WAVE_FORMAT_G723_ADPCM 0x0014 /* Antex Electronics Corporation */ #define WAVE_FORMAT_DIGISTD 0x0015 /* DSP Solutions, Inc. */ #define WAVE_FORMAT_DIGIFIX 0x0016 /* DSP Solutions, Inc. */ #define WAVE_FORMAT_DIALOGIC_OKI_ADPCM 0x0017 /* Dialogic Corporation */ #define WAVE_FORMAT_YAMAHA_ADPCM 0x0020 /* Yamaha Corporation of America */ #define WAVE_FORMAT_SONARC 0x0021 /* Speech Compression */ #define WAVE_FORMAT_DSPGROUP_TRUESPEECH 0x0022 /* DSP Group, Inc */ #define WAVE_FORMAT_ECHOSC1 0x0023 /* Echo Speech Corporation */ #define WAVE_FORMAT_AUDIOFILE_AF36 0x0024 /* */ #define WAVE_FORMAT_APTX 0x0025 /* Audio Processing Technology */ #define WAVE_FORMAT_AUDIOFILE_AF10 0x0026 /* */ #define WAVE_FORMAT_DOLBY_AC2 0x0030 /* Dolby Laboratories */ #define WAVE_FORMAT_GSM610 0x0031 /* Microsoft Corporation */ #define WAVE_FORMAT_ANTEX_ADPCME 0x0033 /* Antex Electronics Corporation */ #define WAVE_FORMAT_CONTROL_RES_VQLPC 0x0034 /* Control Resources Limited */ #define WAVE_FORMAT_DIGIREAL 0x0035 /* DSP Solutions, Inc. */ #define WAVE_FORMAT_DIGIADPCM 0x0036 /* DSP Solutions, Inc. */ #define WAVE_FORMAT_CONTROL_RES_CR10 0x0037 /* Control Resources Limited */ #define WAVE_FORMAT_NMS_VBXADPCM 0x0038 /* Natural MicroSystems */ #define WAVE_FORMAT_CS_IMAADPCM 0x0039 /* Crystal Semiconductor IMA ADPCM */ #define WAVE_FORMAT_G721_ADPCM 0x0040 /* Antex Electronics Corporation */ #define WAVE_FORMAT_MPEG 0x0050 /* Microsoft Corporation */ #define WAVE_FORMAT_CREATIVE_ADPCM 0x0200 /* Creative Labs, Inc */ #define WAVE_FORMAT_CREATIVE_FASTSPEECH8 0x0202 /* Creative Labs, Inc */ #define WAVE_FORMAT_CREATIVE_FASTSPEECH10 0x0203 /* Creative Labs, Inc */ #define WAVE_FORMAT_FM_TOWNS_SND 0x0300 /* Fujitsu Corp. */ #define WAVE_FORMAT_OLIGSM 0x1000 /* Ing C. Olivetti & C., S.p.A. */ #define WAVE_FORMAT_OLIADPCM 0x1001 /* Ing C. Olivetti & C., S.p.A. */ #define WAVE_FORMAT_OLICELP 0x1002 /* Ing C. Olivetti & C., S.p.A. */ #define WAVE_FORMAT_OLISBC 0x1003 /* Ing C. Olivetti & C., S.p.A. */ #define WAVE_FORMAT_OLIOPR 0x1004 /* Ing C. Olivetti & C., S.p.A. */ // // the WAVE_FORMAT_DEVELOPMENT format tag can be used during the // development phase of a new wave format. Before shipping, you MUST // acquire an official format tag from Microsoft. // #define WAVE_FORMAT_DEVELOPMENT (0xFFFF) Return to TopHow to determine which Audio Codecs are Installed
View the SYSTEM.INI file. In Windows 95, 32 bit Audio Codecs are listed in the [drivers32] section. [drivers32] msacm.lhacm=lhacm.acm msacm.l3codec=l3codecb.acm msacm.msg723=msg723.acm msacm.msnaudio=msnaudio.acm The string msacm stands for Microsoft Audio Compression Manager (ACM). This is the system software component that manages audio codecs (and other audio components) in 16 bit Windows and in Win32. The different codecs are identified by a string of arbitrary length such as msnaudio for Microsoft Network Audio. Note that this differs from Video for Windows where everything is a Four Character Code. The audio codecs in the example above were installed in Windows 95 by Microsoft's NetShow streaming audio/video product. The Audio Compression Manager (ACM) is in the process of being displaced by ActiveMovie. In Windows 95, (1) Open the Control Panel (2) Double Click on the Multimedia Icon (3) Select the Advanced tab (4) Under the Multimedia Drivers icon, double click on the Audio Compression Codecs icon to see a list of installed audio codecs. This information is the same as the information stored in the SYSTEM.INI file (see above). Return to TopActiveMovie
Active Movie is a new multimedia architecture for Windows 95 and Windows NT (4.0 and after). ActiveMovie includes support for playing AVI, QuickTime (.MOV), and MPEG files. ActiveMovie is apparently intended to supersede Video for Windows. ActiveMovie 1.0 ships with the OEM Service Release 2 (OSR2) of Windows 95. It did not ship with prior releases of Windows 95 but was available separately through the ActiveMovie SDK. ActiveMovie 1.0 is also bundled with Microsoft's Internet Explorer for Windows 95 and NT 4.0 Internet Explorer can be downloaded from the Microsoft Web site at: http://www.microsoft.com/ie/ Active Movie 1.0 can be downloaded by itself from the Microsoft Internet Explorer site. (6/6/97) ActiveMovie 1.0 appears to be a 32 bit software component that runs under both Windows 95 and Windows NT 4.0 user mode. ActiveMovie provides at least three different programming interfaces: - The ActiveMovie ActiveX Control - ActiveMovie Component Object Model (COM) interfaces - The OM-1 MPEG MCI (Media Control Interface) command set Amongst other things, the ActiveMovie ActiveX Control can be embedded in HTML Web pages and programmed via VBScript or JavaScript. It can also be programmed using Visual C++ or Visual Basic as part of applications. The ActiveMovie COM interaces can be accessed through Visual C++ or Visual Basic. ActiveMovie supports a subset of the Media Control Interface (MCI) commands familiar to Video for Windows programmers. These commands can be accessed through the mciSendCommand(...) and mciSendString(...) functions in C/C++. ActiveMovie 1.0 does NOT provide video capture. Windows 95 with ActiveMovie 1.0 continues to use the Video for Windows video capture system and drivers. ActiveMovie 2.0 (renamed DirectShow in 1997) will provide a new, alternative mechanism for video capture. According to information distributed by Microsoft at the WDM Device Driver Conference in April, 1997, ActiveMovie 2.0 will use the WDM Stream Class under Memphis (formerly Windows 97) and Windows NT 5.0 to implement video capture. This is subject to possible change since neither Memphis nor NT 5.0 has been released (7/27/97). Extensive information on ActiveX and ActiveMovie is available at the Microsoft Web site. ActiveMovie 1.0 SDK Documentation at (6/28/97): http://www.microsoft.com/devonly/tech/amo v1doc/ Return to TopGUID's and AVI
GUID stands for Global Unique IDentifier. In Microsoft's Component Object Model (COM) morass, an object oriented programming model that incorporates MFC (Microsoft Foundation Classes), OLE (Object Linking Embedding), ActiveX, ActiveMovie and everything else Microsoft is hawking lately, a GUID is a 16 byte or 128 bit number used to uniquely identify objects, data formats,
Section 5 of 14 - Prev - Next
All sections - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 - 14
| Back to category graphics - Discuss "AVI Graphics Format Overview" |
| Home - Search - About the project - Forum - Feedback |
© allanswers.org | Terms of use