基于OMAP3的视频解码器的通用解码方案_技术

　　本文以OMAP3530为例，分析了0MAP平台的硬件结构与软件编程特点;总结了TI公司提供的专用图像图形处理库(IMGLIB)的使用技巧，并与OMAPl510进行了部分比较;在流行的视频编解码标准的基础上，提出了基于OMAP3的视频解码器的通用解码方案。

　　1 OMAP平台简介

　　开放式多媒体应用平台OMAP结合高性能、低功耗的DSP核与控制性能强大的ARM内核，是一种开放式的、可编程的体系结构，目前主要有OMAP1X、OMAP2X和OMAP3X系列。以OMAP3530为例，硬件结构如图1所示。

　　1.1 OMAP3530的硬件平台

　　0MAP3530的硬件平台主要由ARM内核、DSP内核以及流量控制器(Traffic Controler，TC)组成。

　　(1)ARM内核

　　OMAP3530采用ARM Cortex-A8核，工作主频最高可达720 MHz。它包括存储器管理单元、16 KB的高速指令缓冲存储器、16 KB的数据高速缓冲存储器和256K字的二级Cache;片内有64 KB的内部SRAM，为液晶显示等应用提供了大量的数据和代码存储空间。CortexA8内核采用13级流水线、32位的RISC处理器架构。系统中的控制寄存器对MMU、Cache和读写缓存控制器进行存取 *** 作。ARM内核具有整个系统的控制权，可以设置DSP、TC以及各种外设的时钟及其他工作参数，控制DSP的运行停止。OMAP3530平台可支持包含绘图、多媒体内容和Java程序的先进应用。

　　(2)DSP内核

　　TMS320C64X+内核具有最佳的功耗性能比，工作主频最高为520 MHz;它具有高度的并行能力，32位读写和功能强大的EMIF，双流水线的独立 *** 作以及双MAC的运算能力。它采用3项关键的革新技术：增大的空闲省电区域、变长指令和扩大的并行机制。其结构针对多媒体应用高度优化，适合低功耗的实时语音图像处理。另外，TMS320C64X+内核增加了固化了算法的硬件加速，来处理运动估计、8×8的DCT/IDCT和1/2像素插值，降低了视频处理的功耗。

　　(3)流量控制器

　　流量控制器TC用于控制ARM、DSP、DMA以及本地总线对OMAP3530内所有存储器(包括SRAM，SDRAM、Flash和ROM等)的访问。

　　OMAP3530具有丰富的外围接口，如液晶控制器、存储器接口、摄像机接口、空中接口、蓝牙接口、通用异步收发器、I2C主机接口、脉宽音频发生器、串行接口、主客户机USB口、安全数字多媒体卡控制器接口、键盘接口等。这些丰富的外围接口使应用OMAP的系统具有更大的灵活性和可扩展性。

　　1.2 OMAP3530的软件平台

　　利用OMAP可以建立两个 *** 作系统：基于ARM的 *** 作系统(如WinCE、Linux等)，以及基于DSP的DSP/BIOS。连接两个 *** 作系统使用的核心技术是DSP/BIOS桥。0MAP支持多种实时多任务 *** 作系统在ARM微处理器上工作，用来对ARM微处理器进行实时多任务调度管理，对TMS320C64X+进行控制和通信;同时，支持多种实时多任务 *** 作系统在TMS320C64X+上工作，实现复杂的多媒体信号处理。DSP/BIOS桥包含DSP管理器、DSP管理服务器、DSP和外围接口链接驱动器。DSP/BIOS桥提供运行在Cortex-A8上的应用程序和运行TMS320C64X+上的算法之间的通信管理服务。开发者可以利用DSP/BIOS桥中的应用编程接口控制在DSP中实时任务的执行，并同DSP交换任务运行结果和状态消息。在这个环境下，开发者可以调用局部DSP网关组件来实现诸如视频、音频和语音等功能。因此，开发者不需要了解DSP和DSP/BIOS桥，就能开发新的应用软件。使用标准应用编程接口开发的应用软件，与基于0MAP的未来无线设备兼容。

