嵌入式H264网络视频监控系统.docx

嵌入式H264网络视频监控系统.docx

《嵌入式H264网络视频监控系统.docx》由会员分享，可在线阅读，更多相关《嵌入式H264网络视频监控系统.docx（43页珍藏版）》请在冰豆网上搜索。

嵌入式H264网络视频监控系统

题目嵌入式H.264网络视频监控系统设计与研究

摘要

H.264是ITU-T和ISO/IEC联合推出的最新视频编码国际标准，较之以往的视频编码标准有了明显的进步。

由于其良好的压缩效率和网络自适应性，H.264将在可视电话、远程监控、移动流媒体、视频压缩存储等领域得到广泛的应用。

基于ARM的嵌入式视频监控系统，具有体积小、成本低、稳定性高、实时性好、重量轻，便携等优点，具有很强的实用性价值，可广泛应用于安全监控系统、视频会议、远程同步教学等领域。

研究在嵌入式开发平台上实现H.264视频监控具有重要的现实意义。

本文设计并实现了一个嵌入式H.264视频监控系统。

通过对嵌入式、数字图像处理等技术的研究，提出了基于utu2440开发平台的视频编码系统的设计与优化方案。

论文的主要工作从以下几个方面展开：

一是分析了H.264主要功能模块和核心算法复杂度，对计算复杂度高、费时多的分子像素运动进行了优化；二是充分利用系统资源配置和ARM处理器特性，结合H.264视频编码的运算量大和存储访问任务繁重的特点对ARM平台进行了优化；三是编写了视频采集应用程序，结合X264源码，完成了视频采集并压缩为H.264/AVC格式的视频数据的功能，实现了视频采集压缩系统的设计与优化，利用UDP协议完成了压缩视频流的发送；最后远程监控端采用DirectShow技术实现了视频解码播放。

测试结果表明本系统具有图像压缩率高、质量好（QCIF显示模式）的优点，在utu2440开发板上视频延迟时间小，基本达到监控目的。

关键词：

嵌入式；H.264；UDP；DirectShow；优化

第二章嵌入式H.264视频监控系统总体方案设计

§2.1设计总体方案

本课题设计的嵌入式视频监控系统，采用迄今为止最先进的H.264视频压缩标准压缩视频文件，为基于嵌入式的多媒体应用搭建一个应用的基础平台。

基于此设计思想，提出系统的总体设计框架如图2.1所示。

图2.1系统总体框图

服务器端以RISC通用处理器为核心，由SDRAM、FLASH等存储器件和各种通信接口构成嵌入式硬件平台。

通过USBHOST接口接入摄像头外设，以捕获视频原始数据。

同时设有RS232、JTAG、LAN等用于开发调试的接口。

选用免费、开源的Linux操作系统以实现基本控制和网络连接功能；采用H.264对采集的视频进行压缩编码，采用UDP协议实现视频的网络传输。

客户端采用H.264解码后用Directshow技术播放接收到的视频。

§2.2硬件平台的选择

嵌入式处理器是嵌入式系统的核心部件。

嵌入式处理器与通用处理器的最大不同点在于它把通用计算机中许多由板卡完成的任务集成在芯片内部，从而有利于嵌入式系统设计趋于小型化，并且具有高效率、高可靠性等特征。

现今市面上有1000多种嵌入式处理器芯片，其中使用最广泛的有ARM、MIPS、PowerPC、MC68000等。

目前，采用ARM技术知识产权（IP）核的微处理器，即我们通常所说的ARM[9]微处理器，已遍及工业控制、通信系统、网络系统、消费类电子产品、无线系统等各类产品市场，基于ARM技术的微处理器应用约占据了32位RISC微处理器75%以上的市场份额，ARM技术正在逐步渗入到我们生活的各个方面[10]。

ARM所提供的16/32位嵌入式RISC内核有以下几个系列：

ARM7，ARM9，ARM9E，ARM10，SecurCore，StrongARM和IntelXScale。

其中，ARM7，ARM9，ARM9E和ARM10为4个通用处理器系列，每个系列提供一套相对独特的性能来满足不同领域的需求。

例如SecurCore系列专门为安全要求较高的应用而设计。

S3C2440X[11]是韩国三星公司推出的一款基于ARM920T内核的16/32位RISC嵌入式微处理器。

以手持设备为主，其特点有[12]：

功耗低、处理速度快，同时增加了丰富的外围资源，这对系统开发非常有利。

作为该芯片的CPU内核，16/32位ARM920TRISC微处理器采用0.13μmCMOS标准单元和存储单元复合体。

