开发笔记:[ffmpeg]h.264解码所用的主要缓冲区介绍

在进行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];
/// 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频繁访问的数据，可以发现：

1. 这些以cache命名的结构体成员除了包含当前宏块的数据之外，还包含其周边块的数据，特别是上一行的数据。在实际进行数据的排列的时候，是以宏块行为单位从左到右进行排列的，因此即使宏块在空间位置上是上下相邻，但是在内存中也会间隔较远，很有可能不在同一cache line中。
   
2. 解码一个宏块所需要访问的数据繁多，解码器为每一帧的每种数据都分配了各自的内存块，这些内存块都占用相当大的内存空间，因此不同的数据不可能在同一cache line中。
   
3. 解码一个宏块需要多次访问各个内存块中的不同数据，并且访问的代码段较为分散。由于cache空间有限，如果直接处理内存块内的数据，就有可能会导致cache line被频繁替换，使得在进行数据访问的时候cache命中率较低，从而在数据访问上耗费较多时间。

为了针对上述问题进行优化，ffmpeg把在进行宏块解码时频繁访问到的数据集中到了H264SliceContext结构体中，并且用名称包含cache字段的成员存储宏块及其周边的数据。如此一来，就使得宏块解码过程中的数据访问的内存范围大大缩小，只有在开头的填充这些成员以及末尾的数据写回的时候才会访问到各个分散的内存块，以此来提升内存的cache命中率。

还有一些未被介绍的缓冲区，指向这些缓冲区的指针是H264Context结构体的成员，主要在ff_h264_alloc_tables中进行内存分配。

Reference:

1. update_frame_pool, video_get_buffer
   
2. alloc_picture, init_table_pools
   
3. fill_decode_cache
   
4. write_back_intra_pred_mode
   
5. write_back_motion_list
   
6. 8.3.1.1 Derivation process for Intra4x4PredMode/ Intra Luma Prediction (pred_intra_mode)
   
7. 8.3.1.2 Intra_4x4 sample prediction / Intra Luma Prediction (hl_decode_mb_predict_luma, pred4x4)
   
8. 8.4.1 Derivation process for motion vector components and reference indices (DECODE_CABAC_MB_MVD)
   
9. 8.4.1.2.2 Derivation process for spatial direct luma motion vector and reference index prediction mode (pred_spatial_direct_motion)
   
10. 8.4.1.3 Derivation process for luma motion vector prediction / h.264 mvp求解过程 (pred_motion)
    
11. 8.4.2.2 Fractional sample interpolation process (mc_part_std,mc_dir_part)
    
12. 8.5.2 Specification of transform decoding process for luma samples of Intra_16x16 macroblock prediction
    mode (decode_cabac_luma_residual, hl_decode_mb_predict_luma, h264_luma_dc_dequant_idct)
    
13. 8.7.2.1 Derivation process for the luma content dependent boundary filtering strength / 估算边界强度 (check_mv, filter_mb_dir)
    
14. 9.3.3.1.1.6 Derivation process of ctxIdxInc for the syntax elements ref_idx_l0 and ref_idx_l1 (decode_cabac_mb_ref)
    
15. 9.3.3.1.1.7 Derivation process of ctxIdxInc for the syntax elements mvd_l0 and mvd_l1 (DECODE_CABAC_MB_MVD)
    
16. 9.3.3.1.1.9 Derivation process of ctxIdxInc for the syntax element coded_block_flag (get_cabac_cbf_ctx)
    
17. ff_h264_alloc_tables
    
18. Intel? 64 and IA-32 Architectures Optimization Reference Manual 4.4 STACK AND DATA ALIGNMENT