轨道交通视频监控子系统的研究与实现

赵军锋　李上　高晓军　杜庆伟

[摘要]轨道交通综合监控系统中的视频监控子系统（CCTV）对于轨道交通的安全运行具有非常重要的作用，首先介绍了视频监控子系统的总体架构和软、硬件体系结构，然后重点介绍了其实时监控模块的工作原理，特别是订阅，发布机制，该机制可以有效地避免重复订阅所导致的冗余视频流。基于订阅，发布机制，系统实现了序列监控的功能。最后，针对性能的不足，系统分别对视频头处理、视频数据传输等机制进行了分析和优化，取得了良好的效果。

[关键词]轨道交通；视频监控；订阅发布；模块化；序列监控

城市軌道交通视频监控系统是行车组织和客运组织重要的辅助设备，是保证运输安全、应对紧急事态的重要手段，是轨道交通综合监控系统中不可或缺的一环。对此，研究开发了不少的视频监控系统或解决方案，如文献等。本司正在开发有轨电车综合调度与控制系统（TICC），因为应用背景和要求不同，所以对视频监控进行了重点投入，实现了一套适应于大规模摄像头环境下的高性能视频监控系统，并对系统的具体实现加以阐述，

1轨道交通的总体架构

文献指出，数字视频监控系统是城市轨道交通系统中的重要网络应用，应以数字化、综合化和智能化为基础。为此，CCTV子系统采用了有轨电车综合调度与控制系统的布局，分为三级控制，如图l所示。其中实线是主要的控制，数据通路，而虚线是辅助通路。

这种架构考虑了整个结构的清晰性，三级层次分明：但是考虑到部分操作如果通过控制中心端系统来进行中转，则降低了系统的效率，所以部分控制命令是由客户端直接对车站端系统进行操纵的。

1.1系统的硬件体系架构

根据总体架构的思想，系统的硬件系统架构如图2所示。

在车站监控一级，设置一台工控机，通过高性能交换机与车站各设备相连，包括数字高清网络摄像头、NVR等。其中摄像头具有字符叠加功能，能将摄像机的日期和时间等信息进行叠加。不同于文献，本系统全部采用了远程网络进行视频数据的传输，即采用了网络摄像头，通过TCP/IP协议直接进行远程访问。NVR负责读取摄像头的视频数据形成历史视频，在规定的时间，备份到控制中心。

在控制中心，设置高性能服务器若干，进行整个监控系统的信息处理（包括事件数据接收、事件分析和处理等）。控制中心需要具有大容量磁盘控制器保存历史视频文件信息（称为视频数据库服务器），需要有实时数据库支持关键数据的处理，还要有历史数据库进行事件等的备份。以上数据库服务器下文统一称为数据库服务器。

其中实时数据库又称为内存数据库，是开发实时监控、数据实时采集等功能的支撑软件，可以获取企业运行过程中的各种数据，并将其转化为对各类业务有效的公共信息，满足对实时信息完整性、一致性、安全共享的需求，可以方便地进行系统监控和优化控制。实时数据库在CCTV子系统中同样起着重要的作用，例如，将部分运行参数、摄像头的订阅情况等信息备份在实时数据库中，当系统启动，恢复时，可以及时快速地获取相关参数，加快启动/恢复过程。

客户端由普通的PC组成，可以和控制中心，甚至车站端进行交互。

由于本系统采用专网，所以暂不考虑安全问题，没有设置网络防火墙等安全设备。

1.2系统的软件体系架构

系统采用分层、模块化设计思想，采用C/S架构，遵循以下原则：

1）两层控制：客户端、控制中心层协调运作，为操作员提供高性能的视频监控功能。

2）标准l生原则：平台采用TCP/IP、NTP等通用协议。

3）控制信令与媒体数据分离原则：便于提高控制信令和媒体的处理能力。

4）低耦合性的设计原则，各个模块独立性尽可能高，可以有效提高系统的可维护性。

其系统结构如图3所示：

