摘要:根据视频监控的特点,设计了一种强实时的嵌入式视频监控系统。系统基于QNX(Quick UNIX)嵌入式实时操作系统,采用异构双核处理器芯片OMAP3530为核心的开发平台,实现了视频的编解码和传输过程。
关键词:QNX;视频监控系统;视频编解码;OMAP3530
引言
嵌入式视频监控系统是当今嵌入式系统发展的热门应用,尤其是数字化视频监控系统越来越受到客户的青睐。目前,嵌入式视频监控系统大多基于Linux操作系统完成,这对于系统CPU是一个不小的开销;同时,系统的稳定性和实时性无法得到很好的保障。本文提出一种基于QNX系统的视频监控系统。QNX(Quick UNIX)是一种实时的微内核操作系统,有利于减小系统CPU开销,并提升系统的稳定和实时性能;用OMAP 3530处理器中的DSP核来完成视频的编解码,有利于提升视频画面质量,提高视频传输速率。
1 系统整体设计
视频监控系统方案是基于开放式多媒体应用平台OMAP设计的。OMAP3530芯片集成了高性能、低功耗的DSP核与控制性能较好的ARM内核,是一种开放式的、可编程的体系结构。系统ARM端负责初始化整个芯片,包括ARM、DSP、TC(Traffic Controller,流量控制器)等的时钟设置,DSP的开启和复位,以及LCD、定时器等各个外设的初始化。DSP端负责视频的编解码。监控系统硬件结构图如图1所示。监控系统主要由OMAP3530芯片、USB摄像头、液晶显示器、存储模块(SDRAM、ROM、Flash)、JTAG构成。USB摄像头获取视频信息后,经OMAP3530部进行视频编解码处理后,存储在存储介质上,或在液晶显示器上进行显示。
1.1 OMAP3530平台介绍
OMAP3530主要由ARM内核、DSP内核及流量控制器TC组成。
OMAP3530采用ARM Cortex—A8核,工作主频最高可达720 MHz。它具有存储器管理单元、16 KB的高速指令缓冲存储器、16 KB的数据高速缓冲存储器和256KB的二级Cache;片内有64 KB的内部SRAM,为液晶显示等应用提供了大量的数据和代码存储空间。ARM内核拥有整个系统的控制权,可以设置DSP、TC以及各种外设的时钟及其他工作参数,控制DSP的运行停止。本设计通过ARM完成对整个视频监控系统的控制和调度。
DSP内核TMS320C64X+采用3项关键的革新技术:增大的空闲省电区域、变长指令和扩大的并行机制。另外,TMS320C64X+内核增加了固化了算法的硬件加速器,来处理运动估计、8×8的DCT/IDCT和1/2像素插值,降低了视频处理的功耗。
流量控制器TC用于控制ARM、DSP以及本地总线对OMAP3530内所有存储器的访问。
1.2 双核之间的通信
系统的实现,需要让ARM核与DSP核实现协调的通信。利用Codee Engine构架,可以实现和管理ARM与DSP双核之间的数据通信。
Codec Engine是一组用来配置和运行DSP端的符合xDAIS算法的架构,它把符合xDAIS算法纳入其架构之下,让ARM端的QNX可以调用它提供的VISA标准接口,从而实现ARM与DSP的软件管理。图2是CodecEngine下一个应用程序的通用构架。
图2中,应用程序(Application)或者中间层(mediamiddle ware)调用核心引擎和VISA的API。VISA的API使用存根(Video Encode Stubs)来访问核心引擎SPI(系统编程接口)和构架(Video Encode Skeleton)。这些构架访问核心引擎和VISA的SPI。VISA的SPI访问底层算法。
1.3 操作系统介绍
QNX拥有一个非常高效的徼内核,它负责管理一组同时工作的进程,同时,QNX能够实现基于消息的进程间通信。这使得QNX具有独特的高效性、模块化和简易化性能。
整个QNX操作系统是由徼内核调度管理的一组进程的集合,与硬件的总线结构类似,称之为软件总线。软件总线的存在,使得微内核之外的系统模块能够像硬件一样“热插拔”。在微内核中,应用程序、设备驱动程序、文件系统和网络协议栈都驻留在内核外部的独立地址空间,因此它们与内核以及彼此之间都相互隔离,具有出色的故障包容性:一个组件的故障不会导致整个系统崩溃。提高了系统的稳定性和安全性。
如图3所示,整个QNX操作系统是由微内核调度管理的一组进程的集合,与硬件的总线结构类似,称之为软件总线。软件总线的存在,使得微内核之外的系统模块能够像硬件一样“热插拔”。QNX由微内核和一组可供操作的进程构成,具有高度的可裁剪性,最小的配置只占用几十KB的内存。同时,QNX是一个符合POSIX基本标准和实时标准的操作系统,大大方便了在不同系统之间进行应用程序的移植,这让许多符合POSIX相应标准的其他系统上开发的应用程序,不需要修改,在QNX上重新编译后就能运行。本文将基于Linux操作系统的H.264视频编解码程序移植到QNX上,可以节省大量时间。
2 H.264视频编解码
2.1 H.264视频编解码基本原理
H.264采用DCT变化编码加上DPCM的编码,即混合编码结构。同时,H.264在混合编码的框架下引入了新的编码方式,提高了编码效率,更加贴近实际应用。H.264引入了很多先进的技术,包括4×4整数变换、空域内的帧内预测、1/4像素精度的运动估计、多参考帧与多种大小块的帧间预测技术等。依赖于算法复杂度的提升,使得压缩比获得了极大的提升。
H.264并未明确地规定编解码器如何实现,而是规定了一个已编码的视频比特流的句法和该比特流的解码方法。
2.2 H.264编解码器
(1)编码部分
H.264编码器如图4所示。输入的帧或场Fn以宏块为单位被编码器按帧内或帧间预测编码的方法进行处理。如果采用帧问预测编码,其预测者PRED(图中P表示)是由当前片中的参考图像经运动补偿(MC)后得出,其中参考图像表示。预测值PRED和当前块相减后,产生一个残差块Dn,经块变换、量化后产生一组量化后的变换系数X,再经熵编码,与解码所需的一些信息组成一个压后的码流,经NAL(网络自适应层)供传输和储存用。如果采用帧内预测编码,从图4可看出,其预测者PRED是由当前片和uFn'(重建图像过程中未经滤波的帧)的反馈,经由帧内预测选择得出。
为了提供进一步预测用的参考图像,编码器必须具有重建图像的功能。使残差图像经反量化、反变化后得到Dn',与预测值P相加得到uFn'。为了提高参考帧的图像质量以提高压缩图像的性能,设置了一个环路滤波器,滤波后的输出Fn'即为重建图像,可用作参考图像。
(2)解码部分
H.264解码器如图5所示。由编码器的NAL输出一个压缩后的H.264比特流,经熵解码得到量化后的一组变换系数X,再经反量化、反变换,得到残差的Dn'。利用从该比特流中解码出的头信息,解码器产生一个预测块PRED,它和编码器中的原始PRED相同。当解码器产生的PRED与残差Dn'相加后,就产生uFn',再经滤波后,最后得到Fn',即最后解码输出的图像。
3 系统软件设计
3.1 视频处理流程
视频处理流程如图6所示。监控系统软件设计的核心部分是视频信号的采集、编码等处理,主要由Capture thread、Video thread、Stream writerthread来实现。Capture thread主要完成采集设备的初始化,使它工作在合适的状态,从采集设备获取原始视频数据放到缓冲区,为Video thread编码作准备。Video thread对Capture thread放到缓冲区中的原始图像数据进行编码,得到H.264码流。Stream writer thread的主要工作是把H.264码流写入循环缓冲区。放在循环流缓冲区的码流可以根据用户的需求进行进一步的处理,本系统主要将H.264码流存储到SD卡中。
3.2 视频采集设计
这里主要介绍系统对于USB接口摄像头的处理方法,其驱动程序中需要提供I/O操作接口函数open()、read()、write()、close(),对中断的处理,内存映射功能以对I/O通道的控制借口函数ioctl()等,并把他们定义在struct file_operations中。视频采集系统软件流程如图7所示。
软件的主要函数如下:
Camera_open():用来开启视频设备,使用前需要首先声明一个camera_device类型的设备文件。
camera_get_capability():通过调用ioctl()函数取得设备文件的相关信息,并存放到camera_capability结构里。
camera_get_picture():通过调用ioctl()函数取得图像相关信息,并存放到camera_picture结构里。
camera_capture():用来抓取图像,采用mmap方式,直接将设备文件/dev/videoO映射到内存,加速文件I/O操作,共享内存通信。
camera_timer:设定一个定时器,用于控制视频设备采集图像的时隙。
picture_save():保存采集的图片。
picture_num():对保存的图片计数,设定一个最大值,每当该计数器达到最大值时,调用删除图片函数picture_del(),一次性将已发送的几张图片删除。
camera_close():用来关闭视频设备。
结语
对于视频处理来说,采用QNX+OMAP处理器的解决方案是个不错的选择。由于视频编解码算法实现需要大流量的计算,使用OMAP3530开发平台,利用OMAP3530的DSP芯片来完成视频编解码,可以较好地提高编解码的速率;同时,QNX实时操作系统的编程接口符合POSIX标准,可移植性较强,可支持多种视频格式编解码。