国际主流视频编码标准优化代码的对比测试

1、国际主流视频编码标准优化代码的对比测试王中元（ 1972- ），男，湖北英山人，讲师，博士，主要研 究方向为视频编 / 解码、多媒体通信；朱福喜（ 1957- ），男，湖北新洲人，教授，博导，博士， 主要研究方向为人工智能等 .（武汉大学 a. 计算机学院 ; b. 国家多媒体软件工程技术研 究中心 ; c. 档案馆， 武汉 430072）以 H.263、MPEG-4、 H.264 三种标准作为测试对象，在 Win/Intel 平台上测试了优化后编码器的计算效率、编码效率和 码率控制精度， 并对测试结果进行了比较和分析。 测试数据为开 发人员在一定硬件性价比的约束条件下实现视频编码器提供了Te

2、st?Band?Bcomparison?Bon?Boptimized?Bcode?Bof?Bmajor?B international?Bvideo?Bcoding?BstandardsLI Naa,c, WANG Zhong-yuanb, ZHU Fu-xia(a.School of Computer, b.National MultimediaSoftware Engineering Research Center, c.Archives, WuhanUniversity, Wuhan 430072, China)This paper selected H.263,MPEG-4 and H

3、.264 video coding standards as test object to measure such performance index as compression efficiency,calculation efficiency and rate control accuracy on Win/Intel platform. And illustrated the-analysis and comparison on experiment results too. These test datum could be served as a reference guide

4、for designer who would develop video coding application with the constraint on hardware performance and price ratio.几乎在每一种视频标准的制定过程中或者发布后， 都有专家 将该标准与它前期的同类标准作压缩效率和计算复杂度的客观 比较测试 1 。这些测试数据尽管有它一定的学术意义，但是对 实际开发的指导价值非常有限。 其原因有两点： a) 测试过程往往 涵盖了编码工具的全集， 而在实际应用中不太可能启用所有编码 选项，因此，这样测试的压缩效率数据已经背离了实际应用条件； b) 在计

5、算复杂度的对比测试中， 一般均使用伴随标准发布的参考 源码，而这些源码仅仅是用来验证算法的， 它充其量也只是对算 法的一种数学描述。在标准的实现过程中，免不了要对编/ 解码器(CODE)展开算法优化和代码优化，这些优化往往又要结合 目标处理器特定的硬件体系结构实施， 优化过程得到的计算效率 的增益不仅与具体开发平台和开发人员的经验有关， 而且与标准 本身的设计细节所决定的优化潜力相关。 因此，原始参考代码的 计算量差距并不一定能反映最终设计出来的编 / 解码器的计算开 销的差别， 有经验的技术人员实现的 H.264 可能比没有经验的人 员设计的 H.263 的运算效率还要高。 如果对经过了如下

6、两方面优 化处理的视频编 / 解码器进行压缩效率和计算复杂度的客观测试 比较，那么其测试结果对实际应用开发的指导意义是不言而喻 的，这也正是本文的初衷。a）从实现代价的角度对编码选项予以折中取舍；b）算法经过高度的计算效率优化。考虑到 H.2632 、 MPEG-43、 H.2644 在当前压缩视频通 信中应用最为广泛，笔者选取这三种标准作为测试对象。其中 H.263 又进一步划分为不带任何高级选项的基本 H.263 和带 Annex D（unrestrictedmotion vector mode）、Annex F（advancedprediction mode ）两个高级选项的 H.263

7、 来分开测试。此外， 由于码率控制对实时视频通信至关重要， 对这几种标准的验证模 型中提出的码率控制算法的精度也同时予以测试。1测试CODEC勺代码选择和优化首先需要说明的是， 由于视频编码标准制定的开放性， 也就 是它们往往只定义语法、 语义和解码的算法， 而不定义编码算法， 从一般厂家实现标准的角度讲，仅仅根据标准的文本来设计CODE（是很困难的。制定标准的专家组也注意到这个问题，所以 他们往往会伴随标准发布一套参考实现算法， 通常称为参考模型 （RM，或者验证模型（VM），或者测试模型（TM。在这些参 考模型中， 专家们会提出一套相对优良的编码算法实现细节供参 考，并提供这些算法细节的实

