嵌胧紿264网络视频监控系统.pdf

嵌入式 H.264 网络视频监控系统设计与研究 题目题目 嵌入式 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；优化 第一章 绪论 1 第二章 嵌入式 H.264 视频监控系统总体方案设计 2.1 设计总体方案 本课题设计的嵌入式视频监控系统，采用迄今为止最先进的 H.264 视频压缩标准压缩视频文件，为基于嵌入式的多媒体应用搭建一个应用的基础平台。基于此设计思想，提出系统的总体设计框架如图 2.1 所示。软件应用软件：视频采集、压缩、Directshow解码播放操作系统：嵌入式Linux内核、根文件系统设备驱动程序硬件USB HOSTRS232JTAGLAN 摄像头 图 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)核的微处理器，即我们通常所说的 ARM9微处理器，已遍及工业控制、通信系统、网络系统、消费类电子产品、无线系统等各类产品市场，基于 ARM 技术的微处理器应用约占据了 32 位 RISC 微处理器 75%以上的市场嵌入式 H.264 网络视频监控系统设计与研究 份额，ARM 技术正在逐步渗入到我们生活的各个方面10。ARM 所提供的 16/32 位嵌入式 RISC 内核有以下几个系列：ARM7，ARM9，ARM9E，ARM10，SecurCore，StrongARM 和 Intel XScale。其中，ARM7，ARM9，ARM9E 和 ARM10 为 4 个通用处理器系列，每个系列提供一套相对独特的性能来满足不同领域的需求。例如 SecurCore 系列专门为安全要求较高的应用而设计。S3C2440X11是韩国三星公司推出的一款基于ARM920T内核的16/32位RISC嵌入式微处理器。以手持设备为主，其特点有12：功耗低、处理速度快，同时增加了丰富的外围资源，这对系统开发非常有利。作为该芯片的CPU内核，16/32位ARM920T RISC微处理器采用0.13mCMOS 标准单元和存储单元复合体。它功耗极小，简单、稳定的设计非常适合对电源要求较高的产品上。ARM920T核由ARM9TDM1、存储管理单元(MMU)和高速缓存三部分组成。其中，MMU可以管理虚拟内存，高速缓存由独立的16KB指令Cache和16KB数据Cache组成。该芯片集成了支持 TFT 的 LCD 控制器、NAND FLASH控制器、SDRAM控制器、3个通道的UART等等控制器和丰富的外部接口。在时钟方面其也有突出的特点，该芯片集成了一个具有日历功能的RTC(实时控制)和具有PLL(MPLL和UPLL)的芯片时钟发生器。CPU 最高主频达533MHz（标称频率为400MHz）。该工作频率能够使处理器轻松运行WinCE、Linux等操作系统以及进行较为复杂的数据处理。utu2440开发板使用三星S3C2440微处理器，其它资源：10/100MHz 自适应以太网控制器，用于网络通信；1通道5线制串口、2通道3线制串口，用于下载程序和打印输出信息；1通道USB1.1 主机接口，可接usb hub，扩充多个usb主口，1通道USB1.1设备接口，用于接USB摄像头，及挂载临时程序；SD/MMC卡接口，可用来挂载程序；标准20pin JTAG调试接口，主要用来下载引导程序U-BOOT；标准配置64MBytes Nand-Flash 用于存放启动代码、内核、根文件系统，服务端程序等；标准配置64MBtyes SDRAM 存储程序，启动代码启动后，由UBOOT的前4K代码负责把UBOOT从nandflah复制到SDRAM中，然后在SDRAM中执行整个系统的启动；支持的操作系统：WINCE/Linux。鉴于utu2440的以上特性，以及成本低的特点。非常适合本系统的开发，因此选用utu2440开发板作为本系统的硬件平台。开发板实物如图2.2。第一章 绪论 3 图 2.2 utu2440 开发板实物图 2.3 软件平台 2.3.1 视频采集方案 本节介绍在 utu2440 开发平台上基于 VideoforLinux 的实时视频采集方案，USB摄像头因其价格低廉、性能良好而广泛应用于可视电话、视频聊天、视频监控等领域，同时以其灵活、方便的特性，易于集成到嵌入式系统中。摄像头由主控芯片和传感芯片组成。其中，主控芯片负责图像采集、压缩以及和主机的通信，传感芯片用于感应光信号转换为模拟或数字视频电信号。对于主控芯片为 OV511、zc030 x 系列的主流 USB 摄像头，Linux 内核可提供驱动程序支持。采用OV511 芯片的摄像头采集的图像为 RGB 格式，数据量较大不利于实时采集和处理;采用 zc030 x主控芯片的摄像头支持 JPEG 格式和 4:2:0 采样的 YUV 原始视频数据输出，数据量小，可直接作为 H.264 等视频压缩编码标准的原始视频数据源，避免了对图像的重采样和色彩空间的变换等复杂的数字运算处理，非常适合于嵌入式的实时视频采集应用，已成为国内市场的主流。系统选择市场上常见的中星微 USB 摄像头，其采用的主控芯片为 zc0301，图像传感芯片为 HV7131R，图像象素为 130 万，最大分辨率为 640480。驱动程序选用gspca/spcasxx，所用版本为 gspcavl-20080605。嵌入式 H.264 网络视频监控系统设计与研究 2.3.2 视频编码方案 H.264 标准是 ITU-T 的 VCEG(视频编码专家组)和 ISO/IEC 的 MPEG(运动图像专家组)的联合视频组(JVT，Joint Video Team)开发的标准,也称为 MPEG-4 AVC，它作为MPEG-4 Part10，是高级视频编码。H.264 比 H.263 节约 50%左右的码率，所以它有更好的 IP、更高的压缩比和无线网络信道的适应性。H.264 具有较强的抗误码特性，可适应丢包率高、干扰严重的信道中的视频传输。H.264 支持不同网络资源下的分级编码传输，从而获得平稳的图像质量。在数字视频通信和存储领域 H.264 得到越来越广泛的应用。鉴于 H.264 的以上优点，我们采用 H264 实现视频的编解码。H.264 标准包含了三大开源编码器，它们分别是 JM、X264、T26413。JM：特点：实现了H.264标准规定的所有特性，但其程序结构冗长，在引入各种新特性以提高编码性能时，却忽视了编码复杂度，其编码复杂度极高，实用性不强。X264：特点：注重实用。和JM相比，在不明显降低编码性能的前提下，努力降低编码的计算复杂度，故X264摈弃了JM中一些对编码效率贡献微小但计算复杂度极高的特性。T264：特点：和X264的出发点相似，并吸收了JM、X264、XVID的部分优点。为了选择更佳的编码器，我们对上述三大开源编码器做了如下测试：一：测试环境 CPU:赛扬 2.13G RAM:1G DDRII OS:Windows XP 编码器版本：JM:JM86。选用不同分辨率 qcif 和 cif，所有测试序列帧率都采用 30fps。X264:x264-060330 版本。T264:0.14 版本。编码选项：由于 X264 和 T264 是基于基本档次的，所以 JM 采用 baseline profile。T264 采用fast mode。量化步长依次选择为：24、28、32、36。二：测试的可行性 由于我们测试的是编码器本身综合编码效率的优劣，因此在Intel处理器Windows操作系统上的测试结果同样适用于ARM处理器Linux操作系统中，即：如果在Windows xp上编码器的编码效率从高到低的测试结果依次为：X264T264JM86，则在utu2440开发板中的测试结果同样有X264编码效率优于T264及T264优于JM86。而在Windows xp 上测试速度更快、更方便，所以选用在Windows xp 上测试，以节约开发时间。当编码器选用JM86，测试输入文件采用foreman_qcif.yuv，量化步长QP=24时，第一章 绪论 5 测试输出如图2.3、图2.4。其它测试截图不一一列出。图2.3 JM86测试输出截图 嵌入式 H.264 网络视频监控系统设计与研究 图2.4 JM86测试输出截图 三：实验结果分析 1）PSNR:相同输入格式下三个编码器的表现相差很小。不同输入格式下 JM86的 y、u、v差异稍大，X264 和 T264 差异很小，尤其是 y分量差异很小，最大差异为 2.07db。2）码率:Cif 序列的码率是 qcif 序列的三倍多，qp 越大倍数减少。3）编码速度:在同一视频序列下 x264 是 jm86 的 90300 多倍，t264 是 x264 的1.6 倍左右，对同一个编码器 qcif编码速度是 cif 的 4 倍左右，而在 t264 下，其倍数达 4.5 倍左右，说明 t264 对低分辨率序列的编码比较有效。4）分辨率提高 n 倍，为了得到相近的编码质量，输出码率和所用的编码时间也要增加近 n倍。四、实验结论 1）X264 X264 和 JM86 相比，其编码性能和 JM86 相当或更好的情况下，其编码速度可以提高 90300 倍。这体现了 X264 编码非常有效。2）T264 T264 和 JM86 相比，编码速度有了更大的提高，但其编码性能下降很大，除了第一章 绪论 7 传输带宽比较大或延时要求极其苛刻等这些特殊场合，T264(fast mode)的意义不大。3)T264high T264high在编码性能不如 X264，而且编码速度也不如 X264。总之，JM86 编码效率不如 T264,T264 的编码效率不如 X264。基于以上结论本文采用实效性更强的 X264 作为编码器。2.3.3 视频传输方案 视频传输可以选择 TCP 与 UDP。TCP（Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的运输层通信协议，通常由 IETF 的 RFC 793 说明。在简化的计算机网络 OSI 模型中，它完成运输层所指定的功能。在因特网协议族中，TCP 层是位于 IP 层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是 IP 层不提供这样的流机制，而是提供不可靠的包交换。应用层向 TCP 层发送用于网间传输的、用 8 位字节表示的数据流，然后 TCP 把数据流分割成适当长度的报文段。之后 TCP 把结果包传给 IP 层，由它来通过网络将包传送给接收端实体的 TCP 层。TCP 为了保证不发生丢包，就给每个字节一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；假如发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据将会被重传。TCP 用一个校验和函数来检验数据是否有错误；在发送和接收时都要计算校验和。TCP 协议一般不直接用来传送视频数据本身，但是对于视频传输中传输中的控制信息而言，TCP 是最合适的。UDP(User Datagram Protocol)是无连接的用户数据报协议，它由 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 的嵌入式 H.264 网络视频监控系统设计与研究 大量确认应答使视频数据不得不因为等待应答而放弃，造成不必要的延时和更大范围的数据丢失。相比较而言，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 是微软公司提供的一套底层应用程序编程接口，主要在游戏和其他高性能多媒体上应用。这些接口包括对二维和三维图形，音乐和声效，输入设备以及网络游戏等的支持。目前最高版本是 DirectX 9.015。二、DirectShow 的系统组成 DirectShow 技术建立在 DirectSound 和 DirectDraw 之上，它利用 DirectDraw 控制显卡来显示视频，利用 DirectSound 控制声卡来播放声音。DirectShow 可提供高质量的多媒体流的捕获和回放功能；支持的媒体格式很多：包括 MPEG，MP3，ASF，AVI和 WAV 等声音文件；可以从视频采集卡上捕获媒体数据流；还可以自动检测并使用视频和音频加速硬件处理速度。因此，可以充分发挥 DirectShow 的媒体功能，提高运行速度，简化媒体间的格式转换、媒体播放和媒体捕获等工作。同时，它还具有很大的灵活性和可扩展性，可以由用户创建组件，然后将这个组件加入 DirectShow 结构中以支持需要的格式或特殊效果16。DirectShow 所支持的软硬件以及应用程序与DirectShow 组件之间的关系如图 2.5 所示。第一章 绪论 9 图 2.5 DirectShow 系统框图 本系统利用 DirectShow 来播放网络传输过来的压缩 H.264 视频流。2.4 本章小结 本章根据嵌入式视频监控的特点提出了系统的总体设计方案，对构成该系统的各个模块进行了比较选择，采用迄今为止最先进的 H.264 视频压缩标准压缩视频文件，以此为基础构建一个网络视频监控平台。从而达到控制成本低，监控效果好的目的。MEMC帧内预测选择帧内预测滤波T-1Q-1TQ重排序熵编码nF当前参考重建1nFnF帧内帧间P+-+nDnDXNALnuF图 3.1 H.264 编码器框图 嵌入式 H.264 网络视频监控系统设计与研究 第四章 编码器优化及嵌入式系统实现 4.1 H.264 编码器优化 4.1.1 H.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 运动估计概述 运动估计（Motion Estimation，ME）是视频编码中普遍采用的一项关键技术，已经被广泛运用到了视频压缩的一些国际标准中，如MPEG4、H.264/AVC等。它也是消除视频数据时间冗余的最重要的方法，它的优劣直接决定编码效率和重构视频的质量34。一般而言，运动估计越准确，则补偿的残差图像越小，编码效率也就越高，在相第四章 编码器优化及嵌入式系统实现 11 同码率下的解码视频就具有更好的图像质量。但是，运动估计的计算复杂度也占据了编码器的大部分时间，为了保证视频编解码的实时性，运动估计应当具有尽可能低的计算复杂度。因此如何提高运动估计算法的性能，提高其效率，使得运动估计更快速和精确一直受到学术界和工业界的广泛关注。一般而言，运动估计包括两个部分：整数像素运动估计和由整数像素进行插值得到的最优点的分数像素运动估计35 36 37。分数像素运动估计一般采用全搜索法，1/2 像素精度的搜索点数为 8 个，1/4 像素精度的搜索点数为 16 个。因此，分数像素运动估计的计算复杂度非常重要。分数像素的引入，提高了运动估计的精度，输出图像的质量也有所改善，但运动估计复杂度大幅度增加。因此减少分数像素运动估计的计算量就变得十分必要。4.3 H.264 视频监控嵌入式系统实现 4.3.1 NFS 环境的搭建 在嵌入式 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 命令启动。#service portmap start#service nfs start#service iptables stop 开发板要共享宿主机上的文件/opt/FriendlyARM/utu2440/root_qtopia，只需要运行文件的挂载命令就可以了。和挂载本地文件系统时唯一不同的地方在于要挂载的文件嵌入式 H.264 网络视频监控系统设计与研究 系统的描述前加上远程文件系统的主机名或 IP 地址。挂载语法如下:#mount t nfs o nolock 192.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中添加命令：第四章 编码器优化及嵌入式系统实现 13 mount-t usbdevfs none/proc/bus/usb /添加 USB 文件系统/test/udisk start /添加 U 盘相应的驱动/test/auto_udisk&/后台运行自动挂载(卸载)U 盘然后重新启动。(3)插入 U 盘后，程序会将自动挂载 U 盘到 /mnt/usb：拔下 U 盘后，程序会自动卸载 U 盘。如果是手动挂载,直接用 mount 命令：mount-t vfat/dev/sda1 /mnt/usb 其中sda代表U盘，1代表第一个 usb设备，如果有多个 usb设备则分别使用sda2、sda3 等。/mnt/usb 代表挂载 U 盘到/mnt/usb 下,当然 mount 也可以接其它参数,如只读等。如果实现开机后自动挂载，Linux版本在 2.6.20 以下修改/sbin/hotplug 脚本，如图 4.6 所示：图 4.6 自动挂载 U 盘脚本 即可成功挂接 U 盘,cd /mnt，进入 mnt 目录，ls 一下，就能看到 u盘的内容了。如图 4.7 所示：嵌入式 H.264 网络视频监控系统设计与研究 图 4.7 成功挂载 U 盘图 4.3.3 视频采集模块实现 摄像头使用的是中星微的 zc0305b 芯片，该芯片网络资源很多，linux 系统对其有很好的支持，可以缩短开发周期。此外视频采集效果好，该摄像头需要 spca5xx驱动，下载 spca5xx-20060501.tar.gz然后进行解压、编译、安装。视频采集都是围绕 vdIn定义的几种重要数据结构实现的，完成基于 v4l的 USB视频采集，就要获得相关的视频采集设备的信息和图像信息，并对采集窗口、颜色模式、帧状态初始化，然后才能进行视频的采集工作44。图中图像数据处理包括视频压缩和网络传输部分，其余部分是视频采集的过程。在视频采集中，应用程序首先通过 open()函数打开视频采集设备并返回一个文件描述符号，这个文件描述符就代表了捕获的设备硬件。成功开启设备后，调用 ioctl()取的设备文件的相关信息，并且将取的信息放到 video capability 结构中，同样调用ioctl()将视频窗口信息放到 video picture 结构中。视频设备的关闭通过 close()函数实现的。下面主要介绍视频图像的获取。视频图像的获取一般有两种方法，一种比较简单的方法就是直接调用 read()，一般来说，read()通过内核缓冲区来读取数据的。另一种方法就是用 mmap()内存映像的方法获取视频45。本程序就是采用 mmap()的方式实现的。mmap()通过系统调用使得进程之间映像到同一个普通文件实现共享内存。普通文件被映像到进程地址空间后，进程可以向访问普通内存一样对文件进行访问，不必再调用 read()，write()等操作。第四章 编码器优化及嵌入式系统实现 15 采用共享内存通信的好处是效率高，因为进程可以直接读写内存，而不需要任何数据的拷贝。视频采集的流程如图 4.8 所示。图 4.8 Linux 下视频采集流程图 在获取设备和图像信息之后，调用函数 mmap()函数将设备映像到内存，map()函数的原型如下：vd-map=mmap(0,vd-mbuf.size,PROT_READ|PROT_WRITE,MAP_SHARED,vd-fd,0)然后使用操作名为 VIDEOCAMCAPTRE 的 ioctl()函数启动捕获过程，这样就完成一帧图像的捕获并将其存储到内存映像区。代码如下:vd-mmap.frame=frame;if(ioctl(vd-fd,VIDIOCMCAPTURE,&(vd-mmap)frame_usingframe=TRUE;vd-frame_current=frame;开始 打开视频设备 获取设备和图像信息 内存映射 初始化窗口和帧状态 捕获视频帧数据 终止采集？关闭视频设备 结束采集 N 图像数据处理及应用 Y 嵌入式 H.264 网络视频监控系统设计与研究 到此并没有真正的完成图像的捕获，这时使用操作名为 VIDEOSYNC 的 ioctl()函数等待动作的完成。该调用返回则表示捕获的操作结束，然后开始下一帧的捕获。代码如下：if(ioctl(vd-fd,VIDIOCSYNC,&(vd-frame_current)frame_usingvd-frame_current=FALSE;4.3.4 视频压缩模块的实现 对图像帧的编码是通过调用 X264 函数库的函数实现的。首先是下载 X264 的源代码，X264 的下载地址为：http:/www.videolan.org/developers/x264.html。这里下载的是 x264-060330.zip 下载到Linux系统上之后解压：解压之后进入源代码顶层目录，如下所示：源代码集中在 common/、decoder/、encoder/、dshow/这几个目录下面，在 build/目录下面则包含了针对不同平台的构建文件对于 Linux，这里指的是 makefile；对于 Windows，这里指的是针对 Visual Studio 的 solution文件。除了上述两种平台之外，x264 已经被移植到了 TI 公司的一款 DSP 上名字叫做 DM642。在 build/目录下可以看到有下面这样几个子目录，分别对应着不同的平台：我们是要在 Linux平台下编译，进入到 linux/目录下面。在该目录下面存在着三个文件：dependencies 中存放的是各个源文件之间的依赖关系，makefile 是管理整个项目的 make 文件，TAGS 中存放着 ctags 程序生成的 tag标记。解释一下什么是 tag：rootcyc x264#cd avc-src-0.14/avc/rootcyc avc#ls-F build/changelog.txt common/decoder/dshow/encoder/readme.txt rootcyc avc#cd build/rootcyc build#ls linux TiDM642 vc6 vc71 rootcyc x264#ls x264-060330.zip rootcyc x264#unzip x264-060330.zip 第四章 编码器优化及嵌入式系统实现 17 在诸如 vim、emacs 这样的文本编辑器中，为了能够定位源程序中的变量或者对象，需要先通过 ctags（适用于 vim）或者 etags（适用于 emacs）生成 tag文件，然后才能在一大堆程序代码中自由地跳转。除了 C 和 C+这两种最常见的编程语言之外，ctags和 etags 目前还支持众多其它的编程语言，比如 python46。在这里我们修改 makefile把 ctags 修改为 etags。因为我的编译器里没有 ctags 这个命令,ctags 和 etags 其实是同一工具在不同 linux 版本里的不同名字而已，它们的作用是相同的。编译过程中，除了需要./obj/目录之外，还需要一个./bin/目录，这里一并建好：把当前目录下makefile文件中CFLAGS=$(INCLUDE)-D_GCC_ 将其修改为：CFLAGS=$(INCLUDE)-D_GCC_-DUSE_DISPLAY。指定交叉编译工具链，CC=/usr/local/arm/4.3.2/bin/arm-linux-gcc 如图 4.9。编译整个项目，执行命令 make。如果编译出现错误，则执行 make distclean清除配置，再执行 make clean清除前一次编译生成的文件，再 make 一次。图 4.9 修改后的 makefile 文件 成功编译后，进入 avc-src-0.14/avc/build/objs/下删除 X264.o 文件。否则编译服务器端程序（server_arm.c）时会报错，至此编码器编译工作完成，接着编写服务器rootcyc linux#mkdir./bin rootcyc linux#mkdir./obj 嵌入式 H.264 网络视频监控系统设计与研究 端的网络 socket 程序，实现对编码器接口的调用，真正完成视频帧的压缩编码工作。4.3.5 服务器端程序的编写 sockets（套接字）编程有三种，流式套接字（SOCK_STREAM），数据报套接字（SOCK_DGRAM），原始套接字（SOCK_RAW）；基于 TCP 的 socket 编程是采用的流式套接字(SOCK_STREAM)。基于 UDP 采用的数据报套接字(SOCK_DGRAM)47。服务器端利用UDP的网络socket编程实现视频的传输。实现流程如图4.10所示。图 4.10 服务器端视频编码发送程序流程图 在编写服务器端程序的时候，我们把 X264 编码器初始化参数放到一个记事本里面，然后调用 fgets（）函数和 sscanf（）函数读取存放的参数。部分参数设置如图4.11 所示。SOCKET 初始话 绑定目标服务器 IP 地址 初始化 H264 编码器 初始化视频 读摄像头数据缓冲区看是否 有帧数据收到 读取摄像头数据并进行 H264 编码 把数据包送到 socket 进行发送 有数据收到 没收到数据 结束?Y 关闭 N 第四章 编码器优化及嵌入式系统实现 19 图 4.11 X264 编码器初始化参数 由于采集的视频格式为 RGB 色彩空间，在传输前还要把它转换为 YcbCr 色彩空间，这样可以降低传输和存储开销，在终端显示之前，则还需要转换到 RGB 空间。通过调用 ConvertRGB2YUV(w,h,cam_data,cam_yuv)函数实现转换。然后就可以编写 UDP 发送编码后的 X264 程序，部分关键代码如下：/*初始化编码*/void init_encoder()const char*paramfile=config.txt;init_param(&m_param,paramfile);m_param.direct_flag=1;m_x264=X264_open(&m_param);m_lDstSize =m_param.height*m_param.width+(m_param.height*m_param.width 1);m_pDst=(uint8_t*)X264_malloc(m_lDstSize,CACHE_SIZE);m_pPoolData=malloc(m_param.width*m_param.height*3/2);嵌入式 H.264 网络视频监控系统设计与研究/*采用 udp 传输经过 X264 压缩后的视频数据*/void udp_transport(int sockfd,int w,int h)struct sockaddr_in addrsrc;struct sockaddr_in addrdst;int addrlen,n;int32_t iActualLen;int raw_Pixels=w*h;float rate;/*将 sockaddr_in 结构各个成员原有的信息清 0*/bzero(&addrdst,sizeof(struct sockaddr_in);/*指代协议族,在 socket 编程中只能是 AF_INET*/addrdst.sin_family=AF_INET;/*按照网络字节顺序存储客户端 IP 地址 */addrdst.sin_addr.s_addr=inet_addr(202.193.74.217);/*调用