它功耗极小，简单、稳定的设计非常适合对电源要求较高的产品上。

ARM920T核由ARM9TDM1、存储管理单元（MMU）和高速缓存三部分组成。

其中，MMU可以管理虚拟内存，高速缓存由独立的16KB指令Cache和16KB数据Cache组成。

该芯片集成了支持TFT的LCD控制器、NANDFLASH控制器、SDRAM控制器、3个通道的UART等等控制器和丰富的外部接口。

在时钟方面其也有突出的特点，该芯片集成了一个具有日历功能的RTC（实时控制）和具有PLL（MPLL和UPLL）的芯片时钟发生器。

CPU最高主频达533MHz（标称频率为400MHz）。

该工作频率能够使处理器轻松运行WinCE、Linux等操作系统以及进行较为复杂的数据处理。

utu2440开发板使用三星S3C2440微处理器，其它资源：

10/100MHz自适应以太网控制器，用于网络通信；1通道5线制串口、2通道3线制串口，用于下载程序和打印输出信息；1通道USB1.1主机接口，可接usbhub，扩充多个usb主口，1通道USB1.1设备接口，用于接USB摄像头，及挂载临时程序；SD/MMC卡接口，可用来挂载程序；标准20pinJTAG调试接口，主要用来下载引导程序U-BOOT；标准配置64MBytesNand-Flash用于存放启动代码、内核、根文件系统，服务端程序等；标准配置64MBtyesSDRAM存储程序，启动代码启动后，由UBOOT的前4K代码负责把UBOOT从nandflah复制到SDRAM中，然后在SDRAM中执行整个系统的启动；支持的操作系统：

WINCE/Linux。

鉴于utu2440的以上特性，以及成本低的特点。

非常适合本系统的开发，因此选用utu2440开发板作为本系统的硬件平台。

开发板实物如图2.2。

图2.2utu2440开发板实物图

§2.3软件平台

§2.3.1视频采集方案

本节介绍在utu2440开发平台上基于VideoforLinux的实时视频采集方案，USB摄像头因其价格低廉、性能良好而广泛应用于可视电话、视频聊天、视频监控等领域，同时以其灵活、方便的特性，易于集成到嵌入式系统中。

摄像头由主控芯片和传感芯片组成。

其中，主控芯片负责图像采集、压缩以及和主机的通信，传感芯片用于感应光信号转换为模拟或数字视频电信号。

对于主控芯片为OV511、zc030x系列的主流USB摄像头，Linux内核可提供驱动程序支持。

采用OV511芯片的摄像头采集的图像为RGB格式，数据量较大不利于实时采集和处理;采用zc030x主控芯片的摄像头支持JPEG格式和4:

2:

0采样的YUV原始视频数据输出，数据量小，可直接作为H.264等视频压缩编码标准的原始视频数据源，避免了对图像的重采样和色彩空间的变换等复杂的数字运算处理，非常适合于嵌入式的实时视频采集应用，已成为国内市场的主流。

系统选择市场上常见的中星微USB摄像头，其采用的主控芯片为zc0301，图像传感芯片为HV7131R，图像象素为130万，最大分辨率为640×480。

驱动程序选用gspca/spcasxx，所用版本为gspcavl-20080605。

§2.3.2视频编码方案

H.264标准是ITU-T的VCEG（视频编码专家组）和ISO/IEC的MPEG（运动图像专家组）的联合视频组（JVT，JointVideoTeam）开发的标准,也称为MPEG-4AVC，它作为MPEG-4Part10，是“高级视频编码”。

H.264比H.263节约50%左右的码率，所以它有更好的IP、更高的压缩比和无线网络信道的适应性。

H.264具有较强的抗误码特性，可适应丢包率高、干扰严重的信道中的视频传输。

H.264支持不同网络资源下的分级编码传输，从而获得平稳的图像质量。

在数字视频通信和存储领域H.264得到越来越广泛的应用。

鉴于H.264的以上优点，我们采用H264实现视频的编解码。

H.264标准包含了三大开源编码器，它们分别是JM、X264、T264[13]。

JM：

特点：

实现了H.264标准规定的所有特性，但其程序结构冗长，在引入各种新特性以提高编码性能时，却忽视了编码复杂度，其编码复杂度极高，实用性不强。

X264：

特点：

注重实用。

和JM相比，在不明显降低编码性能的前提下，努力降低编码的计算复杂度，故X264摈弃了JM中一些对编码效率贡献微小但计算复杂度极高的特性。

T264：

特点：

和X264的出发点相似，并吸收了JM、X264、XVID的部分优点。

为了选择更佳的编码器，我们对上述三大开源编码器做了如下测试：