8、现源码，也就是参考代码。标准本 身和参考模型相得益彰， 既为厂家使用标准提供了便利， 又不影 响厂家个性技术的发挥。 常见国际视频编码标准的参考模型和参 考代码见表 1。1.1H.263笔者选取的原始 H.263 源码版本来自 Telenor R & D 组织， 由 Karl Lillevold和 Robert Danielsen 编写 5 。该源码根据H.263v1标准2和TMN86测试模型设计，用 ANSI C编写，未 经过任何优化处理， 也没有码率控制模块， 因此它不能直接应用 于实际产品中。 在这个参考源码的基础上， 笔者经过多方面计算 效率的优化设计和码率控制功能的添加， 将它应用到

9、自主研发的 H.323/SIP 视频会议系统中。具体采用的优化技术不在此赘述， 笔者另文发表 7,8 。1.2MPEG-4MPEG-4存在 DIVX、 XVID、FFMPEG MoMuSys Microsoft 等多个开源版本，其中尤以 XVID最出名9。如同H.263，这些 开源代码的设计依据与其说是MPEG-4准文本，不如说是MPEG-4勺验证模型 VM810。XVID针对Intel/AMD 平台展开了 全面的指令优化，计算密集的模块全部用ASM/MMX/XMM/SSE/SSE2/3DNOW/3DNOWEXT等几种汇编指令 改写，因而运算效率极高。特别是采用了最新的 PMVFAST (pr

10、edictive motion vector field adaptive searchtechnique )运动估计算法 11 ，使运动矢量搜索的精度和效率 大大提高。 XVID 优良的编码效率和计算效率使它完全达到商用 的程度，厂家在Intel/AMD平台设计MPEG-4产品时，完全可以 放心大胆地直接嵌入 XVID CODEC事实也是如此。即使是对其 他平台如DSP XVID优良的代码设计风格和程序结构也是极好的 代码移植模板。例如笔者在 Trimedia 平台开发网络摄像机和可 视电话等产品时，就是根据 XIVD 移植的。略显不足的是， XVID 中的码率控制算法过于简单， 它仅仅根据

11、缓冲区的填充程度来适 配量化步长，完全没有考虑视频序列自身的复杂度。为此，笔者 对这一点进行了改进，用 TMN86或者SRC(scalable rate control )12码率控制算法替换了 XVID中原有的码率控制模 块。TMN眇宏块为单位来控制码率，所以控制得非常精确，这 主要是为MPEG-4的车载无线视频传输设备定制的。SRC既可以根据当前视频帧的复杂度和当前缓冲区的充满程度为帧内所有 宏块计算出一个统一的量化步长，也就是帧级QP自适应控制；也能够依据宏块复杂度的变化， 为每一个宏块都计算出一个属于 它自己的量化步长，这就是宏块级 QP自适应控制；当然，介于 两者之间，还可以在视频包

12、(video packet )级控制QP由于 SRC宏块级控制起到的作用与 TMN8重复，更主要的是，它在宏 块级控制时将所有宏块比特数开销都算在DCT系数上，而没有考虑宏块头参数的编码开销，其控制精度没有TMN8高。但是，SRC的帧级QP自适应无论是从计算复杂度还是从控制精度来说，都是对TMN8-个比较好的折中，将它用于码率控制要求不是很严 的场合还是一个不错的选择。 在本文中， 为了同时对几种有代表 性的码率控制算法进行一次对比测试，MPEG-砾用SRO帧级QP码率控制算法。1.3H.264H.264也存在JM X264和FFMPEG几种开源代码。其中，JM序列编/解码器（现在版本已经发展

