无线视频监控系统中分发服务器的研究及实现

2013-08-13曹型兵

电视技术 2013年13期

曹型兵，李津，薛萌

(重庆邮电大学a.通信工程应用研究所;b.通信新技术应用研究所，重庆 400065)

责任编辑:任健男

随着监控系统的大量应用，监控系统的功能越来越多，结构越来越复杂，从而传输的信息量急剧膨胀，传统的监控系统对于如此庞大的信息量，暴露出越来越多的局限性，总体而言，可以归纳成为:1)网络带宽有限性和用户数不断增加。每个用户都可能向多个监控点请求实时视频，每个监控点也可能向多个用户传输实时视频，这样就出现了多路重复传输的视频，势必造成信息量的增加。在广域网中，可能会出现网络拥塞。2)用户的动态性增减对监控系统的影响。用户在接收视频数据之前要先向监控点进行视频请求，当同时请求的用户数达到监控点处理的最大值后，视频网络传输量也会大量增加，从而导致图像质量严重下降，出现丢包、图像抖动等现象。

为了解决上述问题，本文研究设计了视频分发服务器，该模型可以较好地保证用户的视频图像质量，有效减少上述不良现象的出现。

1 无线视频监控系统的组成

无线视频监控系统结构图如图1所示。

摄像头是无线视频监控系统最前端的组成部分，负责视频数据的采集，然后通过有线传递给视频服务器，构造复杂的摄像头叫做云台，方向可转动，进行多角度监控。

图1 无线视频监控系统结构图

本系统的视频服务器采用了TI公司的DaVinci［1］解决方案，主要用来处理摄像头传输过来的原始视频数据，摄像头采集到信息后直接交给视频监控终端，视频监控终端进行H.264编码［2］和封装数据，并通过无线网络发送数据流到转发服务器。

转发存储局域网是整个有线传输的核心，转发即把接收到的视频服务器发过来的数据分发到多个客户端，如果客户有录像请求，则把数据发送到存储服务器，这两个过程并不矛盾，可以同时进行。

客户端即客户使用的设备终端，包括计算机、电视墙等，向上文所述的各个服务器发送指令，进行指定功能的实现。

2 视频转发的思路分析

在分析视频转发可行性之前，有必要先对视频帧的结构进行分析，视频帧由多个RTP包组成，相同RTP包的时间戳是相同的，相邻视频帧的时间戳［3］相差一个固定数值，相同帧的每个RTP包的序列号不同，且在视频帧中依次递增，视频帧的最后一个包存在一个mark位，用来区分不同的帧。

视频数据被视频服务器从摄像头采集，视频数据通过H.264编码［2］被打包成RTP包格式，然后对RTP包进行UDP封装，最后以视频服务器把视频数据以UDP包格式发送给转发服务器。由于网络环境的不稳定，转发服务器必须向视频服务器对接收到的视频流的质量进行反馈，这需要用到与RTP相对应的RTCP协议。转发服务器向客户端和存储服务器传输数据流是以UDP包封装的RTP包格式，故用到UDP［4］和RTP协议。转发服务器与系统中其他部分间的协议交互如图2所示。

图2 转发服务器与视频监控系统中其他部分间的协议交互图

客户端对视频数据的请求可能实时更新，存在同时传输多路视频的情况，由于请求的不确定性和多路视频流转发同时转发的可能性，采取单线程轮询的方式是不合适的，因此本设计决定采用多线程的方式。一个主线程负责处理转发信息，多个子线程根据转发信息开启或关闭，从而达到多路视频同时转发，每个子线程转发一路视频到多个目的IP的目的。

视频流在转发服务器中以RTP包为基础重新打包，这时候转发的只是RTP负载，RTP头会重新添加，因此所有包的时间戳都是相同的［5－8］。客户端和存储服务器接收到RTP包后进行后续的排序组帧，根据前面所述，相同帧的所有包的时间戳是相同的，相邻帧的RTP包的时间戳相差一个固定值，即通常所说的时间戳增量。时间戳应该由RTP包头的mark位决定，遇到mark位后，下一个RTP包增加一个时间戳增量［3］，时间戳增量由以下公式决定

式中:FrameRate为帧率，本设计采用最常用的25帧/秒(f/s);ClockFrequency为时钟频率，本设计采用90 kHz，根据计算可得时间戳增量为3 600。

3 视频转发的具体实现

3.1 以控制子线程启闭为目的的主线程的实现

主线程操作流程图如图3所示。

图3 主线程操作流程图

主线程操作流程步骤为:

