About AVI file.....

AVI简介
AVI英文全称为Audio Video Interleaved，即音频视频交错格式。是将语音和影像同步组合在一起的文件格式。它对视频文件采用了一种有损压缩方式，但压缩比较高，因此尽管面面质量不是太好，但其应用范围仍然非常广泛。AVI支持256色和RLE压缩。AVI信息主要应用在多媒体光盘上，用来保存电视、电影等各种影像信息。
它于1992年被Microsoft公司推出，随Windows3.1一起被人们所认识和熟知。所谓“音频视频交错”，就是可以将视频和音频交织在一起进行同步播放。这种视频格式的优点是图像质量好，可以跨多个平台使用，其缺点是体积过于庞大，而且更加糟糕的是压缩标准不统一，最普遍的现象就是高版本Windows媒体播放器播放不了采用早期编码编辑的AVI格式视频，而低版本Windows媒体播放器又播放不了采用最新编码编辑的AVI格式视频，所以我们在进行一些AVI格式的视频播放时常会出现由于视频编码问题而造成的视频不能播放或即使能够播放，但存在不能调节播放进度和播放时只有声音没有图像等一些莫名其妙的问题，如果用户在进行AVI格式的视频播放时遇到了这些问题，可以通过下载相应的解码器来解决。是目前视频文件的主流。 这种格式的文件随处可见，比如一些游戏、教育软件的片头，多媒体光盘中，都会有不少的AVI 。

 

 

