在此不再详述，其中AVFrame是包含码流参数较多的结构体。本文将会详细分析一下该结构体里主要变量的含义和作用。
(位于libavutil/frame.h)
首先看一下结构体的描述:
- 该结构描述被解码的音频或视频数据（原始数据）
- AVFrame必须用av_frame_alloc分配。注意，这仅分配AVFrame本身，对于数据缓冲器，必须通过其他手段管理。AVFrame必须使用av_frame_free释放。AVFrame通常分配一次，然后多次重复使用(比如一个AVFrame持有多个从解码器接收的frame)在这种情况下，av_frame_unref将释放所持的任何引用，并重置AVFrame到初始状态。
- 由AVFrame描述的数据通常是通过调用AVBuffer API计数。底层缓冲引用存储在AVFrame.buf/AVFrame.extended_buf中。如果有至少一个参数被设置过，比如AVFrame.buf[0]！= NULL，AVFrame通常被认为应该使用引用计数。 在这种情况下，每一个数据平面必须包含被包含在AVFrame.buf或AVFrame.extended_buf中。
- AVFrame的size并不在公开的ABI中，所以在附加模块的末尾可以新加变量。被av_opt_ptr标记为仅访问的类似字段可以重新排序。
#define AV_NUM_DATA_POINTERS 8
变量:
指向图片/信道层的指针
与初始化时分配的大小可能不同
一些解码器取数据范围超出（0，0）－（width，height），具体请查看avcodec_align_dimensions2()方法。
一些过滤器和扫描器读数据时可能会超过16字节，所以当它们被使用的时候，必须额外分配16字节。
uint8_t *data[AV_NUM_DATA_POINTERS];
对于视频数据，为每个图像行的字节大小
对于音频数据，为每个平面的字节大小。
对于音频，只有LINESIZE[0]可以设置。
对于平面音频，每个信道平面必须是相同的大小。
对于视频的linesizes应为CPU的对准要求的倍数，现代桌面CPU为16或32。某些代码需要这样对准，其它代码可以偏慢没有正确对齐，但目前没有区别。
@注意 linesize可大于可用的数据的尺寸 - 有可能存在由于性能原因额外填充。
int linesize[AV_NUM_DATA_POINTERS];
指向图片/信道层的指针
对于视频，只是指向数据。
对于平面音频，每个通道都有一个单独的数据指针，LINESIZE[0]包含各信道的缓冲区的大小。
用于打包的音频，只有一个数据指针，和LINESIZE[0]包含缓冲所有通道的总大小。
注意：两个数据和扩展数据应该总是在一个有效的帧进行设置，但对于具有多个信道的平面的音频可以容纳在数据，扩展的数据必须被用来对所有频道存取。
uint8_t **extended_data;
视频帧的宽高
int width, height;
由该帧描述的音频样本的数目（每个通道
int nb_samples;
帧格式，－1为未设置或者未知格式
int format;
是否为关键帧，1为关键帧
int key_frame;
帧图片的类型
enum AVPictureType {
AV_PICTURE_TYPE_NONE = 0, ///< Undefined
AV_PICTURE_TYPE_I, ///静止帧 压缩率最低
AV_PICTURE_TYPE_P, ///向前预测帧
AV_PICTURE_TYPE_B, ///双向预测帧
AV_PICTURE_TYPE_S, ///< S(GMC)-VOP MPEG4
AV_PICTURE_TYPE_SI, ///< Switching Intra
AV_PICTURE_TYPE_SP, ///< Switching Predicted
AV_PICTURE_TYPE_BI, ///< BI type
};
enum AVPictureType pict_type;
指向第一次分配的内存
目前已废除
uint8_t *base[AV_NUM_DATA_POINTERS];
Sample aspect ratio for the video frame, 0/1 if unknown/unspecified.
帧的长宽比 0/1为未知/不确定
typedef struct AVRational{
int num; ///< numerator分子
int den; ///< denominator分母
} AVRational;
AVRational sample_aspect_ratio;
基础时间戳(决定何时显示)(做帧同步)
int64_t pts;
解码产生本帧的AVPacket的pts拷贝
int64_t pkt_pts;
返回触发此帧的AVPacket的dts拷贝（帧线程未被使用）
不使用pts值只用AVPacket的dts计算出来的该帧的描述时间
int64_t pkt_dts;
比特流队列中图片序号
int coded_picture_number;
显示队列的图片序号
int display_picture_number;
品质（介于1（最好）和FF_LAMBDA_MAX（坏）之间）
int quality;
QP表
QP表指向一块内存，里面存储的是每个宏块的QP值。宏块的标号是从左往右，一行一行的来的。每个宏块对应1个QP。
qscale_table[0]就是第1行第1列宏块的QP值；qscale_table[1]就是第1行第2列宏块的QP值；qscale_table[2]就是第1行第3列宏块的QP值。以此类推...
宏块的个数用下式计算：
注：宏块大小是16x16的。
每行宏块数：
int mb_stride = pCodecCtx->width/16+1
宏块的总数：
int mb_sum = ((pCodecCtx->height+15)>>4)*(pCodecCtx->width/16+1)
int8_t *qscale_table
uint8_t *mbskip_table：跳过宏块表
int16_t (*motion_val[2])[2]：运动矢量表
运动矢量表存储了一帧视频中的所有运动矢量。
该值的存储方式比较特别：
int16_t (*motion_val[2])[2];
int mv_sample_log2= 4 - motion_subsample_log2;
int mb_width= (width+15)>>4;
int mv_stride= (mb_width << mv_sample_log2) + 1;
motion_val[direction][x + y*mv_stride][0->mv_x, 1->mv_y];
该数据的结构：
1.首先分为两个列表L0和L1
2.每个列表（L0或L1）存储了一系列的MV（每个MV对应一个画面，大小由motion_subsample_log2决定）
3.每个MV分为横坐标和纵坐标（x,y）
注意，在FFMPEG中MV和MB在存储的结构上是没有什么关联的，第1个MV是屏幕上左上角画面的MV（画面的大小取决于motion_subsample_log2），第2个MV是屏幕上第1行第2列的画面的MV，以此类推。因此在一个宏块（16x16）的运动矢量很有可能如下图所示（line代表一行运动矢量的个数）：
//例如8x8划分的运动矢量与宏块的关系：
//-------------------------
//| | |
//|mv[x] |mv[x+1] |
//-------------------------
//| | |
//|mv[x+line]|mv[x+line+1]|
//-------------------------
uint32_t *mb_type：宏块类型表
宏块类型表存储了一帧视频中的所有宏块的类型。其存储方式和QP表差不多。只不过其是uint32类型的，而QP表是uint8类型的。每个宏块对应一个宏块类型变量。
short *dct_coeff：DCT系数，这个没有提取过
int8_t *ref_index[2]：运动估计参考帧列表（貌似H.264这种比较新的标准才会涉及到多参考帧）
int interlaced_frame：是否是隔行扫描
1个运动矢量所能代表的画面大小（用宽或者高表示，单位是像素），注意，这里取了log2。
代码注释中给出以下数据：
4->16x16, 3->8x8, 2-> 4x4, 1-> 2x2
即1个运动矢量代表16x16的画面的时候，该值取4；1个运动矢量代表8x8的画面的时候，该值取3...以此类推
uint8_t motion_subsample_log2：一个宏块中的运动矢量采样个数，取log的
AVFrame结构体一般用于存储原始数据（即非压缩数据，例如对视频来说是YUV，RGB，对音频来说是PCM），此外还包含了一些相关的信息。比如说，解码的时候存储了宏块类型表，QP表，运动矢量表等数据。编码的时候也存储了相关的数据。因此在使用FFMPEG进行码流分析的时候，AVFrame是一个很重要的结构体。