一：

测试环境

CPU:

赛扬2.13G

RAM:

1GDDRII

OS:

WindowsXP

编码器版本：

JM:

JM86。

选用不同分辨率qcif和cif，所有测试序列帧率都采用30fps。

X264:

x264-060330版本。

T264:

0.14版本。

编码选项：

由于X264和T264是基于基本档次的，所以JM采用baselineprofile。

T264采用fastmode。

量化步长依次选择为：

24、28、32、36。

二：

测试的可行性

由于我们测试的是编码器本身综合编码效率的优劣，因此在Intel处理器Windows操作系统上的测试结果同样适用于ARM处理器Linux操作系统中，即：

如果在Windowsxp上编码器的编码效率从高到低的测试结果依次为：

X264>T264>JM86，则在utu2440开发板中的测试结果同样有X264编码效率优于T264及T264优于JM86。

而在Windowsxp上测试速度更快、更方便，所以选用在Windowsxp上测试，以节约开发时间。

当编码器选用JM86，测试输入文件采用foreman_qcif.yuv，量化步长QP=24时，测试输出如图2.3、图2.4。

其它测试截图不一一列出。

图2.3JM86测试输出截图

图2.4JM86测试输出截图

三：

实验结果分析

1）PSNR:

相同输入格式下三个编码器的表现相差很小。

不同输入格式下JM86的y、u、v差异稍大，X264和T264差异很小，尤其是y分量差异很小，最大差异为2.07db。

2）码率:

Cif序列的码率是qcif序列的三倍多，qp越大倍数减少。

3）编码速度:

在同一视频序列下x264是jm86的90－300多倍，t264是x264的1.6倍左右，对同一个编码器qcif编码速度是cif的4倍左右，而在t264下，其倍数达4.5倍左右，说明t264对低分辨率序列的编码比较有效。

4）分辨率提高n倍，为了得到相近的编码质量，输出码率和所用的编码时间也要增加近n倍。

四、实验结论

1）X264

X264和JM86相比，其编码性能和JM86相当或更好的情况下，其编码速度可以提高90－300倍。

这体现了X264编码非常有效。

2）T264

T264和JM86相比，编码速度有了更大的提高，但其编码性能下降很大，除了传输带宽比较大或延时要求极其苛刻等这些特殊场合，T264（fastmode）的意义不大。

3）T264high

T264high在编码性能不如X264，而且编码速度也不如X264。

总之，JM86编码效率不如T264,T264的编码效率不如X264。

基于以上结论本文采用实效性更强的X264作为编码器。

§2.3.3视频传输方案

视频传输可以选择TCP与UDP。

TCP（TransmissionControlProtocol）是一种面向连接的、可靠的、基于字节流的运输层通信协议，通常由IETF的RFC793说明。

在简化的计算机网络OSI模型中，它完成运输层所指定的功能。

在因特网协议族中，TCP层是位于IP层之上，应用层之下的中间层。

不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。

　　应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，然后TCP把数据流分割成适当长度的报文段。

之后TCP把结果包传给IP层，由它来通过网络将包传送给接收端实体的TCP层。

TCP为了保证不发生丢包，就给每个字节一个序号，同时序号也保证了传送到接收端实体的包的按序接收。

然后接收端实体对已成功收到的字节发回一个相应的确认（ACK）；假如发送端实体在合理的往返时延（RTT）内未收到确认，那么对应的数据将会被重传。

TCP用一个校验和函数来检验数据是否有错误；在发送和接收时都要计算校验和。

TCP协议一般不直接用来传送视频数据本身，但是对于视频传输中传输中的控制信息而言，TCP是最合适的。

UDP（UserDatagramProtocol）是无连接的用户数据报协议，它由RFC768标准定义。

是OSI参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。

UDP协议基本上是IP协议与上层协议的接口。

UDP协议适用端口分别运行在同一台设备上的多个应用程序。

与TCP类似，UDP为每个来自上层的数据块加上一个UDP报头，形成UDP消息段，与TCP相比，UDP的报头要简单得多，其中校验和是用于检查传输中是否出现错误。

与TCP不同，UDP并不提供对IP协议的可靠机制、流控制以及错误恢复功能等。

由于UDP比较简单，UDP头包含很少的字节，比TCP负载消耗少。

 UDP适用于不需要TCP可靠机制的情形，比如，当高层协议或应用程序提供错误和流控制功能的时候。

UDP是传输层协议，服务于很多知名应用层协议，包括网络文件系统（NFS）、简单网络管理协议（SNMP）、域名系统（DNS）以及简单文件传输系统（TFTP）。

