在进行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;

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];
}

其中名称中含有“cache”这一名称的结构体成员都需要当前宏块的周边块的信息，这些信息都是在fill_decode_cache中写入到成员的数组中的，而当前宏块中的信息则是在熵解码后直接或者间接存储到cache结构体成员中。

这些包含cache字段的成员中基本都有DECLARE_ALIGNED修饰，这个宏主要用于向编译器声明这些成员为8或者16byte对齐。原因是为了提升处理速度，这些成员大多需要用SIMD指令进行处理，而SIMD指令在执行时，如果内存操作数不是对齐的，则有可能会出现性能下降。

这些结构体成员被命名为cache也是有原因的。在计算机原理中，当进行内存访问时，为了提高数据访问速度，一般都会对所访问的内存及其周边内存区域（即一个cache line）一同取入cache当中，如果某个代码段会频繁访问数据，并且大部分数据都在cache当中，即cache命中率高，那么这个代码段的执行效率就会得到很好的提升；如果大部分数据不在cache中，即cache命中率低，就会在数据访问上浪费大量时间。一般的处理器的L1 cache仅几十k字节的容量，因此在执行数据处理的时候，如果不是频繁访问的内存区域，有可能很快就会被从cache中清除。基于这些理论，现在返回来观察h264频繁访问的数据，可以发现：

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

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

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

Reference:

update_frame_pool, video_get_buffer
alloc_picture, init_table_pools
fill_decode_cache
write_back_intra_pred_mode
write_back_motion_list
8.3.1.1 Derivation process for Intra4x4PredMode/ Intra Luma Prediction (pred_intra_mode)
8.3.1.2 Intra_4x4 sample prediction / Intra Luma Prediction (hl_decode_mb_predict_luma, pred4x4)
8.4.1 Derivation process for motion vector components and reference indices (DECODE_CABAC_MB_MVD)
8.4.1.2.2 Derivation process for spatial direct luma motion vector and reference index prediction mode (pred_spatial_direct_motion)
8.4.1.3 Derivation process for luma motion vector prediction / h.264 mvp求解过程 (pred_motion)
8.4.2.2 Fractional sample interpolation process (mc_part_std,mc_dir_part)
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)
8.7.2.1 Derivation process for the luma content dependent boundary filtering strength / 估算边界强度 (check_mv, filter_mb_dir)
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)
9.3.3.1.1.7 Derivation process of ctxIdxInc for the syntax elements mvd_l0 and mvd_l1 (DECODE_CABAC_MB_MVD)
9.3.3.1.1.9 Derivation process of ctxIdxInc for the syntax element coded_block_flag (get_cabac_cbf_ctx)
ff_h264_alloc_tables
Intel® 64 and IA-32 Architectures Optimization Reference Manual 4.4 STACK AND DATA ALIGNMENT

TaigaComplex

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

H264Picture

H264SliceContext