　　2 视频编码标准与OMAP图形图像库应用

　　2.1 视频编码标准

　　从1988年开始，ISO/IEC MPEG和ITU-T针对不同的应用制订了一系列视频编码国际标准。MPEG的有MPEG-1、MPEG-2、MPEG-4标准，ITU-T的有H.261、H.263、H_263+/H.263++以及H.264标准。2001年12月，ISO和ITU-T正式成立联合视频小组(Joint Video Team，JVT)共同制定新的H.264编码标准。2002年6月，我国信息产业部制订了我国的数字音视频编码技术标准(Audio-Video Coding Standard，AVS)。AVS是我国具备自主知识产权的第二代信源编码标准。与目前比较流行的标准(如MPEG-2、MPEG-4、H.263、H.264)相比，从编码效率来看，MPEG-4是MPEG-2的1.4倍，AVS和H.264都是MPEG-2的2倍以上;从算法复杂度上来看，H.264的算法在编码端比MPEG-2复杂4～5倍，在解码端复杂2～3倍，而AVS在复杂度上比H.264有较大幅度降低，且不需要交纳高昂的专利费用。

　　目前，应用比较广泛的视频编码标准中，基本上都有如下的步骤：将图像序列编码为帧内模式和帧问模式两种，并且分别进行编码。采用帧内编码时，直接对8×8的像素块进行DCT变换，然后将量化系数进行变长编码后形成输出码流;另一路经反量化、反DCT变换后形成恢复图像，直接存入帧存储器。采用帧间编码时，对原始数据的每个块先进行运动估计，并与经运动估计后的预测图像相减，产生差分图像，接着进行DCT变换和量化，并同运动矢量数据一起编码形成码流;另一路经反量化、反DCT变换后形成恢复图像，存入帧存储器，用于下一步的运动估计。

　　不同的标准具有各自的特点，例如MPEGl与H.261采用整像素，MPEG4和H.263采用半像素，H.264与AVS采用1/4至1/8像素精度的运动估计，H.261采用单参考帧，H.264与AVS采用多参考帧等。特别是目前的H.264标准，采用整数DCT/IDCT、帧内预测、多模式运动估计、去块效应滤波器等先进技术，造成了极大的算法复杂度，对硬件实时解码提供了很高的要求。

　　2.2 OMAP图形图像库(IMGLIB)应用

　　针对图像与视频处理的需要，TI提供了IMGLIB库供C程序调用。库里内容主要有2部分：

　　①硬件加速部分。由汇编语言编写，但是计算由硬件的加速模块来实现，无法修改。例如DCT/IDCT都是针对8×8块进行的，变换矩阵已经固定，硬件加速指令共有16种，其中DCT/IDCT各1条，运动估计指令10条，插值指令4条。

　　②软件加速部分。用汇编语言编写，包括矩阵量化反量化、JPEG变长编码、一维/二维离散小波变换反变换及小波包变换反变换，以及图像的直方图计算、边缘检测、带移位 *** 作的3×3掩模 *** 作等。这些软件加速指令都提供了标准的C接口，用户可以直接调用，也可以模仿编写规则编译生成自己的库文件。

　　在视频编解码过程中，运动估计、DCT/IDCT和像素插值占据了大量的运算时间，0MAP平台提供的硬件加速单元可以高效地完成上述运算，而几乎不占用CPU时钟(这里，不占用是指运算过程，实际上数据的输入输出仍需要花费少量时间);同时，优化的软件加速单元也可以较快地完成运算。以DCT/IDCT为例，耗时情况如表1所列。

　　由表1可知，硬件DCT耗时约为软件DCT的1/7，硬件IDCT耗时约为软件IDCT的1/4.5。因此，采用硬件加速模块可以极大地提高运算速度并降低功耗。

　　对于最新的H.264以及AVS标准，需要采用OMAP3530才能发挥0MAP系列的硬件加速优势。OMAP3530的硬件加速集成了加速模块的半像素插值，采用的整数DCT/IDCT类变换硬件加速模块，而且集成了去块效应滤波器。在通用计算机上，H.264的解码过程中各部分所需的时间如表2所列。