对视频数据的传输而言（对时延敏感，但可以容忍一定的错误），UDP比TCP更为合适。

尽管TCP是一个很成功的协议，但是无法满足视频传输的需要。

TCP的大量确认应答使视频数据不得不因为等待应答而放弃，造成不必要的延时和更大范围的数据丢失。

相比较而言，UDP只要网络流量足够，视频数据就可以源源不断的到达接收者。

因此，在IP网络上传送视频数据，往往采用UDP协议，而不是TCP协议[14]。

本系统我们选用UDP作为传输协议。

§2.3.4视频播放方案

网络上经过H.264压缩的视频流用当前主流播放器播放不了，必须要自主设计一个播放器。

本设计中我们选用DirectShow技术设计一个播放器。

DirectShow技术是DirectX推出的一个多媒体应用程序开发包，DirectShow支持多媒体流的捕捉和回放。

利用DirectShow，可以轻松地从采集卡上捕获数据，然后进行处理并存储到本地文件中。

它支持各种媒体格式，包括Asf、Mpeg、Avi、Dv、Mp3、Wave、H.264等，轻松地实现多媒体数据的回放。

另外，DirectShow直接支持DVD的播放，数字摄像机的数据交换，视频的非线性编辑。

更重要的是，DirectShow提供了一种开放式的开发环境，可以根据不同需要定制自己的组件。

实际上，MediaPlayer就是在DirectShow基础上搭建起来的。

功能非常的强大。

一、DirectX简介

DirectX是微软公司提供的一套底层应用程序编程接口，主要在游戏和其他高性能多媒体上应用。

这些接口包括对二维和三维图形，音乐和声效，输入设备以及网络游戏等的支持。

目前最高版本是DirectX9.0[15]。

二、DirectShow的系统组成

DirectShow技术建立在DirectSound和DirectDraw之上，它利用DirectDraw控制显卡来显示视频，利用DirectSound控制声卡来播放声音。

DirectShow可提供高质量的多媒体流的捕获和回放功能；支持的媒体格式很多：

包括MPEG，MP3，ASF，AVI和WAV等声音文件；可以从视频采集卡上捕获媒体数据流；还可以自动检测并使用视频和音频加速硬件处理速度。

因此，可以充分发挥DirectShow的媒体功能，提高运行速度，简化媒体间的格式转换、媒体播放和媒体捕获等工作。

同时，它还具有很大的灵活性和可扩展性，可以由用户创建组件，然后将这个组件加入DirectShow结构中以支持需要的格式或特殊效果[16]。

DirectShow所支持的软硬件以及应用程序与DirectShow组件之间的关系如图2.5所示。

图2.5DirectShow系统框图

本系统利用DirectShow来播放网络传输过来的压缩H.264视频流。

§2.4本章小结

本章根据嵌入式视频监控的特点提出了系统的总体设计方案，对构成该系统的各个模块进行了比较选择，采用迄今为止最先进的H.264视频压缩标准压缩视频文件，以此为基础构建一个网络视频监控平台。

从而达到控制成本低，监控效果好的目的。

图3.1H.264编码器框图

第四章编码器优化及嵌入式系统实现

§4.1H.264编码器优化

§4.1.1H.264编码器复杂性分析

H.264获得高性能的同时，也增加了编码器的复杂度。

优化H.264的目的就是要找出其中耗时最多，效率最低的部分，对其进行优化改进，以达到实用[15]。

本文在X264中对编码的关键模块进行了测试，实验采用6个典型的标准测试序列：

CIF格式的foreman、football、Stefan和QCIF格式的akiyo、carphone、foreman，30帧/秒，共90帧。

编码主要参数为：

搜索范围16，量化28，参考帧数5，帧结构PBBPBB……。

测试结果如表4.1所示。

表4.1编码器主要模块开销（%）

序列

格式

运动估计

变换和量化

帧内预测

率失真优化

其它

Foreman

Football

Stefan

Akiyo

Carphone

foreman

CIF

CIF

CIF

QCIF

QCIF

QCIF

62.14

70.08

66.47

28.87

34.25

33.47

10.68

8.37

9.25

20.63

19.56

20.40

4.26

4.73

4.48

7.73

6.78

6.83

17.41

12.37

15.70

29.25

31.87

31.67

5.57

4.52

4.18

13.58

7.61

7.71

实验表明对于CIF格式，运动估计占整个计算量的60-70%。

QCIF格式，运动估计占整个计算量的30%左右，为了降低编码器的复杂度，该运动估计算法还有很大的改进空间。

