数字视频产品需求近些年出现猛增。主流应用包括视频通信、视频监控与工业自动化，而最热门的要算娱乐应用，如 dvd、hdtv、卫星电视、标清(sd)或高清 (hd) 机顶盒、数码相机与 hd 摄像机、高端显示器（lcd、等离子显示器、dlp）以及个人摄像机等。这些应用都向高质量的视频编解码算法及其标准提出巨大需求，目前主流压缩标准主要有mpeg2、mpeg4和h.264/avc，而针对这些编解码标准有各种各样的实现方案。本文主要探讨基于ti 的c64系列dsp的视频解码算法标准系统优化过程中需要考虑的若干因素。
ti的c64系列dsp以其强大的处理能力被广泛用于视频处理领域，然而由于大家对c64系列dsp的结构、指令、的理解程度不一样，造成算法实现时的效果有许多的差异。具体体现在实现算法时所使用的cpu的资源上。如实现h.264 mp@d1解码时所占用cpu的资源上，会有所差异，或者是所包含的算法工具子集上，如实现h.264 mp@d1解码时使用cavlc而不使用cabac。造成这些差异，主要原因有如下因素：

1. 算法关键模块的优化
2. 算法系统集成时memory的管理
3. 算法系统集成时的edma的资源分配管理

　　本文从这三方面逐步探讨算法优化集成中需要考虑的若干因素。

算法关键模块的优化

　　一般而言，对于目前主流视频解压缩标准都有类似的很消耗dsp cpu的模块，如h.264/avc、mpeg4、avs等编码中运动矢量搜索很占用资源，而且这些模块在整个系统实现过程中调用相当频繁，因此我们首先找出这些模块，这点ti的ccs提供了工程剖析工具(profile)，可以很快找到整个工程中占用dsp cpu资源最多的模块；然后对这些模块进行优化。
对这些关键算法模块的优化我们分可以分三步进行，如图2所示，先认真分析这部分代码，并进行相应的调整，如尽量减少有判断跳转的代码，特别是for循环中，判断跳转会打断软件流水。使用的方法，可是使用查表或者使用_cmpgtu4、_cmpeq4等intrinsics来代替比较判断指令，从而巧妙替代判断跳转语句。同时使用ti的ccs中所提供的#pragma提供编译器尽量多的信息，这些信息包括for循环的次数信息、数据对齐信息等。如果经过这部分优化无法满足系统要求，则对这部分模块使用线性汇编实现，线性汇编是介于c和汇编之间的一种语言实现形式，可以控制指令的使用，而不必特别关心寄存器、功能单元(s、d、m、l)的分配和使用，使用线性汇编一般会比使用c语言具有更高的执行效率。如果线性汇编还无法满足要求，则使用汇编实现，要编写出高并行、深软件流水的汇编需要经过画相关图，创建时序表(scheduling table)等步骤，由于篇幅所限，这里就不熬述。

表1

　　优化选项：-pm, -o3，基于c64plus内核，c+instrinsics 是指在c中使用instrinsics。
表1是运动搜索中所需要的计算16×16宏块sad值时，不同方式下所消耗的dsp cpu的周期数。由此可见，汇编实现所消耗的cpu的周期数最少，但前提是需要充分了解dsp cpu的结构、指令以及算法模块的结构，从而能够编写出高并行、深软件流水的汇编，否则有可能所写出的汇编还没有线性汇编或者c效率更高。为此一个行之有效的方法是，充分利用ti所提供的算法库中的函数，因为算法库中的函数都是已经充分优化过的算法模块，而且大都提供对对应的c、线性汇编和汇编源代码，并有文档进行api介绍。

算法系统集成时memory的管理

　　由于在基于dsp的嵌入式系统开发中，存储资源特别是片内高速存储资源有限，在算法系统集成时memory的管理对于提高整个系统的优化是非常重要的，这一方面影响数据的读取、搬移速度；另一方面还影响cache的命中率，下面分程序和数据两方面分析。
程序区：最大原则是将经常调度使用的算法模块放片内。为做到这点，ti的ccs中提供了#pragma code_section，可以把需要单独控制存放的函数段从.text段中独立出来，从而在.cmd文件中对这些函数段进行单独物理地址映射。还可以使用程序动态的方式，将需要运行的代码段先调度进片内memory，如h.264/avc中cavlc和cabac两个算法模块具有互斥性，因此可以将这两个算法模块放在片外而且对应于片内同一块运行区，在运行其中某一个算法模块之前，先将其调入片内，从而充分利用片内有限的高速存储区。程序区的管理考虑到一级程序cache(l1 p)的命中率，最好将具有先后执行顺序的函数按地址先后顺序配置在程序空间中，