摘要：H.264/AVC是国际电信联盟ITU-T之视频编码专家组VCEG与国际标准化组织150/IEC之活动图像专家组MPGE联合制定之视频编码新标准，其目之是为了获得更好之图像压缩效果与更好地适应不同之网络环境。但H.264之高效性是建立在其实现之高复杂度基础上之，因此一般之处理平台已经不能满足H.264高计算复杂度之需要。DPS芯片以其超强之处理速度与较低之资源消耗，在很多领域都有非常出色之表现。TI公司生产之C64xx系列芯片具有很强之并行处理能力与信号处理功能，是实现H.264编解码之理想平台。H.264协议之最新草案只给出了一个理想之解码器模型，而把具体之编码器设计留给了工程实现在本文中，选取之 H.264参考代码是JM86。

　　关键词：  视频编解码，H.264，DM642，优化

　　H.264协议之最新草案只给出了一个理想之解码器模型，而把具体之编码器设计留给了工程实现者[1]。实现者需要解决之问题有：运动搜索之算法；宏块之编码模式选择算法；量化参数选择算法等等。此外，由于H.264协议引入了多参考帧以及1/2、1/4象素精度进行运动估计，使得H.264之运算复杂度也相应之提高了很多。因此，要设计一个好之H.264编码器，尤其是满足实时性要求之嵌入式H.264编码器，将会面临许多困难。根据应用需求，正确设计H.264编/解码器，不仅可以提高其压缩性能，而且可以减少需要之JM代码在CCS中之实现如图1所示，包括H.264编码源程序*.c，头文件*.h（在Include目录中）连接命令文件*.cmd，C运行库文件rts6400.lib与cslDM642.lib（在Libraries目录中）。J

　　图 1  JM代码结构框图

　　图1分别是JM代码之结构框图，解码器从输入码流进行格式转换，得到NAL层之码流，然后经过语法分析得到解码控制信息（CAVLC或CABAC）、预测信息（运动信息或预测模式）以及一系列残差系数。残差系数经过重新排序再经过反量化与反变换得到残差数据。如果是帧内预测，帧内预测模块根据预测模式与帧内参考像素创建一个帧内预测块。如果是帧间预测，运动补偿模块根据运动信息（宏块划分模式、参考索引、运动矢量）与参考帧创建一个帧间预测块。将预测块与残差数据求与得到图像块数据，再通过去滤波得到重建图像之解码块。再经过内存与码流之管理，得到输出之YUV视频序列。

　　将JM代码在CCS中实现，需要做之工作有：

　　1、修改程序中不适合CCS环境下面之函数与变量。

　　2、连接命令文件之编写。

　　1修改程序中不适合CCS环境下面之函数与变量

　　视频处理程序通常都需要进行浮点运算，为了能在定点DSP上实现，必须用定点数表示浮点数。我们要实现基于定点DM642之嵌入式之H.264视频编解码程序，就必须考虑DM642之硬件特点与运行环境，所以要把PC Windows操作系统下之JM程序转变成CCS中可编译运行之DSP程序。在实现过程中需要做之工作有：

　　1、DM642没有浮点表示数，只支持定点之计算（乘、加）与四种定点数据类型：char型（8bit），short型（16bit）、int型（32bits）、long型（40bits）。出现浮点运算时，则须改为定点运算。在数据类型方面，CCS也与VC有不同之处。

　　例如：代码typedef __int64 _int64_t;

　　Typedef unsigned__int64 uint64_t;

　　应改为：typedef long int64_t;

　　typedef unsigned int uint64_t;

　　2、需要合理之分配内存空间。DM642之存储容量很有限，只有32兆之内存，不像在PC上进行程序开发，逻辑存储空间可以很大。这项工作会在下文中编写*.cmd文件时遇到。

　　3、JM程序是在VC环境下开发之，包含大量针对VC环境之头文件，其中之库函数调用、头文件引用可能在CCS环境中没有同名函数与头文件，这就会造成编译时大量函数出错，需要在CCS中找到与之功能与属性类似之文件、函数来替代。

　　例如出现代码：#include <sys/timeb.h>时，由于timeb.h文件是VC环境中之头文件，所以，在CCS环境下实现时，应该改为：

　　#ifdef _TMS320C6X

　　#else

　　#include <sys/timeb.h>

　　#endif

