本文提出了一个嵌入式MPEG4 多媒体监控系统。该系统在32 位高性能ARM 嵌入式处理器与Linux 操作系统基础上设计实现，支持客户机/服务器工作模式，实现了四路音、视频数据的实时MPEG4 编码、网络广播与硬盘录像。
1. 引言
随着科学技术的日益进步，采用高科技手段来保障安全、打击犯罪已经成为各个领域的共识。监控技术的发展一直是人们关注的应用技术热点之一，它以其直观、方便、信息内容丰富而被广泛应用于如交通、银行、仓库、通信机房等许多场合。目前监控系统向着数字化、网络化方向发展已经成为行业共识，并逐渐成为市场的主流，网络化的视频监控系统是传统安防与网络通信技术结合的产物，其组成可分为前端的硬件和后端的网络软件系统，要想真正的完善一个网络平台的数字视频监控系统，需要长期专注投入与不断升级完善。
2. 音视频压缩技术及国际标准
传统的模拟闭路电视监控系统有其局限性：首先，有线模拟视频信号的传输对距离十分敏感，当传输距离大于1km 时，信号容易产生衰耗、畸变、群延时，并且易受干扰，使图像质量下降；其次，有线模拟视频监控无法联网，只能以点对点的方式监视现场，因而布线工程量极大；最后，有线模拟视频信号数据的存储会耗费大量的存储介质(如录像带)，查询取证时十分繁琐。
数字化视频监控的优点正好克服了模拟闭路电视监控的局限性：首先，数字化视频可以在计算机网络（局域网或广域网）上传输图像数据，基本上不受距离限制，信号不易受干扰，可大幅度提高图像品质和稳定性；其次，数字视频可利用计算机网络联网，网络带宽可复用，无需重复布线；另外，数字化存储成为可能，经过压缩的视频数据可存储在磁盘阵列中或保存在光盘中，查询十分简便快捷。因此监控领域必将从模拟迈向数字，这是一个不可逆转的趋势，也是监控领域的革命性飞跃。
目前市面主流压缩算法标准也不少，主要有ISO（国际标准化组织）的MPEG 系列和ITU （国际电联）的H 系列。JPEG 技术视频分辨率较高，任何情况下都不会出现马赛克，是欧美的主流标准，但占用带宽过高，不适合在网络上传输。MPEG2 标准特性与其类似。
H.263 是ITU 为64K 窄带信道制定的极低码率编码标准，对带宽要求较低，但图象质量较差。
MPEG4 是基于对象编码的一种压缩标准，可以实现高效率的编码，在相同图象质量情况下，MPEG4 只需要MPEG1、MPEG2 一半的带宽。而且储存容量小，适合于大量录象场合。
H264 与MPEG4 使用场合类似，在压缩还原上又有突破，效果更好。但算法更为复杂，编解码占用资源更多，可能引起系统延时加大，而且目前处于开发阶段，没有现成的ASIC实现。
经过比较，视频编码方面采用MPEG4 标准，采用较低的带宽获得令人满意的质量。音频编码方面采用ADPCM 标准，8K 采样率满足的语音通信的基本需要，市场上作好的多路Codec 种类极多，成本也很低。
3. 系统总体结构
早期的数字监控系统把模拟视频信号由同轴缆传回到主控室，经视频采集压缩卡阵列压缩后，存储到硬盘设备上。而今的发展趋势是研究以嵌入式方式将模拟视频信号数字化及研究符合压缩协议的视频流并打包成网络传输流，这样可以方便地接入局域网，实现灵活的数字监控技术 。
现有的几种MPEG4 格式的视频服务器大多为工控机插卡工作方式，成本高，可靠性差。Intel 公司推出的Xscale PXA-255 处理器工作在400MHz 下，有很强的处理能力，加上外围电路就可以完成过去一台PC 才能完成的功能。能够驱动网络控制器直接在IP 网络上发送压缩好的多路音视频数据，也能在总线上直接驱动IDE 硬盘完成DVR 硬盘录象机的功能。系统集成度高、体积与功耗都很小、可靠性好、成本低，是理想的选择方案。
本系统总体采用目前比较流行的C/S （客户端/服务器）结构。对于敏感的数据和控制信息，要求用户用专用的客户端程序登陆服务器认证后发送和接收，同时也可以用客户端软件来完成诸如系统设置或云台控制等功能。该系统只需要把嵌入式监控前端设备（体积和功耗都很小）放置于监控现场，便可以实现4 路高解析度的音视频实时监控与录象，整个系统结构如图1。
图1 嵌入式监控系统示意
在图1 中，红色虚线之内表示监控现场的设备。采集来的音视频数据实时单播/组播/广播到本地局域网络上，同时该视频的一个拷贝也以压缩录象的形式保存在本地磁盘阵列中。本地监视器主要用于本地管理人员实时监看系统工作状态，并通过红外遥控器和OSD 菜单调整系统参数。该前端系统框图如图2。
图2 嵌入式监控前端硬件总体框图
4. 服务器端软件的实现
服务器端程序是整个软件系统的核心。它工作在用户空间，通过访问设备文件读取MPEG4 码流，再按照其维护的当前连接列表转发给正在收看的用户，同时也可以将各路视 频录制成为avi 文件存储在IDE 硬盘上，向用户提供历史记录FTP 下载。
由于系统中很多任务需要同时进行，而且在沉重的后台处理负荷之下还要保证对接入用户响应的迅捷，需要采用多线程技术。多线程的程序一般需要与特殊的库进行链接，因此首先要编译出所有支持库的多线程版本，而不能与非线程版本的库进行链接。其次，还要协调各个线程之间的关系，在两个线程同时希望访问同一个数据时，对数据进行保护是很必要的。通过使用互斥区域的办法解决，一个线程可以锁定互斥量，并且在它锁定之后，其它线程就不能再锁定这个互斥量了，试图这样做的线程都会被阻塞直到互斥量被释放。这样就确保则资源调用的串行化。
各线程工作流程见图3 与图4。主程序开始的时候，打开IME6400 设备文件，初始化IME6400，FPGA 和SAA7114，之后依次启动三条工作线程。三条工作线程并行执行，其中控按权限选择连接方式，对于控制连接，交换控制信息；对于数据连接则传送制线程在TCP服务端口监听，发现连接请求便要求其验证身份。合法用户媒体信息，并把点对点用户登记在用户列表中。
图3 数据获取线程和数据发送线程工作流程
图4 控制线程以录象、发送模块
数据获取线程直接从IME6400 设备文件中读取压缩好的帧数据。如果数据还没准备好，则该读取调用将会被阻塞。读到数据后申请一块Buffer空间保存之，并进行必要的检查，以确定数据的有效性，同时为数据帧打上时间戳，用来为日后的回放提供参考时间，最后把指向合法数据块的指针推入指针队列。
发送线程以阻塞模式读取指针队列中的内容，得到数据帧后，对数据区域进行分析，获得必要的媒体信息，最后按照系统的设定调用录象模块和播放模块完成最后的处理。
5. 客户端软件的实现
程序总体上采用SDI（单文档）结构，系统采用Document（文档）来处理所有的数据信息，采用View（视）来向用户显示结果，采用MainFrame（主框架）来处理用户的命令，然后再分配给Document 或View 等结构进行处理。而且在Document/View 结构下，所有菜单、工具条的支持都是内建的，我们只需填充需要的函数，十分方便。
系统要同时完成四路视频、音频接收、解码、播放等工作，还要绘制UI 界面、同用户交互、与服务器通信，任务十分繁重。为了更好的分解任务，同时避免沉重的处理负担影响UI 响应的迅捷，程序依然采用多线程结构。由主线程负责UI 的绘制与用户操作的响应，同时还有TCP 控制线程负责用户的命令连接；UDP 数据线程负责用户的数据连接。此外系统插入了第四章设计的控件的四个实例，每个实例实现需要3 个线程，不过这些已经由控件封装良好，在主程序里不必操心。各个线程执行流程如图5 和图6。
图5 主程序工作流程
在主线程里进行初始化，当用户单击“打开网络”按钮的时候，系统分析消息，调用 OnOpenNet()函数，开始TCP 控制线程。
图6 控制和数据线程工作流程
在TCP 控制线程开始的时候初始化Socket，发送连接请求，完成身份验证后，等待服务器命令。每当收到命令的时候，分析命令的合法性并对有效的命令加以执行，发送命令应答，完成媒体参数的设置以及连接方式的协商。一切准备就绪后，启动UDP 数据线程。此时根据连接的种类决定TCP 控制线程的工作状态。如果是广播或者组播方式，则控制线程立刻断开TCP 连接并返回，以节约系统资源。如果是点对点连接方式则保持连接，继续监听服务器命令。
在UDP 数据线程启动的时候初始化Socket 并按照需要加入组播分组，监听协商好的连接端口。然后初始化接收缓冲区与接收状态机。每当收到一个数据包的时候，读出其头部，验证帧类型与序列号，进行差错检查，丢弃出错的帧并填零，最后把收到的数据发送给对应通道的播放控件。当收到结束命令的时候，释放缓冲区、关闭Socket 并退出线程执行。
6. 系统测试与结果讨论
模拟网络畅通与拥塞的情况为需要播放媒体数据打不同种类的时间戳，记录播放控件对音视频同步的调节情况。
将视频服务器和作为测试端的PC 机都连接到以太网，配制好网络参数。让服务器广播不同分辨率，不同频道的MPEG4 码流，记录PC 机的接收情况。再用PC 机用FTP 协议登陆服务器，下载服务器上MPEG-4 码流的历史记录到本地播放，记录服务器录制MPEG4 视频文件的情况。
打开录象检索界面，搜索指定通道的全部录象与指定时间范围的录象，下载所选择的录象，记录服务器的响应情况。
首先启动视频服务器，再给服务器设置IP，然后服务器以广播的方式向外发送数据。客户端用户使用客户端软件，点“打开网络”按钮，输入服务器IP地址，然后就可以接收到的从视频服务器播放出来的视频图象数据了；客户端用户也可以点击“打开文件”按钮，通过打开播放下载到本地硬盘的视频文件。测试结果见表1：
表1 播放测试结果
通过对这个系统的测试，我们可以看到本系统已经实现系统设计中所需要的功能，并且各个功能模块之间能很好的融合兼容，在测试过程中视频流基本稳定，图像效果比较不错，播放时延较短。音频播放平滑，几乎没有停顿与爆音，与视频同步良好。录象检索因为采用HTTP 方式，速度稍慢，不过还可以容忍，录象下载迅速，播放流畅。
本文转自 fanxiaojun 51CTO博客，原文链接：http://blog.51cto.com/2343338/440185，如需转载请自行联系原作者