　　从表2中可以看出，在H.264的解码过程中，环路滤波、插值以及反变换反量化占据了超过70%的计算时间。因此，用0MAP3530来进行H.264以及AVS的解码时，如果能有效地利用0MAP3530的硬件加速资源，可以提高计算效率，实现实时解码。另外，除了硬件加速之外，0MAP3530的体系结构比较适合于视频处理，这主要基于以下考虑：

　　①目前市场上推出的整合了ARM与DSP的多媒体专用芯片并不多，OMAP可以使用单一芯片实现嵌入式 *** 作系统(Linux、WinCE等)的功能，并且可以获得TI广大的第三方提供的丰富的算法支持。基于 *** 作系统的编程更灵活方便，便于产品的软件升级。相比之下，单一的DSP无法实现 *** 作系统的功能，若额外采用ARM构建 *** 作系统，成本以及硬件软件复杂度无疑会大于采用OMAP平台。

　　②功耗的考虑。表3列出了OMAPl510上运行MPEG4解码时的功耗情况。

　　可以看出，在OMAPl510平台上，对于QCIF(常用的标准化图像格式)、15 fps的应用来说，功耗在9.9～28.5mW。对于常见的650 mAh时的手机电池，大概可以连续工作34～59小时，这对一般的应用来说显然是够用的。而TI的另一款专用多媒体处理芯片DM642，其功耗为1.5W，是OMAP的50～150倍。对于便携式的多媒体终端而言，由于并不需要太高的运算处理能力，采用OMAP平台既能满足需要，又可以节约电池电力。

　　③速度的考虑。TMS320C64X+最多可以并行执行8条指令，所以理论上的最大速度是4 160 MIPS(520MHz)。这一点相比目前最快的多媒体处理芯片DM642(4 800 MIPS，600 MHz)来说稍低，但两者的目标定位不同。DM642主要用于实时编码等对速度要求较高的场合，而0MAP主要用于手持设备的解码。以H.264算法的Base Profilc为例，复杂度比MPEG-4高20%～30%。对于MPEG4，在QCIF、15 fps下需要28 MIPS;对应的H.264算法的Base Profile要求40 MIPS的运算速度。

　　④程序结构的考虑。DSP的片内内存速度最快，但是非常有限，所以必须将片外的数据倒入内存。由于目前的编码方式全都是采用基于宏块的，每个宏块至多16×16，所以比较通用的办法是采用，DMA方式将要用到的数据提前倒入片内。DMA传送速度很快，所以可以并行也可以串行传送。

　　⑤软件加速的考虑。可以仿照IMGLIB的编写规则用汇编语言对耗时最多的部分进行重写，同时结合TI公司的数据手册进行C语言级以及汇编级的程序优化。由于TI公司编译器的编译效率一直在提高，从通用及可读性的角度上讲，推荐采用C语言。

　　3 实时视频解码在OMAP上的软件实现

　　在OMAP上开发程序通常分为两部分：ARM端负责控制、显示等;DSP端负责数据处理。采用TI公司提供的DSP开发工具CCS在这两端分别开发，视频解码流程如图2所示。

　　ARM端：初始化整个OMAP3530芯片，包括ARM、DSP、TC等的时钟设置，DSP的开启关闭以及复位，LCD、定时器等各个外设的初始化。在启动完成后，ARM内核就一直查询共享内存中的某一标志位，当查询到一帧解码结束时，就启动LCD专用DMA，在LCD上进行显示。

　　DSP端：负责压缩的解码。将压缩码流放置在SDRAM中。与基于PC的解码程序的主要区别在于，由于DSP的片内内存有限，所以不可能将当前帧以及参考帧都放在片内，所以以宏块为单位在SDRAM与片内内存之间进行数据传递。另外，由于在液晶屏上显示时需要转换成RGB图像，所以，在每一帧结束后都要通过YUV转RGB来实现实时显示。

　　4 实验结果

　　在0MAP3530平台上实现了AVS解码，表4给出了OMAP3530上的实验数据。