达芬奇TMS320DM 6446的视频软件设计*

谢文滨，叶水生

（南昌航空大学 信息工程学院，江西 南昌 330063）

随着计算机多媒体技术、网络通信技术、微电子技术、数字信号处理技术的高速发展，嵌入式数字视频监控系统正迅速深入到学校、银行、商场、机场、道路交通等领域的安防监控。然而，视频数据量庞大，如此广泛的应用，也就需要压缩率更高的算法。H.264是目前最先进的视频压缩标准，具有高压缩率的同时还具有更强的网络适应性，它提供了网络抽象层，使得H.264的文件更容易在不同网络上传输 （例如互联网、WCDMA、CDMA2000等）。为了应对强劲的市场需求，德州仪器（TI）公 司 推 出 达 芬 奇[1]（DaVinci）技 术 的 TMS320DM6446处理器，它是一种专门针对数字视频应用、基于信号处理的解决方案，提供了专业的集成处理器、软件、工具和支持，以简化设计过程，加速产品创新，深受开发者青睐。然而，它的开发却非常复杂，使得许多开发者都未能尽可能地发挥其硬件作用。为此，本设计采用了基于达芬奇技术的TMS320DM6446处理器为开发平台，介绍了达芬奇平台的双核通信机制，并以H.264进行压缩编码，设计实现视频编码软件系统。

1 TMS320DM6446双核通信

TMS320DM6446集成了TMS320C64x+DSP核和ARM926EJ-S核。在ARM端基于MontaVista Linux、相关驱动和应用程序来管理芯片与外设的交互，DSP作为ARM的协处理器，主要是基于DSP/BIOS（TI公司的实时操作系统内核）来处理复杂的音视频编解码相关的算法。高集成度带来了开发的复杂性，ARM和DSP间通过DSPLink完成通信，同时需要编解码引擎Codec Engine和编解码服务器Codec Server协助完成。

1.1 Codec Engine

Codec Engine是处理器间通信的桥梁，是介于ARM侧的应用程序和DSP侧的算法之间的软件模块，可以通过调用一组API集合来调用和运行符合xDAIS标准的算法。Codec Engine包括核心引擎（Core Engine）API和VISA（Video，Image，Speech，Audio）API。 其中的 VISA API通过stub （ARM端） 来访问核心引擎SPIs（System Programming Interface）和 skeleton（DSP 端），skeleton 访问核心引擎 SPIs和 VISA SPIs，VISA SPIs则最终调用具体的算法。因此，Codec Engine的工作是通过完成VISA API的任务来体现的。整体结构如图1所示。

图1 Codec Engine结构图

核心引擎操作如下：

打开一个编解码引擎之后，就可以创建、控制、处理、删除具体的算法实例。VISA接口支持4种数据源的处理，分别是视频、图像、语音和音频。

VISA API应用如下：

1.2 Codec Server

Codec Server是一个二进制文件，集成了编解码器、框架组件以及相关的系统代码，可以使用DSP/BIOS作为内核运行在DSP端。Codec Server类似于一个网页服务器，包括了对客户请求（ARM端应用程序对DSP端音视频算法的调度）进行响应的相关DSP/BIOS任务线程，能够用于创建编解码器，同时也提供处理器性能信息。

Codec Engine和 Codec Server间的通信就是RPC（远过程调用）原理在双核上的实现。ARM端当成客户机，访问DSP服务器的算法；而DSP端被当成服务器，响应ARM端应用程序的请求。

2 系统总体结构

系统基于达芬奇平台数字媒体处理器TMS320DM6446进行设计，同时结合128MB DDR2 SDRAM内存、视频解码器 TVP5150、CCD摄像头、10M/100M标准以太网芯片。系统框图如图2所示。

图2 系统框图

在ARM端，使用CCD摄像头实时采集模拟视频信号，传入视频解码器TVP5150内进行A/D转换为数字视频信号，这部分的采集工作由视频前端VPFE负责。为了使这些数据能被DSP处理，VPFE需要将RGB格式的原始图像转换为YUV格式[2]。然后使用DSPLink模块与DSP端进行通信，并通过Codec Engine调度DSP端的H.264编码算法，从而得到已编码的视频数据。基于TCP/IP协议，将编码过的数据通过以太网接口EMAC传输至远程管理软件管理。同时为了验证H.264编码的正确性和编码的质量，调用DSP端的H.264解码算法对已编码视频数据进行解码操作，最后通过ARM侧的视频后端VPBE将解码过的视频数据送到LCD进行显示。VPBE能将YUV格式的图像转换为LCD支持的NTSC或者PAL格式。UART0接口主要用于系统调试，DDR2则是视频流数据的交换中心。

