AVI文件采用的是RIFF文件结构方式，RIFF（Resource Interchange File Format，资源互换文件格式）是微软公司定义的一种用于管理windows环境中多媒体数据的文件格式，波形音频wave，MIDI和数字视频AVI 都采用这种格式存储。构造RIFF文件的基本单元叫做数据块（Chunk），每个数据块包含3个部分，
1、4字节的数据块标记（或者叫做数据块的ID）
2、数据块的大小
3、数据
整个RIFF文件可以看成一个数据块，其数据块ID为RIFF，称为RIFF块。一个RIFF文件中只允许存在一个RIFF块。 RIFF块中包含一系列的子块，其中有一种字块的ID为"LIST"，称为LIST，LIST块中可以再包含一系列的子块，但除了LIST块外的其他所有 的子块都不能再包含子块。
RIFF和LIST块分别比普通的数据块多一个被称为形式类型（Form Type）和列表类型（List Type）的数据域，其组成如下：
1、4字节的数据块标记（Chunk ID）
2、数据块的大小
3、4字节的形式类型或者列表类型
4、数据
下面我们看看AVI文件的结构。AVI文件是目前使用的最复杂的RIFF文件，它能同时存储同步表现的音频视频数据。AVI的RIFF块的形式类型是AVI，它包含3个子块，如下所述：
1、信息块，一个ID为"hdrl"的LIST块，定义AVI文件的数据格式。
2、数据块，一个ID为 "movi"的LIST块，包含AVI的音视频序列数据。
3、索引块，ID为 "idxl"的子块，定义 "movi"LIST块的索引数据，是可选块。
AVI文件的结构如下图所示，下面将具体介绍AVI文件的各子块构造。
从上面的图上可以看到另一种特殊的数据块，用一个四字符码'JUNK'来表征，它用于内部数据的队齐（填充），应用程序应该忽略这些数据块的实际意义。
下面仔细的介绍每个子块的内容：
2.1信息块
信息块包含两个子块，即一个ID为 avih 的子块和一个ID 为 strl 的LIST块。
"avih"子块的内容可由如下的结构定义：
| typedef struct { FOURCC fcc; // 必须为'avih' DWORD dwMicroSecPerFrame ; //显示每桢所需的时间ns，定义avi的显示速率 DWORD dwMaxBytesPerSec; // 最大的数据传输率 DWORD dwPaddingGranularity; //记录块的长度需为此值的倍数，通常是2048 DWORD dwFlages; //AVI文件的特殊属性，如是否包含索引块，音视频数据是否交叉存储 DWORD dwTotalFrame; //文件中的总桢数 DWORD dwInitialFrames; //说明在开始播放前需要多少桢 DWORD dwStreams; //文件中包含的数据流种类 DWORD dwSuggestedBufferSize; //建议使用的缓冲区的大小， //通常为存储一桢图像以及同步声音所需要的数据之和 DWORD dwWidth; //图像宽（以像素为单位） DWORD dwHeight; //图像高（以像素为单位） DWORD dwReserved[4]; //保留值 }MainAVIHeader; |
"strl" LIST块用于记录AVI数据流，每一种数据流都在该LIST块中占有3个子块，他们的ID分别是"strh","strf", "strd"；
"strh"子块由如下结构定义。
| typedef struct _avistreamheader { FOURCC fccType; // 流的类型：'auds'（音频流）、'vids'（视频流）、 |
上图是一个strh块的内容，73 74 72 68是strh，是此块的标示符，后面紧跟着此块的大小00 00 00 38，后面四字节是vids（绿色部分），代表着视频帧，注意后面是编码的类型，此处为H264，如红色框所示。
"strf"子块紧跟在"strh"子块之后，其结构视"strh"子块的类型而定，如下所述；如果 strh子块是视频数据流，则 strf子块的内容是一个与windows设备无关位图的BIMAPINFO结构，如下：
| typedef struct tagBITMAPINFO { BITMAPINFOHEADER bmiHeader; RGBQUAD bmiColors[1]; //颜色表 }BITMAPINFO; typedef struct tagBITMAPINFOHEADER { DWORD biSize; LONG biWidth; LONG biHeight; WORD biPlanes; WORD biBitCount; DWORD biCompression; DWORD biSizeImage; LONG biXPelsPerMeter; LONG biYPelsPerMeter; DWORD biClrUsed; DWORD biClrImportant; }BITMAPINFOHEADER; |
如果 strh子块是音频数据流，则strf子块的内容是一个WAVEFORMAT结构，如下：
| typedef struct { WORD wFormatTag; WORD nChannels; //声道数 DWORD nSamplesPerSec; //采样率 DWORD nAvgBytesPerSec; //声音中每秒的数据量 WORD nBlockAlign; //数据块的对齐标志 WORD biSize; //此结构的大小 }WAVEFORMAT |
"strd"子块紧跟在strf子块后，存储供压缩驱动程序使用的参数，不一定存在，也没有固定的结构。
"strl" LIST块定义的AVI数据流依次将 "hdrl " LIST 块中的数据流头结构与"movi" LIST块中的数据联系在一起，第一个数据流头结构用于数据流0，第二个用于数据流1，依次类推。
数据块中存储视频和音频数据流，数据可直接存于 "movi" LIST块中。数据块中音视频数据按不同的字块存放，其结构如下所述，
音频字块
"##wb"
Wave 数据流
视频子块中存储DIB数据，又分为压缩或者未压缩DIB，
"##db"
RGB数据流
"##dc"
压缩的图像数据流
可以看到数据块是以movi为开始，然后是音视频标示符+块大小，依次存放，每个块以四字节的标示符为开始，可表现为list---size----movi---00db---size---01wb---size----00db---
，其中音视频流的顺序不固定。
avi文件的图像数据可以是压缩的，和非压缩格式的。对于压缩格式来说，也可采用不同的编码，也许你曾经遇到有些avi没法识别，就是因为 编码方式不一样，如果没有相应的解码，你就没法识别视频数据。AVI的编码方式有很多种，比较常见的有 mpeg2，mpeg4，divx等。
2.2 索引块
索引块包含数据块在文件中的位置索引，能提高avi文件的读写速度，其中存放着一组AVIINDEXENTRY结构数据。如下，这个块并不是必需的，也许不存在。
| typedef struct { DWORD ckid; //记录数据块中子块的标记 DWORD dwFlags; //表示chid所指子块的属性 DWORD dwChunkOffset; //子块的相对位置 DWORD dwChunkLength; //子块长度 }; |
index段是可以没有的，视频一样可以播放。可是当你要拖动视频时，视频不会立刻跳到你所要的位置，而是加快播放速度，直到到达目标位置。而有索引段时可直接到达所要的位置。
3 拓展
根据实际文件我们看一下索引部分的结构。
首先是idx1的标示符69 64 78 31，其次是整个索引块的大小，4byte，下面就是具体的音频流、视频流的信息，首先是流的标示符，30 30 64 62，如图红色框所示，是00db代表视频流，后面蓝色框的四字节是代表是否是关键帧，10 00 00 00是关键帧，不是关键帧用00 00 00 00，后面紫色框是块的偏移地址，此地址是针对数据块的movi的标示符，最后灰色框中的四字节代表此块的大小。
下面看一下这个偏移地址
首先找到movi的地址是0x1F0+C=0x1FC，第一个00db块的地址是0x200，如图中粉色线所示，其偏移量是0x200-0x1fc=0x04
注：这里面的数需要高低位转换，例如此处00db块的大小是E0 72 00 00，实际大小应该是0x000072E0。
下面我们验证一下第二个块的偏移地址是否正确。
可以看到第二个块的地址是0x74E8，则偏移地址是0x74E8-0x1fc=0x72EC，则对应的值应该是EC 72 00 00，查看一下上面索引截图里面的偏移值确实也是此值。
通过RIFF结构我们可以看到数据区中都是以视频流、音频流间隔存放的，但是间隔又不相同。其实，这个是没有什么实际的关系，即使把所有 的视频流放在一起，然后下面才是音频流，也是可以工作的，此时只需要更改一下索引表。可以通过UltraEdit工具直接右击打开avi文件进行修改。
还可以发现一个avi文件中一般只有一个LIST：movi，此时可以人为的添加一个LIST：movi，在其放置一些音频流和视频流，并需要修改索引表，此时偏移地址只能以第一个movi的位置为准，否则无法解析，不能正常播放。
来源：oschina
链接：https://my.oschina.net/u/2404244/blog/713611