在嵌入式工业设备、消费类娱乐产品和小型计算装置等多媒体应用中，设计实现、系统效率和高质量编解码器方面存在着许多挑战，设计人员需要了解如何选择正确的处理引擎以构建灵活的IP视像系统。本文讨论一种基于数字信号处理器的解决方案，可以降低开发成本，同时保持较高的性能。

许多嵌入式系统面临的设计挑战涉及到如何降低设计成本而又不牺牲性能，一些优秀的处理器如英特尔80200或德州仪器TMS320C6205之类的DSP也存在这样的问题。设计人员需要使用有效针对平台的数据流模型，根据平台选择内部循环优化措施，降低计算的复杂程度。这样才能在性能上得到极大改进，即使是对移动多媒体系统视像验证模型编码器(MoMuSys)这样的开放源代码视频MPEG-4编解码器，也不需要在视像质量方面做出牺牲，另外还可按特定用户的要求定制编解码器性能和质量。

PAL和NTSC电视信号分别为25帧/秒和30帧/秒，因此在一个CIF图像中，编码器每秒必须处理396×30个宏块(macroblock)。在一个帧处理期间，对每个宏块都要从4Y 8×8的块中计算产生最小误差MB的运动矢量，然后全误差MB(即6个模块)通过离散余弦转换(DCT)后再进行量化。此外为保持与解码器同步，编码器要对所有模块进行去量化和逆向DCT，以重新构建完全编解码的视像帧。简单运动编解码器运算次数范围为每秒9,700万次至97.68亿次(表1)。

必须使用半像素运动估计以便从编解码器中得到合适的视像质量。对于估计所需要的MIPS数来讲，在软件中实现全MPEG-4简单类系统是非常困难的，如果要用廉价(低于30美元)的DSP实现MPEG-4编解码器，需大幅降低计算复杂性，这类器件为可用MIPS数设定了一个界限。

将MPEG-4编解码器用于IP视像系统时，还有一些其它的灵活性和处理要求。系统核心功能是将原始视像信号转换到压缩的IP数据包中，最简单的情况是把模拟摄像头的IP数据流传递到PC机上，然后解压并向用户回放出视频影像。

选择正确的处理引擎

目前市面上有几种用于视像压缩的处理器，它可以作为IP视像系统的一部分。这些处理器分成四类，即专用视像处理器(DVP)、多媒体协处理器(MMCP)、专用编解码处理器(DCP)和通用信号处理器(GSP)，每种都有各自的优缺点(表2)。

DVP是在DSP上扩展了专用于视像应用的部分，通常有一个DSP或RISC内核，再加上专用的视像压缩辅助硬件，如松下的视频信号处理器VDSP2和扩展8×8视频通信处理器VCPex。MMCP类似于DVP，但包括声音压缩、图形和其它多媒体扩展功能，如飞利浦的TM32A处理器。DCP指专用硬件，设计用于按MPEG-4之类特定压缩标准进行编解码。最后一种GSP是具有扩展指令集的通用DSP，指令集包括专门用于视像压缩和解压操作的其它功能，如德州仪器的C6xx系列及BSP-15。 DVP和MMCP专门用于视频/多媒体，相应有一个硅片开发成本的问题。由于内部复杂，包含许多压缩辅助协处理单元，所以这些芯片的软件开发费用也相当高。不过它们通常结合了视像采集和转储能力，这样可以去掉额外的外围电路，降低整个IP视像系统的费用。DCP系统能够达到很高的性能，但芯片开发费用高，且编程灵活性很低。

总的来讲，我们相信GSP是所有产品中最灵活的，针对多种应用进行大批量生产，所以价格便宜，而且因为简单，在所有编解码器中开发费用最低。缺点是在IP系统中，依然需要视像采集和转储方面的硬件。

构建灵活的IP视像系统

在我们选择的基于DSP的设计中(图1)，来自摄像头即通过帧采集器得到的数据被送到编解码处理器的SDRAM中。这里我们用的是德州仪器的C6205 DSP，速度为200MHz，每个时钟周期可执行8个32位指令(高达10次运算)。

该处理器用于对帧采集器提供的原始视像数据进行编码，主处理器是时钟为533MHz的Intel 80200，用于执行主要任务，从DSP处理器中取得数据并打包，再经过以太网(使用IP)进行网络发送。不过考虑到实现编解码器所需的MIPS数量，应在早期做出决定划分编解码器，使主处理器完成数据的熵(即VLE)编码。

主处理器也运行Linux内核，它的任务还有配置和控制包括DSP在内的所有外围器件。整个系统在内部通过PCI总线进行通信，之所以用PCI作为嵌入式总线架构是因为其应用历史悠久，公认比较稳定，而且易于使用，如果市场需要更大处理能力而增加额外的外围器件，PCI也很容易扩展。