3 软件方案设计

本设计中，以MontaVista Linux操作系统作为软件开发平台，基于Linux下视频设备驱动程序规范V4L2[3]（Video for Linux Two）、帧缓冲机制（Frame Buffer）和多线程技术进行视频应用程序的设计。多线程是一种多任务、并发的工作方式，能够提高程序响应及CPU的使用率，并能改善程序的结构。本系统软件设计为5个线程，分别为主线程、显示线程、采集线程、视频线程和控制线程。

3.1 主线程

主线程用于执行必要的初始化，解析用户程序提供的命令行参数，并根据这些参数的值产生其他线程。初始化任务主要包括视频标准检测，使用了帧缓冲设备驱动程序的 ioctl（FBIO_GETSTD）；用户命令行参数解析；Codec Engine初始化；创建显示、采集和视频三个线程；调用控制线程的函数 ctrlThrFxn（ ），从而主线程转变为控制线程。控制线程负责用户接口，可用于响应键盘接口输入的命令；还能在OSD（On-Screen Display，达芬奇平台的在屏显示技术）上显示和更新文字、图形，使用setOsdTransparency（ ）函数设置 OSD窗口的透明度；同时能够在OSD上绘制按钮并对文字着色。具体的流程如图3所示。

3.2 采集线程

ARM端的采集线程基于V4L2设备驱动程序来获取实时的视频缓冲数据，并传给视频线程处理。采集线程的流程如下：

（1）打开视频采集设备

图3 主线程流程图

（2）初始化设备

首先，查询设备的性能，获取视频采集设备的capability，辨别是否具有视频输入特性。

然后，选择视频输入的功能。

设置视频制式和帧格式。

（3）设定数据传输方式

采用内存映射模式。在这种模式下，应用程序和驱动程序之间只有指向视频数据buffer的指针被交换，数据本身不会被复制，提高了效率。

（4）实际的采集操作

V4L2中有两个队列：输入和输出[4]。先把映射好的内存片段入队，接着开始采集视频数据并进入read循环，此时应用程序等待输出队列被填满时可以将内存片段出队，出队的数据就是摄像头采集的视频数据。将出队的内存片段处理完后重新入队列尾，这样可以循环采集。入队和出队操作使用V4L2中的VIDIOC_QBUF和VIDIOC_DQBUF的 ioctl（ ）函数调用。

同时，应用程序可以调用VIDIOC_STREAMON的ioctl（ ）来启动视频采集，VIDIOC_STREAMOFF 的 ioctl（ ）则用来停止视频采集。

（5）关闭设备

3.3 视频线程及其交互

视频线程基于Codec Engine机制调用DSP端的视频编码算法对该数据进行H.264编码，经过预测、量化、熵编码等一系列的操作，大幅减小视频数据的存储容量，从而降低视频传输对网络带宽的需求。已编码的视频数据可以存储在本地硬盘或者基于TCP/IP协议发送至远程管理软件管理。同时为了验证视频编码算法的正确性与质量，调用DSP端H.264解码算法对已编码数据进行解码操作，并且送入显示线程，使用frame buffer机制将其显示在LCD屏幕上。详细的交互流程如图4所示。

图4 视频线程交互流程图

3.4 实际效果

采用 PAL制式，分辨率为 720×480，帧率 25 f/s。 当目标移动速度过快时，视频的清晰度会较大程度降低。实际视频效果如图5所示。

结合达芬奇TMS320DM6446中ARM和DSP处理器各自的优势，提出了基于H.264压缩算法的视频编码软件系统的设计方案，实现视频采集、视频编解码、视频显示和网络传输等功能，在以后的工作中将加入行为分析和追踪等功能，以使系统更加智能。本设计可应用于学校、交通、商业、银行等多个领域，具有较好的前景。

[1]王铭铭，方千山，颜佳泉，等.图像处理和达芬奇技术在纺纱断线检测中的应用 [J].微型机与应用，2012，31（17）：44-45.

[2]HAN Peicen， YE Zhaohui， YANG Shiyuan.The Design and Implementation of Network Video Surveillance System Based on Davinci Chips[C].Qingdao China：Advances in Information Technology and Education，2011，201：296-302.

[3]Bill Dirks.Video for Linux Two[EB/OL].（2003-6-26）http：//www.thedirks.org/v4l2.

[4]赵勇，袁誉乐，丁锐.DAVINCI技术原理与应用指南[M].南京：东南大学出版社，2008.