[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

原文地址:https://www.cnblogs.com/TaigaCon/p/10312476.html

时间: 2024-10-17 10:53:46

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

H.264解码过程剖析-4

x264开源工程实现H.264的视频编码,但没有提供对应的解码器.ffmpeg开源多媒体编解码集合汇集了市面上几乎所有媒体格式的编解码的源代码.其中的H264.c就是一个能正常解码x264编码码流的独立的源文件,其使用步骤也与上述的编码或解码CODEC应用案例基本相同.这一节通过自顶向下的方式,讲述H264.c如何实现H.264视频解码过程. H264.c源文件有几千行,代码量庞大,很不便于浏览.分析和移植.同时该文件还依赖其他源文件,组织结构较复杂,实现平台由于不是基于Windows的VC++

FFmpeg的H.264解码器源代码简单分析:熵解码(Entropy Decoding)部分

本文分析FFmpeg的H.264解码器的熵解码(Entropy Decoding)部分的源代码.FFmpeg的H.264解码器调用decode_slice()函数完成了解码工作.这些解码工作可以大体上分为3个步骤:熵解码,宏块解码以及环路滤波.本文分析这3个步骤中的第1个步骤. 函数调用关系图 熵解码(Entropy Decoding)部分的源代码在整个H.264解码器中的位置如下图所示. 单击查看更清晰的图片 熵解码(Entropy Decoding)部分的源代码的调用关系如下图所示. 单击查

FFmpeg的H.264解码器源代码简单分析:宏块解码(Decode)部分-帧内宏块(Intra)

本文分析FFmpeg的H.264解码器的宏块解码(Decode)部分的源代码.FFmpeg的H.264解码器调用decode_slice()函数完成了解码工作.这些解码工作可以大体上分为3个步骤:熵解码,宏块解码以及环路滤波.本文分析这3个步骤中的第2个步骤.由于宏块解码部分的内容比较多,因此将本部分内容拆分成两篇文章:一篇文章记录帧内预测宏块(Intra)的宏块解码,另一篇文章记录帧间预测宏块(Inter)的宏块解码. 函数调用关系图 宏块解码(Decode)部分的源代码在整个H.264解码器

H.264视频在android手机端的解码与播放(转)

随着无线网络和智能手机的发展,智能手机与人们日常生活联系越来越紧密,娱乐.商务应用.金融应用.交通出行各种功能的软件大批涌现,使得人们的生活丰富多彩.快捷便利,也让它成为人们生活中不可取代的一部分.其中,多媒体由于其直观性和实时性,应用范围越来越广,视频的解码与播放也就成为研究的热点. H.264标准技术日渐成熟,采用了统一的VLC符号编码,高精度.多模式的位移估计,基于4×4块的整数变换.分层的编码语法等.这些措施使得H.264算法具有很高的编码效率,在相同的重建图像质量下,能够比H.263节

h.264并行解码算法分析

并行算法类型可以分为两类 Function-level Decomposition,按照功能模块进行并行 Data-level Decomposition,按照数据划分进行并行 Function-level Decomposition 在h.264解码时进行功能划分,例如对于四核系统,各个核心分别执行下列任务 熵解码framen 逆量化.逆变换framen-1 预测处理framen-2 去块滤波framen-3 这种并行类型就是流水线类型,但这种类型在h.264解码中会出现以下问题 各个功能部分

FFmpeg的H.264解码器源代码简单分析:环路滤波(Loop Filter)部分

本文分析FFmpeg的H.264解码器的环路滤波(Loop Filter)部分.FFmpeg的H.264解码器调用decode_slice()函数完成了解码工作.这些解码工作可以大体上分为3个步骤:熵解码,宏块解码以及环路滤波.本文分析这3个步骤中的第3个步骤. 函数调用关系图 环路滤波(Loop Filter)部分的源代码在整个H.264解码器中的位置如下图所示. 单击查看更清晰的图片 环路滤波(Loop Filter)部分的源代码的调用关系如下图所示. 单击查看更清晰的图片 环路滤波主要用于

FFmpeg的H.264解码器源代码简单分析:解码器主干部分

本文分析FFmpeg的H.264解码器的主干部分."主干部分"是相对于"熵解码"."宏块解码"."环路滤波"这些细节部分而言的.它包含了H.264解码器直到decode_slice()前面的函数调用关系(decode_slice()后面就是H.264解码器的细节部分,主要包含了"熵解码"."宏块解码"."环路滤波"3个部分). 函数调用关系图 解码器主干部分的源代码在

FFmpeg源代码结构图 - 解码

版权声明:本文为博主原创文章,未经博主允许不得转载. 目录(?)[+] ===================================================== FFmpeg的库函数源代码分析文章列表: [架构图] FFmpeg源代码结构图 - 解码 FFmpeg源代码结构图 - 编码 [通用] FFmpeg 源代码简单分析:av_register_all() FFmpeg 源代码简单分析:avcodec_register_all() FFmpeg 源代码简单分析:内存的分配和

H.264开源解码器评测

转自:http://wmnmtm.blog.163.com/blog/static/38245714201142883032575/ 要播放HDTV,就首先要正确地解开封装,然后进行视频音频解码.所以我们需要分离器,视频解码器和音频解码器,俗称hdtv的“三件套”,又统称滤镜. H264的分离器: 常见的有Gabest MP4分离器,就是MP4splitter,也是Gabest编写的,Halli的分离器和NDigital分离器等. H264的视频解码器: CoreAVC的H264视频解码器Cor