我们的IP视像系统总体解决方案显示了高度可升级性。主处理器和DSP处理器都在英特尔和德州仪器各自的长期开发产品线上，一些新型更快的设计不久就会推出。因为DSP执行大多数视像压缩任务，所以主处理器还有多余的MIPS可供给与视像无关的特殊用户要求。

此外，该设计在编解码器实现方面也具有很大灵活性，相比于其它常用方案这里的编解码器开发速度非常快，虽然性能上有所欠缺但在简单性方面进行了弥补，即使更廉价的DSP也有能力运行全帧速率及高质量编解码器。它可以满足将来的新标准和更先进的特性，很容易用更高性能的型号来代替，设计更新速度比专用视像处理器快。

GSP还没有强大到足以满足非常高性能要求的地步，如高空间分辨率4CIF、16CIF等，不过我们的硬件在设计时已考虑了以后的扩展，现在考虑的其它方案是使用专用DCP替代编解码器处理器以及转储器和采集器，这些未来方案的目标应用是IP数字视像市场上的高性能终端。

C6205 DSP处理器的内核可以并行执行8条32位指令，并能以200MHz速度在每个周期执行高达10个基本算法操作扩展指令集。具有全并行化特性的内核理论上可以达到1,600MIPS，或2,000MBOPS。但实际上目前任何软件要达到这一点都是极其困难的，根据上面对编解码器复杂性的讨论可以看到，选择这样的处理器将无法执行全帧速率MPEG-4编解码器。

市场的压力即费用上的考虑使我们只能这样选，但即使如此，所要求的性能标准即30帧/秒的高质量视像还是能够达到。DSP内部有64KB程序和数据存储器，两者都能配置成高速缓冲存储器或快速RAM。在我们的平台上，DSP扩展存储器接口(EMIF)连在16MB的SDRAM上。

为测试我们的设计，我们使用移动多媒体系统视像验证模型编码器。这个MPEG-4编码器从来就不是一个高性能编码器，但却是由国际标准化组织(ISO)提供的，作为MPEG-4编解码器开发和质量指导。

编解码器代码首先简化为生成MoMuSys MPEG-4简单类编码器所需的最简值。为了事先对任务有一个概念，先将现在更容易管理的基本代码下载到DSP的SDRAM中并执行，并将内部数据和程序存储器配置成高速缓冲存储器，所产生的帧速率(MPEG-4量化器值为3，没有速率控制)对于内部帧约为0.1帧/秒，这个数字不包括VLE处理(图2)。

VLE之所以不包括在这一测量中是因为我们知道在最终系统中，编解码器这一部分将在80200主处理器中执行，用以平衡总的计算负载。帧间速率没有作估计，不过由于ME/MC是运动编解码器一个重要计算部分，所以该性能会比较差，或许要差一个数量级。

此外，仅用一个内部帧编解码器(负的VLE)也很容易工作，因为该特性与图像无关，使我们能准确测量DSP的性能。在这点上请注意编解码器性能比我们需要的30帧/秒之间相差300倍以上。

在标准PC上的MoMuSys MPEG-4简单类编码器性能要比上面的设计好几个数量级，但DSP技术规范中MIPS部分并不比英特尔奔腾系列处理器差几个数量级，所以很显然，DSP内核的能力还没有完全发挥出来。

带宽制约速度

我们怀疑这主要是由于高速缓冲存储器出现错误而影响到SDRAM的访问速度。虽然除了经过TI编译器优化外，代码没有再对DSP内核进行其它优化，所以可能没有达到最优，但我们还是认为有其它异常因素导致性能降低。后来在检查产生帧值数据的SDRAM和内部数据RAM(IDRAM)之间带宽时才找到原因。

MoMuSys是一个基于帧的编解码器，这表示它以全帧进行每一级编码，与基于宏模块的编解码器不同，它每次都在宏模块上进行全编码过程。

单从这一点就可以看到，仅对帧数据一项编码器就需要大容量SDRAM来处理视像输入帧。此外，DCT和定量器需要12位数据(用于8位/像素的输入图像)，因此所有帧都以16位/像素数据格式存储，这些帧总共要1.45MB数据存储器。

对MoMuSys码的检查显示，处理一个帧需要的存储器大约是2MB，包括1.45MB帧数据、ACDC预测数据和运动矢量数据。当编码器工作于PC5时，存储器使用情况分析显示它需要8M字节存储器用于正常工作。

我们预计每帧存储器用量很可能在2到8MB之间。在正确设计的高速缓冲存储器相关系统中，高速缓冲存储器容量(64KB)和处理1帧所要求的存储器容量(2～8MB)之间存在着巨大差异，但这一差异本身不会给来自SDRAM的高速缓冲存储器线路负载性能造成问题。