13、到 JM11）是学术研究中用 得最多的代码， 它完整地实现了 H.264 的全集， 甚至连信道鲁棒 性的宏块编码模式 RDO这种目前还只停留在学术研究阶段，尚无法实际应用的技术也体现在代码中15。显然，JM代码只是实 现了对 H.264 标准严格的算法描述， 没有任何优化的成分， 因此， 基于JM来开发实际产品需要付出的优化工作量很大。值得庆幸 的是， X264 encoder16 这个开源的 H.264 编码器提供了类似 XVID那样近乎完美的指令优化版本，它对计算密集的模块几乎 全部用 Intel/AMD 汇编指令改写。 所以， 仅仅依靠 X264 encoder 本身的代码优化工作， 基

14、本上就可以将它集成到实际产品中应用 起来。笔者通过对 X264代码的深入分析发现，它实现的编码选 项与JM相比几乎没有作太多删减，如 CAVLC/CABACB帧、帧场 自适应编码、QPEL运动补偿、全部的INTRA模式预测、全部的 INTER模式预测、ABT deblocking loopfilter 、RDO等关乎编 码效率的编码工具它都支持。与原始的JM代码比较，X264仅仅简化了几个技术要素： 不支持 SP/SI 帧；不支持信道自适应的编码模式判决（CA-RDO ;不支持FMO ASO RS等差错弹性工具； 参考帧个数限制在 1 帧； Slice 划分模式仅保留固定宏块个数一 种，去掉了

15、固定比特数划分模式； 码率控制模块不是采用 JVT 推 荐的G012或F086,而是取自FFMPE工程中的相应模块。但是， X264只有编码器没有解码器，高效的H.264 decoder可以在FFMPE开源工程中找到17。笔者测试发现，FFMPE（中的H.264 decoder 不仅运算效率高，而且支持带任何编码选项的 H.264 码 流的解码，如 CAVLC/CABACB帧、多参考帧、FMO帧场自适应 等，更为难得的是它还包含了差错掩盖后处理算法。笔者在向研制的 H.323/SIP 视频会议系统中增加 H.264 能力 时，选取的就是 X264 encoder 和 FFMPE的 H.264

16、decoder。 在开发过程中对 decoder 几乎没有作太多修改，但对 X264 encoder 进行了如下方面的改造：a）改造码率控制模块。尽管 X264中的ABR码率控制模块控 制得还是相对比较精确， 但它解决“蛋鸡悖论”的方法是： 在正 式的运动估计之前先将图像缩小到原始图像的 1/4 ，然后对这个 1/4 图像作一次粗糙的运动矢量预估计，用这个预估步骤得到的 MAD去指导码率控制计算。显然，这个方法既费时又消耗存储空 间，笔者用G012技术替换掉了 ABR由于G012技术通过MAD预 测模型解决了 RDO和码率控制的矛盾，节省了 ABR对资源的额外 开销。同时，在宏块层次实现 G0

17、12码率控制，其控制精度也有 所提高。b）改造Slice划分方法。X264保留的是JM中固定宏块个数 的 Slice 分片方法。 显然，这种方法得到的 Slice 字节数是变化 的，而且几乎不可能做到选取一种宏块个数门限能够将 Slice 中 的字节数控制在 MTI范围内。一旦Slice大小超过MTI范围，按 照RFC3984W议要求18，必须采用分段模式（segmentation） 完成其对应NAL的RTP打包。但是，H.241协议规范了 H.264在 H.323 系统中的打包模式只能是 single NAL 模式 19 ，不允许 分段或合并。所以必须确保Slice分片大小控制在MTI内，这

18、只 能采取固定比特数分片方式才能做到。 需要注意的是， 分片方式 的改动也要带来代码中其他位置的改动，如亮度16X 16 INTRA预测、色差8X 8 INTRA预测，否则编码器和解码器在 DC预测方 向上就不能形成闭环， 导致预测错误， 解码图像出现变色或块斑。2 测试方法2.1测试CODE编码选项配置编码效率和计算效率与CODEC己置的编码选项密切相关，所 以，必须明确测试数据所依托的编码器配置。 测试CODECS置见 表 2。2.2 测试环境测试序列：CIF分辨率，YUV420色度空间格式；ITU-T视 频测试序列： Foreman （300帧） ， Paris （1 065 帧）， M

