摘要：本文论述了一款符合AVS-M标准的实时编码器的设计与实现过程，目的是验证AVS-M标准在实时应用环境中的性能表现。为了尽快地取得验证结果，本项目充分利用了网络开源项目的资源优势——以x264（www.videolan.org）为AVS-M编码库设计的基础，以VLC（www.videolan.org）为编码器框架设计的基础。最后对AVS-M与H.264进行了对比测试，主要比较二者编解码后生成的音视频的清晰和连贯程度，取得了“AVS-M在低码率（32～512Kbps）、低分辨率（SQCIF～CIF）的条件下有接近H.264的性能表现”的结果。

    1.引言

    AVS-M是AVS标准的第7部分——一款专门为移动通讯环境而设计的视频编解码标准。本项目的目的是要验证AVS-M在应用环境中的性能表现，借此证明该标准的实用价值，为其在国内的产业化过程作贡献。移动通讯终端具有带宽低，误码率高和计算能力弱等特点，目前主要以MPEG-4SP为视频编解码的标准，今后国际上可能的升级方案有H.264和VC-1等。本项目通过在相同测试环境下对比AVS-M与H.264标准的实际性能表现来证明AVS-M标准的实用价值。为了贴近真实的使用环境，本项目实现的编码器需要实现实时音视频采集、实时编码、实时通过以太网以MPEG2TS流的形式输出码流的功能。

    VLC与x264是两款遵循GPL标准发布的开源软件，其中VLC是一个流媒体平台，支持插件功能；x264是一款H.264编码库，并针对x86平台进行了优化。为了尽快取得验证结果，本项目采用VLC和x264项目为设计的出发点。VLC以插件的形式实现了实时音视频采集，H.264编码，MPEG2TS流复用和以太网输出等功能，恰好契合本项目的总体需求；AVS-M标准起源于于H.264标准，两者结构类似、功能相同，以H.264为基础开发AVS-M标准能加快开发进度，并且采用同一代码树也能更好的比较AVS-M与H.264标准的实际性能差异。为了更符合实际的使用环境，本项目采用AAC+作为音频的编码标准。VLC本身并不支持AAC+的编码功能，而只支持其解码功能，在此采用3GPP工程的26410-700作为AAC+标准的实现，通过插件的方式来实现AAC+音频编码功能。

    VLC不但支持音视频数据的采集、编码、复用和以太网发送功能，而且还支持码流的以太网接收、解复用、解码和播放功能。为了验证编码器的实际编码效果，本项目也采用VLC作为码流的接收端，通过实时观看播放的效果来评判编码器的性能表现。支持AVS-M解码功能的VLC为另一项目的开发成果，在本文不作详细描述。

    2.编码器

    音频和视频编码都是计算密集型的操作，如果要实时编码就需要一个强劲的运算平台，这里采用一台DellPowerEdge2950服务器作用编码器的硬件基础。PowerEdge 2950配置有一颗Intel Xeon 5160 (Woodcrest) 3.0GHz双核CPU、1GB DDR2内存、SATA II 硬盘、内置双Broadcom BCM5708C NetXtreme II GigE千兆以太网控制器，并具有两条PCI-X扩展插槽以扩充外设接口功能。操作系统选用Red Hat Enterprise Linux 4 (32bit)操作系统。

    PowerEdge2950本身不具有音视频采集接口，需要通过相应的采集卡扩展。这里采用一块Osprey230采集卡作为实时音视频采集接口，它采用PCI-X接口形式，支持PAL/NTSC/SECAM视频标准，能实时采集一路标清视频及双声道的音频。以太网输出采用PowerEdge2950内置的千兆以太网接口。编码器的整体框图如下图所示：

    图表1 编码器总体结构框图

    整个编码了流程为：PAL/NTSC/SECAM的视频信号通过Composite或S-Video接口，音频通过双声道音频接口进入Osprey230采集卡；Osprey230由Video4Linux2与OSS驱动程序来驱动，VLC通过这两个接口控制采集卡，实时读取音视频数据，并分别将音视频数据送到AVS-M编码器与AAC+编码器进行编码；编码后生成的码流送到MPEG2 TS 复用器进行复用；复用后的TS流通过以太网接口以UDP单播或组播的方式发送出去。

    2.1.1.编码库

    开发支持AVS-M标准的编码库是本项目的重点，根据AVS-M标准与H.264标准的异同对x264编码库进行修改，修改的原则是在不改变原先H.264编码功能的前提下增加AVS-M编码功能。为了同时支持上述两个标准，在此采用运行时开关的方法使得编码库既支持H.264标准又支持AVS-M标准，并且两者可以动态地切换。如下是在开发过程中涉及的两个标准的不同部分。

    2.1.1.1.NAL层

    AVS-M和H.264类似，码流的基本单元都是NAL，每个NAL可以包含序列头、图像头和条带等多种语法结构。不同之处是H.264中为了避免与起始码混淆，当NAL内部出现0x000001时，要在0x01之前插入一个0x03。所以我们在实现AVS-M时，要把这个插入0x03的模块删除。

    2.1.1.2.条带上层语义

    在AVS-M中，有和H.264相对应的序列参数集和图像参数集。另外AVS-M增加了图像头，这使得每帧图像数据的边界清晰明了，方便了解码器的实现。我们在实现AVS-M时，也要相应地加入图像头的支持。

    2.1.1.3.帧内预测

    在亮度帧内预测中，AVS-M和H.264都有9种模式，但是他们的排列顺序是不相同的，如图1所示。

    在实现过程中，我们使用了一个映射表将两种不同的排列顺序联系起来，使得代码的改动达到了最小。当然我们也要按照标准修改帧内预测的细微差别。

    另外，AVS-M中只有4x4一种帧内预测模式，而H.264还有16x16和8x8两种模式，所以我们要关掉两种不用的模式。在色度方面，AVS-M不用基于“平面”的预测，所以也要把它从X264中去掉。最后还要注意，在帧间预测帧（P帧）中如果出现帧内预测宏块，它的相邻帧间预测块的帧内预测模式的预测值在AVS-M中被定义为不可用（-1），而在H.264中被定义为DC预测模式（2）。

    2.1.1.4.运动向量预测

    在AVS-M中，当前块的运动向量预测是使用它左下角、上方和右上角的运动向量，而H.264是使用左上角、上方和右上角的运动向量，如图2所示。

    另外，运动向量预测值的计算方法也略有不同。

    2.1.1.5.分数像素插值

    在AVS-M和H.264中，半像素精度的样本值都是使用双线性插值的方法，当然它们使用了不同的滤波器。最需要注意的是，在水平和垂直方向都是四分之一精度的样本预测时，AVS-M使用的是“星形”法，而H.264使用的是“菱形”法，如图3所示。

    在AVS-M中，e，g，p和r采用下面公式计算。

    e=(F + j + 1 ) >> 1

    g=(G + j + 1 ) >> 1

    p=(N + j + 1 ) >> 1

    r=(O + j + 1 ) >> 1

    而在H.264中，e，g，p和r采用下面公式计算。

    e=(b + h + 1 ) >> 1

    g=(b + m + 1 ) >> 1

    p=(h + t + 1 ) >> 1

    r=(m + t + 1 ) >> 1

    2.1.1.6.变换和反变换

    AVS-M和H.264使用了类似的整数DCT变换，需要注意的是色度方面。在AVS-M中，色度使用了和亮度相同的变换方法，而H.264中对色度的DC分量又进行了一次变换。

    1.1.2.1量化和反量化

    AVS-M和H.264使用了类似的量化方法，都是使用了查表、乘法和移位，而避免了除法。需要注意的是AVS-M中要对量度量化参数做一次映射来做为色度的量化参数。

    2.1.1.7.变长编码

    AVS-M使用了基于上下文的多阶哥仑布码，而H.264有专门的CAVLC或CABAC编码方式。需要注意的是在AVS-M中对帧内预测增加了一种“直接”模式，即所有4x4块都使用预测模式。所以我们在变长编码时，要先判断“直接”模式是否出现，然后再进行相应的处理。

    2.1.1.8.环路滤波

    AVS-M和H.264中都有环路滤波，这可以显著减少块效应，提高视觉质量。它们的具体实现是不同的，总体来说AVS-M要比H.264简化。

    2.1.1.9.调试

    在调试过程中，我们使用了比较法。就是从编码器端将每帧的预测值和残差存到一个文件中，然后使用标准的解码器进行解码，并在解码的同时比较预测值和残差，然后确定出错的宏块，进行调试。这样通过比较编码器端的重建图像和解码器端的输出图像，从而保证的编码器的正确性。

    2.1.2.优化

    视频编码需要消耗大量的计算资源，如果不针对特殊平台进行优化就很难满足实时编码的要求。本项目采用的硬件平台是Intel的Xeon系列，它具有MMX，SSE，SSE2等加速指令集。x264本身已经针对MMX和SSE指令集进行了优化，鉴于AVS-M与H.264的相似性，针对H.264的优化策略应该多数多能应用于AVS-M标准上。因为在相同的输入下优化和不优化的编码器所产生的码流应该二进制相等，因此在开发过程中采用了在相同输入的前提下，比较不优化与优化两个版本输出的码流是否是二进制相等，以确定的那些优化模块是AVS-M与H.264能共用的。具体比较时采用二分法以加快比较的速度——先屏蔽一半的优化模块，然后比较开启优化模块与关闭优化模块时产生的码流是否相等，如果相等则当前开启的优化模块为AVS-M与H.264能共用的，如果不等则缩小范围继续比较，直道能确定每一个优化模块。经过上述比较之后，最终确定只有四个优化模块二者不能共用，其他的模块两者都能共用，其中两个不能共用的模块可以通过修改C代码解决，另两个需要修改MMX/SSE汇编代码。

    2.1.3.测试

    对音视频的编解码效果的对比分析主要基于两个方面——客观指标和主观感受。当前，已经有不少针对AVS-M与H.264的基于客观指标（PSNR）的对比测试了，本文没有必要再次重复进行这些测试，本文将就二者在实时编码条件下的观众主观感受进行对比测试。测试主要以观众在观看经过实时编码处理后的音视频时是否能感觉到有明显的失真现象为依据。考察分四个方面，即视频的清晰程度和连贯程度及音频的清晰程度和连贯程度，每个方面根据观众的实际感受进行评分，评分的标准如下表所示：

    对比测试的环境设置为视频帧率25，固定码率控制模式、关闭loopfilter功能、GOP为15、H.264采用baseline级；音频采样率为48000、双声道、AACHE编码格式、码率52kbps。测试的结果记录如下表所示（其中四个字母依次代表“视频清晰程度”、“视频连贯程度”、“音频清晰程度”和“音频连贯程度”）

    3.结语

    比较测试的结果数据，可以看出AVS-M在低码率（32～512Kbps）、低分辨率（SQCIF～CIF）的条件下有接近H.264的性能表现，但总体上落后与H.264标准。考虑到移动终端有限的计算能力和AVS-M相对于H.264有计算复杂度上的优势，我们可以确信在未来的移动通信领域AVS-M应该能占有一席之地。（耿文欣编辑）