基于ADSP-BF561的H.264视频编码器的实现

CAVLC的抗差错能力比较高，但编码效率比CABAC低；而CABAC的编码效率高，但需要的计算量和存储容量更大。

(8)采用新的环路滤波技术及熵编码技术等。

H.264的这些新技术使运动图像压缩技术向前迈进了一大步，它具有优于MPEG-4和H.263的压缩性能，可应用于因特网、数字视频、DVD及电视广播等高性能视频压缩领域。

3 H.264视频编码算法的实现

将H.264在DSP进行改进要经过以下3个步骤：PC机上的C算法优化、从PC机到DSP的程序移植、在DSP平台上的代码优化。

3.1 PC机上的C算法优化

根据系统要求，本设计选择了ITU的Jm8.5版本baseline profile作为标准算法软件。ITU的参考软件JM是基于PC机设计的，故可取得较高的编码效果。将视频编解码软件移植到DSP时，应考虑到DSP系统资源，主要应考虑的因素是系统空间(包括程序空间和数据空间)，所以，需要对原始的C代码进行评估，这就需要对所移植的代码有所了解。图2所示是H.264的算法结构。

了解了算法结构以后，还需要确定在编码算法的实现过程中，运算量较大且耗时较长的部分。VC6自带的profile分析工具显示：帧内与帧间编码部分占用了整体运行时间的60％以上。其中ME(Move Estimation，运动估计)又占用了其中较多的时间。所以，移植与优化的重点应在运动估计部分，因此，应当对代码结构进行调整。

(1)大幅删减不必要的文件和函数

由于选用了baseline和单一参考帧，因此，很多文件和函数都可以删减，包括有关B帧、SI片、SP片和数据分割、分层编码、权值预测模式、CABAC编码模式等不支持特性的冗余程序代码，同时包括rtp.c、sei.c、leaky_bucket.c、In-trafresh.c文件、相关的头文件以及在global.h头文件中相应定义的全局变量和函数，此外，还可以删除top_pic、bottom_pic等与场有关的全局变量与局部变量、分层编码、多slice分割以及FMO、与场编码／帧场自适应编码／宏块自适应编码有关的预测、参考帧排序、输入输出以及解码器缓存操作等；也可以删除随机帧内宏块刷新模式和权值预测模式等相关的冗余代码(如使编码器采用NAL码流而非RTP格式)，同时删除rtp.c；sei.c中包含一些辅助编码信息(并不编入码流中)，如果不用，也可以删除leaky_bucket.c用于计算泄漏缓存器的参数。

(2)配置函数的改写

由于JM的系统参数配置是通过读取encoder.cfg文件来实现的，故可将参数配置由读取文件改为通过初始化集中赋值函数来实现，这样既减少了代码量，又减少了对有限内存空间的占用和读取时间，提高了编码器整体的编码速度。例如：定义为int型的变量input->img_height就可直接改写为input->img_height=288(CIF格式)。

(3)去除冗余的打印信息

为了调试与算法改进的方便，JM保留了大量的打印信息。为了提高编码速度，减少存储空间消耗，这些信息完全可以删掉，如大量的trace信息和编码数据统计文件。如果lor.dat和stat.dat仅需在PC机上调试时使用，也没必要移植到DSP平台上，跟这部分相关的代码完全可以去除。但是，调试时所需的基本信息(如码率、信噪比、编码序列等)则应保留参考。

通过调整可使得代码的结构、容量更加精简，从而为接下来在DSP上的移植做好准备。

3.2从PC机到DSP的程序移植

要将PC端精简的程序移植到ADSP-BF561的开发环境Visual DSP下，以使其能够初步运行，所需考虑的主要是语法规则和内存分配等问题。

(1)除去所有编译环境不支持的函数

主要是除去某些与时间相关的函数、将文件操作修改为读取文件数据缓存的操作、删除SNR信息收集等DSP平台实现不需要的代码。还要注意：函数的声明、数据结构的类型要符合DSP的C语言格式。

(2)添加与硬件相关的代码

该代码包括系统初始化、输出模块代码、中断服务程序和码速率控制程序等。

(3)配置LDF文件
　
因为刚移植的代码往往数据和程序都非常大，SRAM里面肯定是放不下的，这时链接就会有问题。刚开始的时候，最好把所有的程序和数据都放在SDRAM里，这样链接就不会有问题了。Stack和heap情况类似，都先放到SDRAM。一般在开始时，往往需要的是一个可以正确运行的程序，而速度倒在其次。

(4) Malloc问题的解决

　 DSP下的开发，malloc是一个需要解决的问题。如果动态申请内存，就算可以运行，其结果往往也是不对的。所以，最好进行静态分配，可用数组的形式分配。

移植完毕后，即可实现基于ADSP-BF561处理器的H_264编码，此时如果速度达不到实时编码的要求，还可