19、other_daughter （ 300 帧）， New（s 150 帧）。目标码率 384 kbps， 目标帧率25 fps。测试环境：HPNX9040笔记本电脑，CPUnetl 迅驰1.5 GHz内存512 MB硬盘40 GB操作系统 Windows XP。2.3 测试指标和方法1 )计算效率以每秒钟编码的帧数来衡量 也即 f=N/T 。其中 : f表示处理的帧率速度,单位是 fps ; N为处理的帧数；T为处理 完N帧所消耗的时间，单位为s。在编码时间T的计算上，笔者 作了两点处理： a) 为统计净编码时间， 去掉读取文件序列和写压 缩码流的干扰，只统计开始编码一帧到一帧编码完毕所占的时

20、 间，然后将它们累加；b) 由于 ANSI C 中 clock() 函数计算时间的精度只能达到2030 ms，而H.263或MPEG-4编码一帧的时间 远小于这个数值， 有必要采用更高计时精度的计时器。 笔者调用 的是 Windows系统函数：QueryPerformanceFrequency()、 QueryPerforma nceCou nter()。该计时器可以达到 ms精度。2) 编码效率也即压缩效率。 如果各个编码器实际输出的码率 都相同，那么PSNR直越大，编码效率就越高。然而实际上由于 码率控制精度的差异， 即使是目标码率都设置成一样， 实际输出 码率会有所不同，这时必须综合考虑

21、PSNR直和实际码率的结果， 至于如何将它们折算成一个惟一的指标数据则是比较困难的。3) 码率控制一般来说实际输出码率与目标码率越接近，则码率控制的精度越高，但实际码率往往是一个较长时统计的结果， 尚不能完全反映出单帧码率控制的均匀性。 所以， 还有必要计算 每帧产生比特数的方差，方差越小，反映出码率控制越平滑，瞬 时抖动越小。实验中笔者发现如下计算指标更能说明问题：其中：N为编码的帧数；Bi为每帧编码实际产生的字节数； 为每帧目标期望字节数，计算为 二R (8F)。R为目标码率，单 位是 bps； F 为目标帧率，单位是 fps 。3测试结果和分析按照上文方法对 Foreman、Paris

22、、Mother_daughter 、News 四个视频序列展开测试，并将测试结果列于表3。笔者从实验数据中可以发现一些基本事实， 并予以分析：a) PSNF指标。H.263 DF 较 H.263Base 最大相差 0.7 dB ；H.264较H.263Base约高1 dB,最大可相差2.7 dB，且H.264码 率低于 H.263 甚多；MPEG-4SP略高于 H.263 DF,在 0.20.6 dB。b) 计算复杂度。H.264 是 H.263Base 的 5、6 倍；H.263 DF 是 H.263Base 的 2 倍左右；MPEG-4 SP与 H.263 DF 基本相当， 略快一点，主要

23、是尽管都有INTER4V运动估计，但是前者无OBMC 计算。c) 码率控制的精度依次是 TMN8 G012 SRC TMN8 G012 高于SRCm好理解，因为前两者是基于宏块控制的，而 XVID中 的SRC笔者只实现到帧级控制。 至于TMN8高于G012的原因，笔 者认为是受两个方面因素的影响：(a)TMN8在H.263中的MAD参 数是运动估计的直接输出，而 G012用于X264时，MAC由线性模 型预测得到，预测值与实际值间不可避免地存在偏差； (b)TMN8是用宏块头参数占的实际比特数来更新控制模型的，而G012中的宏块头参数编码比特数是通过对前面已经编码的宏块估计得 到，再从宏块的平均比特数中减去估计的头开销， 余下的比特作 为系数编码的期望