　　同理，在遇到代码：

　　#include <malloc.h>

　　#include <memory.h>

　　也应作相应之修改。

　　4、充分利用CCS在C6000之开发环境中增加之库函数。

　　例如CSL （Chip Support Library）库函数，我们会在下面优化之过程中提到。

　　5、CCS只兼容ANSI C代码，所以需要对非标准C部分之代码进行修改，把它们改写成CCS可以兼容之C代码。

　　例如：将代码static const char *funcl_names[]={“qp2bit”，NULL}

　　改为：static const char *funcl_names[2];

　　Funcl_names[0]=“qp2bits”；

　　Funcl_names[0]=NULL;

　　6、在DSP环境中没有可视化界面操作与文件操作，所以必须对这些操作做相应之改写。

　　例如VC中之“Program Arguments”之可视化操作，如图12所示：

　　图 15 VC中Program arguments可视化操作

　　在CCS环境下，则必须写成如下代码：

　　int argc = 3;

　　char *argv[3] = {

　　"lencod",

　　"-d",

　　"D:\\Program_temp\\CCS_proj\\JM86\\bin\\encoder_sp.cfg"

　　};

　　2连接命令文件之编写

　　代码编写完成后，还需编写连接程序*.cmd。在编写连接命令文件（*.cmd）时，要正确地编写。cmd 文件，就必须根据需要具体之存储区用途指定大小，合理配置具体存储区之起始地址与长度。表格2所示是DM642之地址分配空间[22]：

　　CCS之运行支持库包括malloc，calloc与realloc等几个与动态内存分配有关之函数。动态内存是在堆栈里进行分配之，而堆栈之大小可以由链接器命令选项-heap size来设定，-heap size之默认大小是IK words。但由于在程序中要动态分配之存储量超过IK words，所以把-heap size之值设之足够大。否则，程序虽然可以编译通过，但在程序运行时，就会出现“内存无法分配”之错误。

　　cmd文件由3部分组成：

　　1、输入／输出定义：。obj文件：链接器要链接之目标文件；.

　　.lib文件：链接器要链接之库文件；

　　.map文件：链接器生成之交叉索引文件；.

　　.out文件：链接器生成之可执行代码；链接器选项

　　2、MEMORY命令：描述系统实际之硬件资源

　　3、SECTIONS命令：描述“段”如何定位

　　以上各步骤正确完成后，则JM代码可以在该DSP上运行。然后运用profile工具，对代码进行分析，根据分析结果进行优化。

　　3 本文总结

　　本章说明了在CCS3.1开发环境下H.264代码在DM642之实现。主要包括如何修改JM代码以及编写连接程序使其能在TI-DSP上正确运行。

　　主要参考文献

　　[1]ITU，ITU-T Recommendation H.264： Advanced video coding for generic audiovisual services, May 2003。

　　[2]尹勇，欧光军，关荣锋  DSP集成开发环境CCS开发指南  北京  北京航空航天大学出版社  2003  1~97

　　[3]姚庆栋，王兆华，图像编码基础，浙江大学出版社，1993第1版。

　　[4]丁宗豪，多媒体应用之图像压缩及其标准MPEG-1，电视技术，1994年第8期。

　　[5]李幼林，MPEG-2数字技术简介，电声技术1997年第4期。

　　[6]钟玉琢，王琪，贺玉文，基于对象之多媒体数据压缩编码国际标准MPEG-4及其校验模型，科学出版社，2002年1月。

　　[7]钟玉琢，蔡莲红，李树青，多媒体计算机技术基础及应用，高等教育出版社， 2000。

　　[8]王正勇，李永合，MPEG-4与H.263视频编码性能比较[J]，四川大学学报（自然科学版），2001，38（3）。

　　[9]钟玉琢，沈洪，冼伟铨，多媒体计算机技术及其应用，大连理工大学出版社，      2000. 12。

　　[10]毕厚杰，新一代视频压缩编码标准，人民邮电出版社，2005. 5

　　[11]毕厚杰，王珊琪，H. 264：视频压缩编码之新发展，通讯世界网，2003年10月。

　　[12]Chung-Hyo Kim，In-Cheol Park，High Speed Decoding of Context-based Adaptive Binary Arithmetic Codes Using Most Probable Symbol Prediction，IEEE Digital Object Identifier 10，2006，1707-1711