不过，存储器访问空间结构被认为是引起高速缓冲存储器高失误率的原因，并因此使性能大大降低。我们在这一级做了深入耗时的高速缓冲存储器分析，试图优化这一类编解码器用于DSP。

对于存储器要求来讲，基于宏块的编解码器更为有效。此外编解码器每处理一帧需要访问大量完全不同的数据，所以设计一个好的带高速缓冲存储器的编解码器是很难的，不管是基于帧还是基于宏块。因此我们后来决定关闭高速缓冲存储器，并用完善的DSP可编程DMA引擎来管理SDRAM和内部数据RAM(IDRAM)间数据传递。所有DSP内核访问仅限于内部数据RAM，SDRAM和IDRAM间的DMA处理将与CPU内核存储器访问并行执行，如果我们在IDRAM上进行旋转式缓冲器排列，可以假定不会有数据库冲突。

同样我们也关闭程序高速缓存操作，另外还做了一些工作保持代码长度小于64K字节，这也给了我们另外一个理由放弃大部分MoMuSys代码。

运动估计/运动补偿算法是一个有效的专用快速运动估计算法，局限在一个16像素搜索范围内，显然与搜索区域大小紧密相配。所有的帧表达现在都用8比特/像素格式，代码如果在DCT和量化时还需更进一步精确，我们将提供额外的存储空间作为IDRAM静态预分配区域。MB以Y1Y3Y2Y4CbCr格式存储，即将Y3和Y2作了交换。让DSP的4个可用DMA通道直接存储器访问全部MB(6个模块)，并仍保持存储器中每个相邻模块像素排列不变，这样做很有必要，它也是TI为DSP提供的必须采用的格式用于DCT库。所有其它程序数据都留在IDRAM内，总计62.4KB，几乎没有什么空间可以备用。较小的IDRAM需要一个稍微不同的数据模型，结果是DMA总线利用更为充分。

这个基于MB的编解码器所用存储器带宽在SDRAM和IDRAM之间，很容易估计，每帧处理需要742KB DMA，5个帧值，这里一帧是352×288×1.5个字节，所以对于每秒30个NTSC帧而言，DMA引擎必须每秒传递大约22M字节的数据，在SDRAM和IDRAM之间的100MHz 32位总线中它将使用大约1/18的带宽。这完全在TI DSP的DMA性能和我们使用的SDRAM界限内，我们的32位可寻址SDRAM时钟为100MHz，每排访问损失的SDRAM时钟小于5个，相当于10个DSP时钟周期。

从这一点可以看到数据模型已按IDRAM的大小作了修改，对DSP访问进行了优化处理，但却没有充分利用DMA。该数据模型在速度性能上的改进如果没有重要配置或优化条件，则相比于以前的结果是非常令人惊讶的。这一级帧内性能为20帧/秒数量级，即在非常需要存储器的MoMuSys帧基编解码器上性能改进了200倍。当加入我们专用的ME/MC子系统时，一般使用一个代码仿形器，可以看到消耗了30～50%的可用时钟周期，这时帧间性能估计最坏为10帧/秒。

技术突破

在设计编解码器中如何获得最好的并行效果是一个很大的挑战，必须保证DSP内核逻辑单元得到最好应用。在多数情况下，这要留给非常强大的DSP优化器来做，但TI的编辑器也包含了用于软件循环流水操作的算法。

编解码器实现一般包含许多围绕像素的循环内容，这些循环又在模块、MB或帧中，所以它们非常适合进行优化，一个循环的流水作业意味着两个或更多循环反复将并行执行。TI编辑器在其流水作业性能上提供反馈以便在过程中提供帮助，如果某些DSP内核逻辑单元利用不足或过度，常常可用再排列或再设计循环来纠正，并减少执行中的循环数。

用上述方法进一步优化，即使用TI仿形器和TI DSP编辑器反馈选件，可以使性能改进高达7倍，达到140帧间/秒的速率。在我们能够发现的最具计算挑战性的图像方面，最优ME/MC结果在帧内处理速率可达31帧/秒。

采用上述方法获得的性能改进非常可观，并显示出在DSP上对编解码器进行编程的原始方法很可能在代码中极少用到DSP的真正性能，好的数据流模型和对DSP内核性能的认识使我们能极大改进性能。

另外还需要做很多工作减少计算的复杂性，因为廉价DSP没有足够的MIPS解决编解码器压缩问题，不过仍有可能在图像质量方面获得更好性能，得到一个速度保持为30帧/秒，且具有CIF分辨率的实时商用级编解码器。