AVI   RIFF格式  
  AVI文件是用AVI　RIFF格式的，AVI   RIFF格式由四个字符“AVI   ”确定。所有的AVI文件包括两个不可缺的LIST块，这些块定义了流格式和流数据。AVI文件也可包含有索引块，索引块是可选的，它指出了每个数据块在整个文件中的相对位置。整个AVI文件的结构如下：  
  RIFF   ('AVI   '    
            LIST   ('hdrl'  
                          .  
                          .  
                          .  
                      )  
            LIST   ('movi'    
                          .  
                          .  
                          .  
                      )  
            ['idx1'<AVI   Index>]  
            )  
  两个LISTF块和索引块是RIFF   “AVI   “子块。“AVI   ”表示该文件是AVI   RIFF文件。LIST   “hdrl”是第一个必需的块，它定义了数据的格式。LIST   “movi”块是第二个必需的块，它包含了一系列的数据。”idxl”块是可选块。这三块是必须按上述结构的顺序正确存放于AVI文件中。  
  如果再详细把”hdrl”和”movi”两个LIST块展开，那结构如下：  
  ‘RIFF’   四字节文件长度   'AVI   '  
  ‘LIST’   四字节该LIST长度   'hdrl'  
          'avih'   四字节MainAVIHeader长度　<Main   AVI   Header>  
                    ‘LIST’   四字节该LIST长度   'strl'  
                    'strh'   四字节AVIStreamHeader长度   <Stream   header>  
                            'strf’   四字节流格式长度   <Stream   format>  
                            'strd'   四字节附加头长度   additional   header   data  
                            …  
                            …  
                            …  
  'JUNK'   四字节长度   数据（一般为都为0）可选的块用来填充整个LIST到2KB          
  …  
                    …  
                    …  
  LIST   四字节该LIST长度   'movi'  
                            {SubChunk   |   LIST('rec   '  
                                                              SubChunk1  
                                                              SubChunk2  
                                                                    …  
                                                                    …  
                                                                    …  
                                                    )  
                                    …  
                                    …  
                                    …  
                            }  
                  …  
                  …  
                  …  
        )  
        ['idx1'<AVIIndex>]  
  )  
  SubChunk：(##：表示该流的序号，一般只有音频或者只有视频数据，不用rec块)  
    '##wb'　四字节后面数据长度　　音频数据  
    '##dc'　四字节后面数据长度　压缩视频数据  
    '##db'　四字节后面数据长度　未压缩视频数据  
  三个块各自内部的结构  
  一、 The   Main   AVI   Header   LIST  
  文件以main   header开头，在AVI文件中，这个头由”avih”四个字体标识，该头包含整个文件的一般信息，如文件中流的种数，视频系列的宽度和高度等。该main   header的结构如下：  
  typedef   struct   {  
          DWORD     dwMicroSecPerFrame;  
          DWORD     dwMaxBytesPerSec;  
          DWORD     dwPaddingGranularity;  
          DWORD     dwFlags;  
          DWORD     dwTotalFrames;  
          DWORD     dwInitialFrames;  
          DWORD     dwStreams;  
          DWORD     dwSuggestedBufferSize;  
          DWORD     dwWidth;  
          DWORD     dwHeight;  
          DWORD　dwReserved[4];  
  }   MainAVIHeader;  
   
  dwMicroSecPerFrame：整个文件的播放总时间  
  dwMaxBytesPerSec：指出文件大约的最大的数据率。  
  dwFlags：有以下几种标志  
  AVIF_HASINDEX：标明该AVI文件有"idx1"块  
  AVIF_MUSTUSEINDEX：标明必须根据索引表来指定数据顺序    
  AVIF_ISINTERLEAVED：标明该AVI文件是interleaved格式的  
  AVIF_WASCAPTUREFILE：标明该AVI文件是用捕捉实时视频专门分配的文件  
  AVIF_COPYRIGHTED：标明该AVI文件包含有版权信息  
  dwTotalFrames：整个文件总帧数  
  dwInitialFrames：在interleaved格式文件中才有用。  
  dwStreams：指出流的种数，如AVI文件包含有视频和音频，则为2  
  dwSuggestedBufferSize:   指出读该文件建议的缓冲大小，一般比最大的数据块长度还大。如果指定为0或者太小了，则在回放会重新分内存，这样就会影响回放效率。对于interleaved格式的文件，缓冲必须足够去读整个record，而不只是一个数据  
  dwWidth：指出avi文件视频宽度（像素）  
  dwHeight：指出avi文件视频高度（像素）  
   
  二、The   Stream   Header   ("strl")   Chunks  
  MainAVIHeader接下来就是一个或个"strl"块(一种流需要一个”str”l块)，这些块包含在文件流的信息，每个"strl"块必须包含流头和流格式块。流头由四个字符"strh"标识，流格式由"strf"标识。.除了流头和流格式块处，也可以有流数据块，它由"strd"标识  
  其结构如下：  
  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;  
   
  fccType：标识类型的四个字符，视频为"vids"，音频为"auds"。  
  fccHandler：指出标识所用压缩算法的四个字符。  
  DwFlags：  

 

 

AVISF_DISABLED   flag   indicates   that   the   stream   data   should   be   rendered   only   when   explicitly   enabled   by   the   user.    
  AVISF_VIDEO_PALCHANGES   flag   indicates   palette   changes   are   embedded   in   the   file.    
  dwInitialFrames：在interleaved格式文件中才有用。  
  dwScale和dwRate：用以计算整个AVI时间长度。帧速率等于dwScale除于dwRate的值.  
   
  The   remaining   fields   describe   the   playback   characteristics   of   the   stream.   These   factors   include   the   playback   rate   (dwScale   and   dwRate),   the   starting   time   of   the   sequence   (dwStart),   the   length   of   the   sequence   (dwLength),   the   size   of   the   playback   buffer   (dwSuggestedBuffer),   an   indicator   of   the   data   quality   (dwQuality),   and   sample   size   (dwSampleSize).   See   the   reference   section   for   more   information   on   these   fields.    
  Some   of   the   fields   in   the   stream   header   structure   are   also   present   in   the   main   header   structure.   The   data   in   the   main   header   structure   applies   to   the   whole   file   while   the   data     in   the   stream   header   structure   applies   only   to   a   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.  
  The   "strl"   chunk   might   also   contain   a   stream   data   ("strd")   chunk.   If   used,   this   chunk   follows   the   stream   format   chunk.   The   format   and   content   of   this   chunk   is   defined   by   installable   compression   or   decompression   drivers.   Typically,   drivers   use   this   information   for   configuration.   Applications   that   read   and   write   RIFF   files   do   not   need   to   decode   this   information.   They   transfer   this   data   to   and   from   a   driver   as   a   memory   block.    
  An   AVI   player   associates   the   stream   headers   in   the   LIST   "hdrl"   chunk   with   the   stream   data   in   the   LIST   "movi"   chunk   by   using   the   order   of   the   "strl"   chunks.   The   first   "strl"   chunk   applies   to   stream   0,   the   second   applies   to   stream   1,   and   so   forth.   For   example,   if   the   first   "strl"   chunk   describes   the   wave   audio   data,   the   wave   audio   data   is   contained   in   stream   0.   Similarly,   if   the   second   "strl"   chunk   describes   video   data,   then   the   video   data   is   contained   in   stream   1.  
  The   LIST   "movi"   Chunk  
  Following   the   header   information   is   a   LIST   "movi"   chunk   that   contains   chunks   of   the   actual   data   in   the   streams;   that   is,   the   pictures   and   sounds   themselves.   The   data   chunks   can   reside   directly   in   the   LIST   "movi"   chunk   or   they   might   be   grouped   into   "rec   "   chunks.   The   "rec   "   grouping   implies   that   the   grouped   chunks   should   be   read   from   disk   all   at   once.   This   is   used   only   for   files   specifically   interleaved   to   play   from   CD-ROM.  
  Like   any   RIFF   chunk,   the   data   chunks   contain   a   four-character   code   to   identify   the   chunk   type.   The   four-character   code   that   identifies   each   chunk   consists   of   the   stream   number   and   a   two-character   code   that   defines   the   type   of   information   encapsulated   in   the   chunk.   For   example,   a   waveform   chunk   is   identified   by   a   two-character   code   of   "wb".   If   a   waveform   chunk   corresponded   to   the   second   LIST   "hdrl"   stream   description,   it   would   have   a   four-character   code   of   "01wb".    
  Since   all   the   format   information   is   in   the   header,   the   audio   data   contained   in   these   data   chunks   does   not   contain   any   information   about   its   format.   An   audio   data   chunk   has   the   following   format   (the   ##   in   the   format   represents   the   stream   identifier):  
  WAVE     Bytes       '##wb'  
              BYTE         abBytes[];  
   
  Video   data   can   be   compressed   or   uncompressed   DIBs.   An   uncompressed   DIB   has   BI_RGB   specified   for   the   biCompression   field   in   its   associated   BITMAPINFO   structure.   A   compressed   DIB   has   a   value   other   than   BI_RGB   specified   in   the   biCompression   field.   For   more   information   about   compression   formats,   see   the   description   of   the   BITMAPINFOHEADER   data   structure   in   the   Microsoft   Windows   Programmers   Reference   and   Chapter   5,   "DIB   Format   Extensions   for   Microsoft   Windows."  
  A   data   chunk   for   an   uncompressed   DIB   contains   RGB   video   data.   These   chunks   are   identified   with   a   two-character   code   of   "db"   (db   is   an   abbreviation   for   DIB   bits).   Data   chunks   for   a   compressed   DIB   are   identified   with   a   two-character   code   of   "dc"   (dc   is   an   abbreviation   for   DIB   compressed).   Neither   data   chunk   will   contain   any   header   information   about   the   DIBs.   The   data   chunk   for   an   uncompressed   DIB   has   the   following   form:  
  DIB     Bits       '##db'  
            BYTE       abBits[];  
   
  The   data   chunk   for   a   compressed   DIB   has   the   following   form:  
  Compressed   DIB       '##dc'  
            BYTE                   abBits[];  
   
  Video   data   chunks   can   also   define   new   palette   entries   used   to   update   the   palette   during   an   AVI   sequence.   These   chunks   are   identified   with   a   two-character   code   of   "pc"   (pc   is   an   abbreviation   for   palette   change).   The   following   data   structure   is   defined   palette   information:  
  typedef   struct   {  
          BYTE                     bFirstEntry;  
          BYTE                     bNumEntries;  
          WORD                     wFlags;  
          PALETTEENTRY     peNew;  
  }   AVIPALCHANGE;  
   
  The   bFirstEntry   field   defines   the   first   entry   to   change   and   the   bNumEntries   field   specifies   the   number   of   entries   to   change.   The   peNew   field   contains   the   new   color   entries.    
  If   you   include   palette   changes   in   a   video   stream,   set   the   AVITF_VIDEO_PALCHANGES   flag   in   the   dwFlags   field   of   the   stream   header.   This   flag   indicates   that   this   video   stream   contains   palette   changes   and   warns   the   playback   software   that   it   will   need   to   animate   the   palette.  
  The   "idx1"   Chunk  
  AVI   files   can   have   an   index   chunk   after   the   LIST   "movi"   chunk.   The   index   chunk   essentially   contains   a   list   of   the   data   chunks   and   their   location   in   the   file.   This   provides   efficient   random   access   to   the   data   within   the   file,   because   an   application   can   locate   a   particular   sound   sequence   or   video   image   in   a   large   AVI   file   without   having   to   scan   it.    
  Index   chunks   use   the   four-character   code   "idx1".   The   following   data   structure   is   defined   for   index   entries:  
  typedef   struct   {  
          DWORD     ckid;  
          DWORD     dwFlags;  
          DWORD     dwChunkOffset;  
          DWORD     dwChunkLength;  
  }   AVIINDEXENTRY;  
   
  The   ckid,   dwFlags,   dwChunkOffset,   and   dwChunkLength   entries   are   repeated   in   the   AVI   file   for   each   data   chunk   indexed.   If   the   file   is   interleaved,   the   index   will   also   have   these   entries   for   each   "rec"   chunk.   The   "rec"   entries   should   have   the   AVIIF_LIST   flag   set   and   the   list   type   in   the   ckid   field.  
  The   ckid   field   identifies   the   data   chunk.   This   field   uses   four-character   codes   for   identifying   the   chunk.  
  The   dwFlags   field   specifies   any   flags   for   the   data.   The   AVIIF_KEYFRAME   flag   indicates   key   frames   in   the   video   sequence.   Key   frames   do   not   need   previous   video   information   to   be   decompressed.   The   AVIIF_NOTIME   flag   indicates   a   chunk   does   not   affect   the   timing   of   a   video   stream.   For   example,   changing   palette   entries   indicated   by   a   palette   chunk   should   occur   between   displaying   video   frames.   Thus,   if   an   application   needs   to   determine   the   length   of   a

 

现在，在WINDOWS 95或98里都能直接播放AVI，而且它自己的格式也有好几种，最常见的有 Intel Indeo（R）Video R3.2、Microsoft video 等。
含三部分
文件头、数据块和索引块。
其中数据块包含实际数据流，即图像和声音序列数据。这是文件的主体，也是决定文件容量的主要部分。视频文件的大小等于该文件的数据率乘以该视频播放的时间长度，索引块包括数据块列表和它们在文件中的位置，以提供文件内数据随机存取能力。文件头包括文件的通用信息，定义数据格式，所用的压缩算法等参数。
nAVI格式
nAVI是newAVI的缩写，是一个名为ShadowRealm的地下组织发展起来的一种新视频格式(与我们上面所说的AVI 格式没有太大联系)。它是由Microsoft ASF压缩算法的修改而来的，但是又与下面介绍的网络影像视频中的ASF视频格式有所区别，它以牺牲原有ASF视频文件视频“流”特性为代价而通过增加帧率来大幅提高ASF视频文件的清晰度。
DV-AVI格式
DV的英文全称是Digital Video Format，是由索尼、松下、JVC等多家厂商联合提出的一种家用数字视频格式。目前非常流行的数码摄像机就是使用这种格式记录视频数据的。它可以通过电脑的IEEE 1394端口传输视频数据到电脑，也可以将电脑中编辑好的的视频数据回录到数码摄像机中。这种视频格式的文件扩展名一般是.avi，所以也叫DV-AVI 格式。 17file.COM
目前（07年10月）AVI图象反转的原因很可能是暴风影音和windows media player冲突，下载一个完整的DIVX解码器可以解决。
1992年初Microsoft公司推出了AVI技术及其应用软件VFW（Video for Windows）。在AVI文件中，运动图像和伴音数据是以交织的方式存储，并独立于硬件设备。这种按交替方式组织音频和视像数据的方式可使得读取视频数据流时能更有效地从存储媒介得到连续的信息。构成一个AVI文件的主要参数包括视像参数、伴音参数和压缩参数等：
AVI没有MPEG这么复杂，从WIN3.1时代，它就已经面世了。它最直接的优点就是兼容好、调用方便而且图象质量好，因此也常常与DVD相并称。但它的缺点也是十分明显的：体积大。也是因为这一点，我们才看到了MPEG-1和MPEG-4的诞生。2小时影像的AVI文件的体积与MPEG-2相差无计，不过这只是针对标准分辨率而言的：根据不同的应用要求，AVI的分辨率可以随意调。窗口越大，文件的数据量也就越大。降低分辨率可以大幅减低它的体积，但图象质量就必然受损。与MPEG-2格式文件体积差不多的情况下，AVI格式的视频质量相对而言要差不少，但制作起来对电脑的配置要求不高，经常有人先录制好了AVI格式的视频，再转换为其他格式。
视像参数
1、视窗尺寸（Video size）：根据不同的应用要求，AVI的视窗大小或分辨率可按4：3的比例或随意调整：大到全屏640×480，小到160×120甚至更低。窗口越大，视频文件的数据量越大。 内容来自:17file.COM
2、帧率（Frames per second）：帧率也可以调整，而且与数据量成正比。不同的帧率会产生不同的画面连续效果。
伴音参数
在AVI文件中，视像和伴音是分别存储的，因此可以把一段视频中的视像与另一段视频中的伴音组合在一起。AVI 文件与WAV文件密切相关，因为WAV文件是AVI文件中伴音信号的来源。伴音的基本参数也即WAV文件格式的参数，除此以外，AVI文件还包括与音频有关的其他参数：
1、视像与伴音的交织参数（Interlace Audio Every X Frames）AVI格式中每X帧交织存储的音频信号，也即伴音和视像交替的频率X是可调参数，X的最小值是一帧，即每个视频帧与音频数据交织组织，这是CD－ROM上使用的默认值。交织参数越小，回放AVI文件时读到内存中的数据流越少，回放越容易连续。因此，如果AVI文件的存储平台的数据传输率较大，则交错参数可设置得高一些。当AVI文件存储在硬盘上时，也即从硬盘上读AVI文件进行播放时，可以使用大一些的交织频率，如几帧，甚至1秒。
2、同步控制（Synchronization）
在AVI文件中，视像和伴音是同步得很好的。但在MPC中回放AVI文件时则有可能出现视像和伴音不同步的现象。
压缩参数
在采集原始模拟视频时可以用不压缩的方式，这样可以获得最优秀的图像质量。编辑后应根据应用环境环择合适的压缩参数。

数字视频
AVI及其播放器VFW已成为了PC机上最常用的视频数据格式，是由于其具有如下的一些显著特点：
一、提供无硬件视频回放功能
AVI格式和VFW软件虽然是为当前的MPC设计的，但它也可以不断提高以适应MPC的发展。根据AVI格式的参数，其视窗的大小和帧率可以根据播放环境的硬件能力和处理速度进行调整。在低档MPC机上或在网络上播放时，VFW的视窗可以很小，色彩数和帧率可以很低；而在Pentium级系统上，对于64K色、320×240的压缩视频数据可实现每秒25帧的回放速率。这样，VFW就可以适用于不同的硬件平台，使用户可以在普通的MPC上进行数字视频信息的编辑和重放，而不需要昂贵的专门硬件设备。
二、实现同步控制和实时播放
通过同步控制参数，AVI可以通过自调整来适应重放环境，如果MPC的处理能力不够高，而AVI文件的数据率又较大，在WINDOWS环境下播放该AVI文件时，播放器可以通过丢掉某些帧，调整AVI的实际播放数据率来达到视频、音频同步的效果。
三、可以高效地播放存储在硬盘和光盘上的AVI文件
由于AVI数据的交叉存储，VFW播放AVI数据时只需占用有限的内存空间，因为播放程序可以一边读取硬盘或光盘上的视频数据一边播放，而无需预先把容量很大的视频数据加载到内存中。在播放AVI视频数据时，只需在指定的时间内访问少量的视频图像和部分音频数据。这种方式不仅可以提高系统的工作效率，同时也可以实现迅速地加载和快速地启动播放程序，减少播放AVI视频数据时用户的等待时间。 本文来自:17file.COM
四、提供了开放的AVI数字视频文件结构
AVI文件结构不仅解决了音频和视频的同步问题，而且具有通用和开放的特点。它可以在任何Windows环境下工作，而且还具有扩展环境的功能。用户可以开发自己的AVI视频文件，在Windows环境下可随时调用。
五、AVI文件可以再编辑
AVI一般采用帧内有损压缩，可以用一般的视频编辑软件如Adobe Premiere或MediaStudio进行再编辑和处理。