在通常情况下，视频序列连续两帧之间的内容相差不大，甚至有很大一部分是完全相同的，相邻帧间有较强的相关性。

通过运动估计和补偿可以消除这种时域相关性，使编码器输出的比特率大为降低。

§4.1.2运动估计概述

运动估计（MotionEstimation，ME）是视频编码中普遍采用的一项关键技术，已经被广泛运用到了视频压缩的一些国际标准中，如MPEG4、H.264/AVC等。

它也是消除视频数据时间冗余的最重要的方法，它的优劣直接决定编码效率和重构视频的质量[34]。

一般而言，运动估计越准确，则补偿的残差图像越小，编码效率也就越高，在相同码率下的解码视频就具有更好的图像质量。

但是，运动估计的计算复杂度也占据了编码器的大部分时间，为了保证视频编解码的实时性，运动估计应当具有尽可能低的计算复杂度。

因此如何提高运动估计算法的性能，提高其效率，使得运动估计更快速和精确一直受到学术界和工业界的广泛关注。

一般而言，运动估计包括两个部分：

整数像素运动估计和由整数像素进行插值得到的最优点的分数像素运动估计[35][36][37]。

分数像素运动估计一般采用全搜索法，1/2像素精度的搜索点数为8个，1/4像素精度的搜索点数为16个。

因此，分数像素运动估计的计算复杂度非常重要。

分数像素的引入，提高了运动估计的精度，输出图像的质量也有所改善，但运动估计复杂度大幅度增加。

因此减少分数像素运动估计的计算量就变得十分必要。

§4.3H.264视频监控嵌入式系统实现

§4.3.1NFS环境的搭建

在嵌入式Linux的开发过程中，开发者需要在Linux服务器上进行所有的软件开发，交叉编译后，通用FTP方式将可执行文件下载到嵌入式系统运行，但这种方式不但效率低下，且无法实现在线的调试。

因此，可以通过建立NFS，把Linux服务器上的特定分区共享到待调试的嵌入式目标系统上，就可以直接在嵌入式目标系统上操作Linux服务器，同时可以在线对程序进行调试和修改，大大的方便了软件的开发[43]。

因此，NFS的是嵌入式Linux开发的一个重要的组成部分，本部分内容将详细说明如何配置嵌入式Linux的NFS开发环境。

配置NFS，需要添加/etc/exports文件。

/etc/exports文件格式以及说明如下：

#共享目录主机名称1（参数1，参数2）主机名2（参数3，参数4）

共享目录：

是宿主机上要向外输出的以后目录

主机名称：

是允许按照指定的权限访问这个共享目录的远程主机

参数：

是定义了各种港问权限

在我的开发板上exports配置如下：

/mnt*（rw,sync,no_root_squash）

这种配置表示输出共享/mnt目录，并且所有的IP都可以访问。

在完成/etc/exports这个配置文件后就可以启动NFS服务了，用service命令启动。

#serviceportmapstart

#servicenfsstart

#serviceiptablesstop

开发板要共享宿主机上的文件/opt/FriendlyARM/utu2440/root_qtopia，只需要运行文件的挂载命令就可以了。

和挂载本地文件系统时唯一不同的地方在于要挂载的文件系统的描述前加上远程文件系统的主机名或IP地址。

挂载语法如下:

#mount–tnfs–onolock192.168.1.111:

/opt/FriendlyARM/mini2440/root_qtopia

/mnt

挂载成功后，就可以把要调试的应用程序拷贝到宿主机/mnt目录下进行挂载调试，调试成功后就可以下载到开发板上永久保存，如图4.5所示。

取消挂接的命令如下：

#umount/mnt

图4.5配置NFS开发环境

§4.3.2外部存储设备的挂载

一般ARM开发板的存储空间有限，utu2440开发板nandflash存储空间大小为64M，这些存储空间大多数被根文件系统占用了，余下的空间很小，为了让我们的驱动程序和应用程序能在板子上跑起来，可以挂接外部存储器，方便而常用的办法就是挂接一个U盘，让U盘跟PC机上一样使用。

ARM-LINUX挂U盘也象PC那么容易其实不难，只需要写一个小小的脚本程序。

（1）先将auto_udisk复制到目标板的/test目录下，确认本目录下是否有udisk，如果有则新建/mnt/usb目录。

（2）在rc.local中添加命令：

  mount-tusbdevfsnone/proc/bus/usb    //添加USB文件系统

/test/udiskstart                       //添加U盘相应的驱动

/test/auto_udisk&                     //后台运行自动挂载（卸载）U盘然后重新启动。

（3）插入U盘后，程序会将自动挂载U盘到  /mnt/usb：