标签：包含 upd ngui http doxygen and desc 因此 sub
在进行h264解码过程中，有两个最重要的结构体，分别为H264Picture、H264SliceContext。
H264Picture用于维护一帧图像以及与该图像相关的语法元素。其中占用大片内存的结构体成员有以下几个：
typedef struct H264Picture {
AVFrame *f;
int8_t *qscale_table;
int16_t (*motion_val[2])[2];
uint32_t *mb_type;
int8_t *ref_index[2];
} H264Picture;
| Menber/Size[2] | Description |
| f W x H (frame in pixels) x YUV |
维护视频的一帧，主要的存储空间由AVBufferRef提供，存储的是这一帧的像素数据，由于视频中每个像素分有YUV三个分量，因此会有三块大内存，分别存储这三个分量的像素数据[1]。如果视频是以interlaced来进行编码的，则会对一帧分为上下场进行编码，不过在解码的时候这两个场会被合并，由这一成员维护。 |
| qscale_table W x H (frame in MBs) |
记录一帧中所有宏块的QP。每个宏块都有独立的QP，QP值由SPS、PPS、slice以及宏块中的QP相关语法元素计算得来。QP除了用于对残差系数进行逆量化之外还在去块滤波中起到判别真假滤波边界的作用。 |
| motion_val W x H (frame in 4x4 blocks) x 2 x 2 |
记录一帧中所有4x4块的运动向量。4x4块是运动向量作用的最小单位，该表格会记录inter宏块中各个4x4块的运动向量。如果该块在进行编码时采用的是双向预测，那么在解码的时候就会得到前向以及后向共两个运动向量，因此motion_val是个长度为2的数组，分别指向前向以及后向运动向量表，表中的每一项表示一个运动向量。一个运动向量分为x与y两个分量。 |
| mb_type W x H (frame in MBs) |
记录一帧中所有宏块的类型。即每个宏块解码出来的语法元素mb_type。 |
| ref_index W x H (frame in 8x8 blocks) x 2 |
记录一帧中所有8x8块的参考图像索引。8x8块是参考图像作用的最小单位，该表格会记录inter宏块中各个8x8块的参考图像索引。如果该块在编码时采用的是双向预测，那么在解码的时候就会得到前向以及后向共两个参考图像索引，因此ref_index是个长度为2的数组，分别指向前向以及后向参考图像索引表，表中的每一项存储一个索引。 |
h.264解码时，各个slice之间相对来说较为独立，因此对于从一个slice解码出来的各个语法元素，会用一个结构体来进行维护，这个结构体就是H264SliceContext。在对slice解码过程中涉及到的大多数据的存取都是通过该结构体来完成。其中占用较大内存，并且会被频繁使用的语法元素相关的结构体成员有以下几个：
typedef struct H264SliceContext {
int8_t intra4x4_pred_mode_cache[5 * 8];
int8_t(*intra4x4_pred_mode);
DECLARE_ALIGNED(8, uint8_t, non_zero_count_cache)[15 * 8];
DECLARE_ALIGNED(16, int16_t, mv_cache)[2][5 * 8][2];
DECLARE_ALIGNED(8, int8_t, ref_cache)[2][5 * 8];
DECLARE_ALIGNED(16, uint8_t, mvd_cache)[2][5 * 8][2];
uint8_t direct_cache[5 * 8];
///< as a DCT coefficient is int32_t in high depth, we need to reserve twice the space.
DECLARE_ALIGNED(16, int16_t, mb)[16 * 48 * 2];
DECLARE_ALIGNED(16, int16_t, mb_luma_dc)[3][16 * 2];
uint8_t (*mvd_table[2])[2];
}
| Menber | Description |
| intra4x4_pred_mode_cache | 存储当前宏块及其Left，Top方向的每个4x4块的intra4x4预测模式，有如下用途： 1. 对当前宏块进行帧内预测，也就是通过intra4x4预测模式来构建宏块的像素数据[7]。 2. 在进行当前宏块的intra4x4预测模式的预测时，需要根据每一个4x4块其A（左）、B（上）块的intra4x4预测模式来进行当前预测模式的预测[6]。  |
| intra4x4_pred_mode | 存储当前宏块所在的行以及前一行宏块的intra4x4预测模式[17]。但是要注意的是，这里只对每个宏块提供8个intra4x4预测模式的存储位置，而实际所用到的区域只有7个，这7个intra4x4预测模式分别位于当前宏块的最底下一行（Bottom）以及最右边一列（Right）[4]。 当前宏块的这7个intra4x4预测模式将会作为后面所解码的宏块的Left、Top方向的intra4x4预测模式使用，即会用intra4x4_pred_mode来填充intra4x4_pred_mode_cache的Left、Top的位置[3]。  |
| non_zero_count_cache | 存储当前宏块及其Left、Top方向的每个4x4块中非零系数的个数，有YUV三个分量。有如下用途： 1. 在cabac解码语法元素coded_block_flag时，需要当前块的A（左）以及B（上）的非零系数数目来选取上下文索引[16]。 2. 在进行去块滤波时，会根据边界两边的块是否含有非零系数来确定滤波强度[13]。 3. 4x4块non_zero_count的值会根据当前宏块的CBP的值来进行设定，如果一个4x4块没有非零系数，则没有必要进行系数的逆量化逆变换了。  |
| mv_cache | 存储当前宏块及其Left、Top、Top-Right、Top-Left方向的mv。有如下用途： 1. 在进行mv预测时，会根据当前块的A、B、C、D的mv来得到当前块的mvp[10]。 2. 如果当前块是B_Direct，并且采用的是spatial预测，则会根据当前块的A、B、C来确定当前块的ref以及mv[9]。 3. 在进行运动补偿时，需要通过当前块的mv来生成像素数据[11]。 4. 在进行去块滤波时，会根据边界两边的mv的差值来确定滤波强度[13]。  |
| ref_cache | 存储当前宏块及其Left、Top、Top-Right、Top-Left方向的ref。有如下用途： 1. 在进行ref的cabac解码时需要根据其A以及B方块的ref来选取上下文索引值[14]。 2. 在进行mv预测的时候，会根据解码出来的当前块的ref以及A、B、C、D的ref来得到mvp[10]。 3. 在进行运动补偿时，需要通过当前块的ref来生成像素数据[11]。 4. 在进行去块滤波时，会根据边界两边是否为同一个ref，或者是否有同样的参考帧数目来确定滤波强度[13]。 5. 如果当前块是B_Direct，并且采用的是spatial预测，则会根据A、B、C块的ref来确定当前块的ref以及mv[9]。  |
| mvd_cache | 存储当前宏块以及其Left、Top的mvd。有如下用途： 1. 通过当前块的mvd以及预测所得的mvp得到正确的mv[8]。 2. 在进行当前块的mvd的cabac解码时需要根据其A、B块的mvd来选取上下文索引值[15]。  |
| direct_cache | 存储当前宏块的Left、Top的块的sub_mb_type（以8x8块为单位），主要用于判断这些块是否为B_Direct。在进行ref的cabac解码时需要根据当前块的A、B的块是否为B_Direct来选取上下文索引值[14]。 |
| mb | 存储当前宏块的YUV的像素残差的变换系数。在编码的时候宏块像素残差的编码顺序为变换、量化、然后熵编码就能得到码流数据；而在解码时，宏块的码流在经过熵解码后，然后执行逆量化，会得到宏块残差像素的变换系数，这些系数会被存在mb当中，对这些残差系数执行逆变换后，就能得到像素残差。 |
| mb_luma_dc | 存储当前宏块的DC系数。在编码时，如果当前宏块采用的预测模式为intra16x16，那么像素残差在进行4x4的变换后会得到16个DC系数以及15x16个AC系数，在进行量化后，这16个DC系数会排列在一起先进行熵编码，然后熵编码这16x15个AC系数；那么在解码时，如果当前宏块的预测模式为intra16x16，那么在执行熵解码后会得到16个DC系数，这些DC系数会被写入mb_luma_dc当中。在mb_luma_dc当中的这些DC系数在进行逆量化后就会被写入mb，形成16个4x4的像残差系数[12]。 |
| mvd_table | 存储当前宏块所在的行以及前一行宏块的mvd[17]。但是要注意的是，这里只对每个宏块提供8个mvd的存储位置，而实际所用到的区域只有7个，这7个mvd分别位于当前宏块的最底下一行（Bottom）以及最右边一列（Right）[5] 。 当前宏块的这7个mvd将会作为后面所解码的宏块的Left、Top方向的mvd使用，即会用于填充mvd_cache的Left、Top的位置[3]。  |
其中名称中含有“cache”这一名称的结构体成员都需要当前宏块的周边块的信息，这些信息都是在fill_decode_cache中写入到成员的数组中的，而当前宏块中的信息则是在熵解码后直接或者间接存储到cache结构体成员中。
这些包含cache字段的成员中基本都有DECLARE_ALIGNED修饰，这个宏主要用于向编译器声明这些成员为8或者16byte对齐。原因是为了提升处理速度，这些成员大多需要用SIMD指令进行处理，而SIMD指令在执行时，如果内存操作数不是对齐的，则有可能会出现性能下降[18]。
这些结构体成员被命名为cache也是有原因的。在计算机原理中，当进行内存访问时，为了提高数据访问速度，一般都会对所访问的内存及其周边内存区域（即一个cache line）一同取入cache当中，如果某个代码段会频繁访问数据，并且大部分数据都在cache当中，即cache命中率高，那么这个代码段的执行效率就会得到很好的提升；如果大部分数据不在cache中，即cache命中率低，就会在数据访问上浪费大量时间。一般的处理器的L1 cache仅几十k字节的容量，因此在执行数据处理的时候，如果不是频繁访问的内存区域，有可能很快就会被从cache中清除。基于这些理论，现在返回来观察h264频繁访问的数据，可以发现：
为了针对上述问题进行优化，ffmpeg把在进行宏块解码时频繁访问到的数据集中到了H264SliceContext结构体中，并且用名称包含cache字段的成员存储宏块及其周边的数据。如此一来，就使得宏块解码过程中的数据访问的内存范围大大缩小，只有在开头的填充这些成员以及末尾的数据写回的时候才会访问到各个分散的内存块，以此来提升内存的cache命中率。
还有一些未被介绍的缓冲区，指向这些缓冲区的指针是H264Context结构体的成员，主要在ff_h264_alloc_tables中进行内存分配。
Reference:
标签：包含 upd ngui http doxygen and desc 因此 sub
原文地址：https://www.cnblogs.com/TaigaCon/p/10312476.html