1）基础/硬件平台：提供最基础的软件平台/硬件驱动程序，是整个系统的基础。

2）接口A：系统通过接口A为软件平台服务组件提供网络，硬件等的接入服务。

3）软件支撑平台：将自主开发的基础性软件模块进行归纳，形成软件支撑平台，包括数据库、通信平台等底层软件平台，以及文件传送、权限管理、告警管理等应用支撑软件平台。

4）接口B：通过接口B为上层业务提供支持，实现性软件模块与系统应用的有机整合。

5）系统应用：由多个处理具体应用逻辑的模块组成，之间保持相互独立。

6）人机界面：所有的应用通过人机界面，实现应用层次上的集成，形成一个完整的系统。

2实时视频数据采集的设计和实现

2.1订阅，分发模型的定义

实时视频监控是CCTV子系统的核心。轨道交通环境下，视频监控有着不同的特点：

1）摄像头密度大，数量众多。这对整个视频监控提出了很高的性能要求。

2）视频数据与其它监控数据通过同一个城域网进行数据传输，如果视频流数据太多，很容易对其他监控数据产生较大影响。

以上特点要求系统必须精心设计。

实时性的联机服务要求，实时视频监控必须以信息流的方式把实时采集的视频数据及时传输到客户端的播放界面。当前摄像头厂商提供的例程往往采用直连模式，即将播放屏幕和摄像头进行关联，直接播放视频。但是这种方式极易造成信息流的冗余，浪费带宽。假设n个用户同时监控相同的m个摄像头，那么就需要m×n个视频信息流同时在网络上传输，冗余度为n，极大的浪费了带宽。为此系统采用了订阅/分发模型，形成视频分发矩阵，来降低视频数据的冗余度。

定义1：视频分发矩阵，是一种数据结构，保存了视频流与客户播放屏幕的对应关系。

定义2：订阅，分发模型定义了一种一对多的依赖关系，基于中介让多个订阅者同时监听某一个实时视频对象。当视频对象产生新数据，介会通知所有订阅者对象接收新的视频数据。

系统中，由服务器承担中介的角色，对客户端的订阅请求进行监听，实时更改订阅信息。流程见图4。

通过订阅，分发模型可以将这视频产生者和视频消费者封装在独立的对象中，它们可以各自独立地改变和复用。订阅/分发模型所做的工作其实就是解耦合。这样，通过中介的一次中转，使得长距离视频数据的传输只需要一个副本，可以大大降低视频数据的冗余度，降低网络带宽的负载。

在内存以及实时数据库中，保存了所有视频摄像头的信息（classgc_DataLIst），作为全局信息，提供服务。其中包括了相关的订阅者信息，以及对应的视頻头信息。

2.2订阅，分发模型的实现

图3中，如果要登录摄像头，需要将一个回调函数注册给指定的摄像头，一旦登录完成，摄像头便利用此函数向系统返回视频头，视频，系统收到数据后才能进行相关的处理。

void CALLBACK PsDataCallBack（LONG 1RealHandle，DWORDdwDataType，BYTE*pPacketBuffer，DWORD nPacketSize，void*pUser）

其中，1RealHandle是登录摄像头后给出的句柄，用于判断是哪一个摄像头发过来的数据。

dwDataType是摄像头给出的数据类型，分为两类信息，第一类是关键的视频头信息（dwDataType==NET DVR SYSHEAD），第二类是视频本身数据。

由于视频头对于播放视频来说至关重要，不能丢失，因此把视频头作为控制命令，利用TCP协议返回给订阅者。特别的，对于第一个订阅用户，系统还无法在登录摄像头时立即获得视频头，必须等待摄像头返回其视频头。此后才能发给客户端。一般来说，只有第一个订阅者请求订阅的时候才需要，但是考虑到并发性，必须对分发矩阵中所有订阅该摄像头的订阅者进行返回。

视频本身数据，丢掉若干帧，影响不大，所以可以采用效率高的UDP协议。考虑到不同子系统（如环控、电力子系统等）和本子系统是独立的，以及实现的简单性，所以没有采用RTP协议。