1)建立一个全局分发信息数组，该数组的元素是一个包括iFlag，iPos和iCount的结构体。这是为了提高子线程运行时更新分发信息的效率。当子线程的分发目的信息有改变时，子线程可以根据iFlag的值第一时间获得该变化，根据iPos和iCount快速获得分发目的信息在分发链表中的起始位置和数量。

2)建立一个线程作为主线程，此线程一直保持开启状态，直到程序最终关闭。

3)定义一个定时器，以保证对数据库的定时扫描。该定时器时间间隔根据实际情况设定，以500 ms～2 s为宜，本设计设定为1 s。

4)主线程定时扫描数据库，以获取包括分发目的端口号和IP的分发信息。

5)进行分发信息的对比，以更新分发子线程的转发目的或启闭分发子线程。这是最复杂的一个步骤，本设计自定义了一个算法进行实现，该算法包括两部分:当前与上次获得的分发线程转发目的信息的对比，当前与上次获得的分发线程启闭信息的对比。第一个对比通过对分发信息链表的端口和IP地址的组合数据进行排序、差分计算、链表更新等几部分实现，第一个对比与其类似，只是对比元素换成了端口号，且必须去掉重复元素。这一步骤保证了视频分发的实时更新，提高了执行效率。

6)根据分发信息对比结果进行子线程启闭以及子线程转发目的的更新。线程开启采用常用的WINAPI函数CreateThread［9］，线程关闭采用了更改标记位，运用返回值的方式。线程开启所用的端口号参数通过建立vector，并以依次获得的方式进行传递。当上述流程结束后，一个循环结束，等待定时器到达，以继续另一个循环，即重复步骤4)～步骤6)。

3.2 视频转发子线程的实现

视频分发子线程的流程图如图4所示，具体步骤如下:

1)建立RTP会话。视频传输是以RTP包为基础的，建立RTP会话可以建立视频服务器和转发服务器之间的连接，形成一条传输RTP包的通道。

2)设定RTP会话所需的各种参数，包括设定自己的时间戳单元、是否接收RTP数据包、设定接收RTP包的接收端口等。

3)进行RTP会话检错。主要检测当前端口是否被占用以及传输的RTP包大小是否超出RTP会话传输的最大值。RTP会话允许的传输最大数据包大小默认为1 400 byte。

4)看该线程是否应该终止，如果符合终止条件，关闭该线程，本设计关闭线程采用返回值的方式，否则直接执行下一步。

图4 视频分发子线程操作流程图

5)接收视频服务器发送的RTCP格式的sr包，通过一系列的计算获得丢包率、累计丢包数、接收到的扩展的最高序列号以及到达时间间隔抖动(IJ)的参数。其中IJ根据公式计算得到，计算方法如下:假定Si是包i中的RTP时间戳，Ri是包i到达时刻。对于2个包i和j，到达时刻抖动［10］根据公式 J=J+(|D(i－1，i)|－ J)/16计算，其中D为当前包和前一包(i－1)的偏差，可以用公式D(i，j)=(Rj－Sj)－(Ri－Si)获得。计算完上述参数后，封装成RTCP格式的rr包，然后发送给视频服务器。视频服务器根据接收到的rr包对视频流的发包速率、发包大小等参数进行调整，以使视频更流畅。

6)进行转发目的IP和端口的设定，可进行自身的转发。自身转发可把目的IP设为127.0.0.1，目的端口根据自身需要增加一个值。接收数据源，并转发RTP包。转发的RTP包的时间戳根据mark位进行设定，如果接收到的当前包无mark位标记，该包的时间戳增量为0，否则，该包的时间戳增量设为3 600，即该包的下一包的时间戳增加3 600。

7)删除刚刚转发的RTP包。这样做是为了节约内存，采用jrtplib自带的DeletePacket函数实现。

8)RTP会话结束，关闭该会话。通过发送RTCP的bye包结束该RTP会话。

4 运用该转发机制前后视频效果的对比

本文是在Windows系统下，以VC++6.0为开发平台，用C++语言进行开发的，因为使用了成熟的WINAPI函数和JRTPLIB库函数，所以该程序具有比较好的稳定性。

转发前后均采用了VLC播放器进行解码播放，图5和图6是直接对同一时间、同一场景的转发前后的视频截图对比。从播放效果来看，转发前后视频均播放流畅，没有明显差异，转发之后视频未出现马赛克效应，用wireshark抓包发现，转发前发送5 000个包，转发后接收到4 955个，丢包率仅为0.9%，在不影响播放效果的情况下，这属于正常范围。不足之处在于，转发后视频存在1～2 s的延时，在一般情况下这是允许的，但是在要求严格的特殊情况下，这种延时是要予以解决的。