[ffmpeg] h.264解码所用的主要缓冲区介绍

在进行h264解码过程当中，有两个最重要的结构体，分别为H264Picture、H264SliceContext。

 

H264Picture

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的数组，分别指向前向以及后向参考图像索引表，表中的每一项存储一个索引。

 

 

H264SliceContext

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频繁访问的数据，能够发现：

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