在删除用户的时候，必须进行上锁，否则会导致视频分发过程中，访问已经销毁、不存在的用户节点，进而导致系统崩溃。

服务器端在处理完毕视频订阅（包括相应的登录过程）后，就可以接收到摄像头发送的视频数据，并进行后续的视频分发过程，如图5所示。

3序列监控

有了订阅和发布机制，序列监控就很容易实现了，系统在客户端定义了一个线程进行序列监控，每秒钟执行下面算法一次。for（每个播放屏幕）

{

当前摄像头的播放时间++：

if（当前摄像头的播放时间==当前摄像头的规定播放时间），//这个摄像头播放时间已结束

{

Cancel_order（当前摄像头）；

当前摄像头的播放时间=0：

if（当前摄像头是序列中的最后一个摄像头）

当前摄像头=序列中的第一个摄像头：

else

当前摄像头=序列中的下一个摄像头：

Order（当前摄像头）：

}}

4性能的优化

4.1视频头的处理

在上面的实现中，发现视频经常延迟很久才能播放，甚至产生卡住的现象，分析认为，可能是因为采用TCP传输视频头，导致视频头到达客户端迟缓过大所造成的。为此，系统进行了针对视频头的优化过程。

优化后的系统将视频头事先保存入历史数据库中，当系统启动时，读人每个摄像头的视频头信息到实时数据库，当某个客户的一个屏幕订阅一个摄像头时，先去实时数据库中获得视频头，放人播放屏幕，客户端就可以不用接收从控制中心服务器发来的视频头信息了，然后再去进行订阅，

这样的处理，视频头的获取模式，由控制中心查找视频头信息发给客户端，转变成为客户端主动去拉取视频头信息，极大地减少了视频头的等待时间，同时改变了先有视频数据，后有视频头的不正常顺序。运行表明此项优化取得了良好的效果，后续的视频数据不再产生卡住的现象，播放也快多了。

4.2播放性能的优化

实现后的系统，每秒钟只有几帧图片，视频很不连贯。在客户端改为多线程机制进行处理依然效果不佳。为此，系统进行了代码的分析和优化。

未优化的处理，每当一个视频数据到来，控制中心程序都是到gc DataLIst类中去遍历一遍，查找到摄像头后，再找到订阅者列表，将该视频数据列表中的各个客户端。而客户端则在自己的内存中遍历一个列表，找到播放屏幕号后，再把视频数据填入该屏幕。两边的遍历过程，降低了系统的处理性能，甚至导致UDP数据传输过程中的丢失。

为此，系统在客户端和控制中心服务器端分别设置了—个Hash表，在控制中心以摄像头句柄为Hash值，在客户端以摄像头编号为Hash值，省略了两端的遍历过程。该优化取得了良好的效果，视频非常流畅。

4.3负载均衡

未优化前，在控制中心，只采用了一个UDP对象来进行传输，考虑到控制中心担负着很重的负载，如果只通过一个UDP对象发送，可能会导致该UDP对象的缓存很快消耗完，为此，在控制中心设置了n（可以设置）个UDP对象，根据（摄像头编号mod n）来确定使用哪一个UDP对象进行传输。实现了简单的负载均衡。

在大规模验证环境下，系统没有表现出视频卡、顿的情况，表现依然流畅。

5结束语

介绍了视频监控子系统的总体架构，分为三个层次，分别是车站端系统、监控中心端系统和客户端系统。基于总体架构，规划了系统的软、硬件体系架构，然后重点介绍了视频监控子系统中重要的模块——实时监控模块的工作原理，特别是其所采用的订阅，分发机制，该机制可以有效地避免重复订阅所导致的冗余视频流。基于订阅/架构机制，视频监控子系统还实现了序列监控的功能。最后，针对初步实现的系统所表现出的性能不足，系统分别对视频头处理、视频数据传输等机制进行了分析和优化，取得了良好的效果。

[责任编辑：王伟平]