基于动态策略的网络视频监控系统

刘晓妮，卢奕南，潘 明，袁天文

（吉林大学 计算机科学与技术学院，长春130012）

0 引 言

随着社会的进步，网络视频监控越来越被广泛地应用到各个领域。文献［1］提出了一个基于改进的H.264的视频监控系统。目前主要通过缩小预测模式选择范围［2］的方式降低帧内预测模式选择算法复杂度。文献［3］通过宏块的边缘点预测边缘方向，在帧内预测模式中，选择与该预测方向相同的模式。文献［4］首先根据预测方向进行分组，通过先计算出来的分组率失真和帧内预测方向的相关性，对剩余的预测方向中可能性小的模式不再计算，从而降低算法的复杂度。同时，很多学者对基于TCP的网络多媒体也进行了大量的研究和改进［5］，林志勇等［6］分析了3G 网络视频传输中引入自适应调整码率的必要性，提出了一种基于改进的AIMD 算法来调整视频码率的流量控制算法。左冬红［7］提出了一种面向TCP流媒体传输的编码码率自适应算法（TCP＿RA），该算法根据流媒体发送应用层缓冲区读写指针差值调整流媒体发送端的编码码率适应网络带宽的变化。廖顺和［8］探讨了视频监控系统在城市轨道交通安全等领域的应用，并重点介绍了H.264编码标准和码率控制基本原理。

本文采用动态策略，基于宏块特征，实现帧内预测模式的动态选择，并且分析网络状况信息，计算当前网络支持的最大传输码率，自适应地调整服务器的输出码率，从而提高编码效率以及网络的利用率。

1 关键技术

1.1 帧内预测模式的动态选择算法

1.1.1 帧内预测模式

帧内预测是利用当前待编码宏块周围的已编码并重建的宏块预测当前宏块的值。亮度块帧内预测根据亮度块大小分为16×16和4×4两种。

16×16亮度预测模式包括4 种不同的预测模式。如图1所示，垂直预测模式是通过上一行的像素点得到待编码宏块的像素值；水平预测模式通过左一列的像素得到宏块的像素值；DC 直流预测模式通过上一行和左一列的像素均值得到宏块的像素点；平面预测模式利用“plane”函数、左一列像素点及上一行像素点得到宏块的像素点［9］。

图1 16×16亮度预测模式Fig.1 Brightness of 16×16prediction model

4×4亮度预测模式由8 种不同方向的预测模式和DC 直流预测模式组成［9］。图2为除DC预测外的8种预测模式的方向。

图2 4×4预测模式的8种不同方向Fig.2 4×4prediction of 8different directional patterns

1.1.2 动态选择算法

采用基于宏块特征和缩减预测模式选择范围的思想，实现帧内预测模式选择速度的提升。首先根据宏块特征对4种不同的16×16亮度预测模式进行判断，选出能够满足宏块特征的16×16帧内预测模式。如果没有能够满足的，根据宏块特征选择合适的4×4亮度预测模式候选集，最后根据遍历候选集中的亮度预测模式，求得最适宜的亮度预测模式。

本文对宏块特征的计算受到了文献［10，11］的启发。对4种不同的16×16亮度预测模式分别进行分析，垂直预测模式计算待编码宏块的像素点在垂直方向上的平滑度，这里采用方差来衡量平滑程度：

式中：p（x，y）为宏块（x，y）处的像素值；my为宏块第y 列像素点的均值。

水平预测模式计算水平方向上的平滑度为：

式中：mx为宏块第x 行像素点的均值。

DC预测模式计算宏块整体的平滑度为：

式中：mxy为宏块的所有像素点的均值。

平面预测模式适用于水平或垂直方向有倾斜纹理的图像。这里分别使用两条对角线及周围的像素点的方差来预测平面模式的适用程度，公式为：

式中：ml为宏块左上到右下对角线上像素点的平均值；mx0为宏块从（x，0）点出发到底边的与对角线平行的斜线上像素点的平均值；m0x为宏块从（0，x）点出发到底边的与对角线平行的斜线上像素点的平均值。

式中：mr为宏块右上到左下对角线上像素点的平均值；m′x0为宏块（15－x，0）点出发到上边的与对角线平行的斜线上像素点的平均值；m′0x为宏块从（0，x）点出发到上边的与对角线平行的斜线上像素点的平均值。

得到4种16×16的亮度预测模式的宏块特征的计算公式之后，需要确定阈值来决定该16×16亮度预测模式是否适用，并且确定采用何种具体模式，即依次比较var＿dc、var＿v、var＿h与三个阈值大小来确定DC、垂直和水平三种模式之一。对于平面模式的选择，是进一步地将var＿l、var＿r与两个阈值比较大小，满足其中一个条件就可以确定。若16×16模式不适用，则在4×4亮度预测模式候选组中选择开销最小的亮度预测模式作为最佳模式。通过比较4 个候选组｛0，5，7，2｝、｛1，6，8，2｝、｛4，5，6，2｝、｛3，7，8，2｝对应的var＿v、var＿h、var＿l和var＿r值，选择值最小的对应组作为候选组。

由于16×16的预测方向在4×4中同样会进行预测，仅选择可能性较高的模式作为当前块的候选模式，这样可以在很大程度上减少帧内模式的计算量。采用16×16预测模式中的预测方向对4×4预测模式进行分组，同时根据16×16的结果在4×4的预测模式中选出一组预测模式作为候选组，再在候选组中选出最佳的预测模式即可。由于DC预测是在任何条件下都能使用的预测模式［2］，于是将DC 预测加入到所有组中。接下来直接使用X264中提供的方法计算候选分组中的各个模式的代价，选择出代价最低的预测模式作为最佳预测模式。

1.2 基于网络状况的码率自适应算法

1.2.1 传输速率调整方式

目前，根据网络状况进行传输速率调整的方法主要包括基于试探和基于预测两种［12］。由于基于试探的传输速率调整方式在网络状态发生改变时速率改变过大，会引起比较明显的网络波动，对实时性要求较高的视频数据的传输非常不利，所以本文选择基于预测的传输速率调整方式作为拥塞避免阶段的码率自适应方法。这种方法主要根据网络模型，使用预测公式来预测网络的有效带宽。当前应用最广泛的是文献［13］中提出的计算公式，如下：

式中：br 为传输速率；RTT 为往返时间；RTO 为重传间隔，取4 倍的往返时间；Ploss为丢包率；PacketSize为发送的数据包的大小。

1.2.2 码率自适应算法

本算法所需参数主要依靠由接收端周期性向发送端发送的接收端报告RR 数据包。RR 包是RTCP数据包的一种，其中包含了间隔抖动、已接收报告数、累计丢包数等重要参数。服务器根据这些参数计算检测当前网络状况，并根据检测结果进行码率的自适应调整。本文的码率自适应算法主要使用丢包率Ploss和传输的往返时间RTT。

计算丢包率Ploss首先需要获取RR 数据包中的fraction lost字段，并将该字段数值除以256。往返时间RTT 的计算公式如下：

式中：T＿rev 为接收到该RR 包的时间；LSR 为RR 包中最新SR 的时间戳；DLSR 为从最新SR到发送RR 的时间间隔。

基于网络状况的码率自适应是为了避免网络拥塞，而TCP协议对于网络拥塞进行的控制算法又是成熟而且得到实践检验的，所以本文受到TCP协议的启发，对数据传输过程细化为慢启动和拥塞避免两个阶段。

（1）慢启动阶段。在此阶段，将TCP 协议的慢启动思想应用到监控视频开始的传输阶段。通过量化参数QP 的动态改变来实现码率的调整。QP 值越大，码率越小，图像的质量越差，从图像质量和性价比的角度考虑，设置QP＿MAX 和QP＿MIN 为量化参数最大值和最小值。

首先初始化QP ＝QP＿MAX，然后根据RTCP包反馈的丢包率Ploss进行操作选择。当Ploss＝0时，使用公式：

进行QP 的调整（QP′为QP 的均值，τ为参数），由于QP 越大，发送到网络上进行传输的视频数据量越少，网络状况也就越好，QP 的变化速度在QP 越大的情况要快一些，所以设定的QP 变化公式中随着QP 值变小，QP 变化速度是减慢的。否则，QP 不变，统计接下来连续5个RR 包中有3个丢包率非0或者QP 减小到QP＿MIN，则进入拥塞避免阶段。

（2）拥塞避免阶段。当本算法码率与网络带宽达到适应后，进入到拥塞避免阶段。根据网络状况的变化进行码率的自适应调整。

首先，根据求出的传输速率br 可计算得到当前网络状况满足的起始帧量化参数start＿qp［14］：

式中：a、b、c为常系数。

再根据start＿qp 和THR 对QP 的值进行调整，当start＿qp＜QP－THR 时，说明网络处于轻载状态，需要降低量化值，QP 取start＿qp 和QP＿MIN 中较大值。当start＿qp ＞QP ＋THR时，说明当前网络处于过载的状态，需要提高量化值，QP 取start＿qp 和QP＿MAX 中较小值。

当QP－THR ≤start＿qp ≤QP＋THR 时，说明网路处于满载状态，无需改变编码量化值。其中，THR 是调整QP 的阈值。设置THR 的计算公式为：

式中：κ为参数。

从式（8）可以看出，当丢包率为0时，无法预测网络的有效带宽，所以当本系统收到第一个丢包率为0的包，量化参数不变，当收到后面连续丢包率为0的RR 数据包，再收到后续的丢包率为0的RTCP包后，则利用式（10）减小QP 的数值，从而提高网络带宽的利用率。

2 网络视频监控系统结构

本系统采用C／S 架构，主要由摄像头、服务器以及分别用于Windows系统和Android系统的客户端组成，如图3所示。

图3 网络视频监控系统结构图Fig.3 Structure diagram of network video monitoring system

首先，服务器驱动摄像头读取监控视频，然后服务器对监控视频进行压缩编码处理；当存在客户端通过RTSP 协议与服务器建立连接且向服务器发送了监控视频播放请求时，服务器通过RTP协议向客户端发送视频数据，客户端接收到视频数据后进行解码播放；在连接已建立期间，服务器与客户端周期性地相互发送RTCP包，使两端都能了解到当前的网络状况，本文根据这些网络状况信息对编码器的输出码率进行调整，实现基于网络状况的码率自适应调整。

3 系统各功能模块的实现

3.1 服务器的设计实现

本系统服务器主要包括4个部分，如图4所示。

图4 系统服务器结构Fig.4 Structure diagram of system server

首先，服务器利用Linux关于视频设备内核驱动V4L2（video4linux2）提供的接口，编写驱动程序驱动摄像头读取视频数据，再对视频数据进行压缩编码；由于本系统编码器是基于开源的H.264编码器X264实现的，且X264要求输入的视频每帧图像都为YUV420格式，所以在编码前需要将读入的YUYV 图像格式视频数据转换成YUV420。然后，将转换X264 分别对每帧YUV420格式的图像进行编码，编码后即可得到标准H.264格式的视频数据。将编码后的视频数据保存到服务器中作为回放的视频数据，同时在有用户请求实时监控视频时，通过开源流媒体服务器Live555将内存中的视频数据用于发送给用户。

X264和Live555作为开源的解决方案面向的对象是视频文件，而本系统需要实现的是实时视频数据的处理，所以本系统对它们的输入部分分别进行了修改。同时由于这两个开源项目是相互独立的，而本系统需要它们作为服务器整体的两个部分，所以本系统通过多线程的方式对它们的工作过程进行调整，使用外部变量将使Live555能够获得X264编码后的视频数据。

3.2 客户端的设计实现

本系统客户端以开源项目VLC 为基础，同时实现了Windows和Android两个平台下的客户端播放器。首先对VLC 进行编译，生成可调用的库文件，然后通过调用VLC 库函数实现客户端的整体功能。

Windows系统下VLC播放器的编译需要在由Cygwin仿真得到的Linux 环境下进行，图5为编译过程。

图5 Windows系统下VLC编译过程Fig.5 VLC compilation process in Windows system

图5 中第4 步需要清理的第三方库提供的Linux可执行文件都位于／usr／win32／bin文件夹中，它们是moc、rcc和uic。第5步中源码和第三方 库 存 放 的 位 置 为／cygwin／home／username（username为登陆的用户目录）。经过最后一步make package－win32－base后，即可得到客户端实现 所 需 的 动 态 库 文 件libvlc.dll、axvlc.dll、libvlccore.dll和npvlc.dll，同时还生成了VLC的插件库。

对于本系统中Windows系统下的客户端的实现，首先需要创建一个MFC 的工程；然后，将VLC的核心库、插件库以及客户端实现所需的头文件都加入到项目中；接下来即可基于VLC 和MFC进行代码实现。

客户端的代码实现过程如下：

（1）调用libvlc＿new 函数创建并初始化一个libvlc对象。

（2）调用libvlc＿media＿new＿path 函数根据libvlc对象和媒体路径（可以是多媒体文件的文件存储路径，也可以是流媒体文件的网络路径，如：rtsp：／／192.168.3.111／test.264）创建可播放的媒体对象。

（3）调用libvlc＿media＿player＿new 函数，根据libvlc对象创建播放器对象。

（4）调用libvlc＿media＿player＿set＿media函数，将播放器对象与媒体对象进行连接。

（5）获取播放窗口的句柄，调用libvlc＿media＿player＿set＿hwnd将播放器对象与播放窗口进行关联。

（6）调用libvlc＿media＿player＿play函数，发送播放命令，接收视频数据进行播放。

以上就是基于VLC实现Windows系统下客户端的主要步骤，并且这些步骤有严格的先后顺序。

4 实验结果及分析

将未被修改的X264编码器与采用帧内预测编码算法的编码器进行编码性能对比，选定峰值信噪比、编码速度和输出码率作为性能对比参数。ΔPSNR 为峰值信噪比增量百分比，ΔV 为编码速度增量百分比，ΔBR 为输出码率增量百分比，公式如下：式中：old和new 分别表示未被修改的X264编码器和采用本文算法修改的编码器得到的数据。

测试用例选用5 个常用于测试的CIF 格式视 频 序 列，包 括bridge－cif.yuv、coastguard－cif.yuv、hall－cif.yuv、highway－cif.yuv、silent－cif.yuv。本次测试将编码的量化参数设置为跨度适中且能较好地反映编码器性能变化的3个值：20，30，40，同时设置QP＿MAX ＝45，QP＿MIN ＝25，τ＝1.5，κ＝20。

从表1可以看出：本文的帧内预测模式选择算法在编码速度上提升明显，而编码质量和输出码率都只受到了比较小的影响。

在不同网络带宽状况下，将无码率自适应算法与本文基于网络状况的码率自适应算法进行码率对比。该测试在同一个内网下的两台计算机上进行，因此网络状况可以得到保障。本文对采用码率自适应算法的服务器与使用固定编码量化参数分别为25、35和45的服务器输出码率的状况进行了对比。同时，在第75、130、175s三个时间点，将网络的流量限制分别设置为1000、500、1000kbit／s，测试在网络状况发生变化时本文的码率自适应算法的响应情况。

表1 量化参数为20、30和40的性能比较结果Table 1 Performance comparison results of quantization parameter 20，30and 40

如图6所示，本文算法能够较快地达到较高的传输速率，同时对网络状况的变化反应也能够较快地做出回应。在慢启动阶段，由于有足够的网络带宽支持，本文算法能够较快地得到量化值的下限，然后进入拥塞避免阶段。在拥塞避免阶段，对于网络带宽迅速下降和上升，本文算法都能做出较快的反应。

图6 码率自适应算法与固定编码质量的传输速率对比Fig.6 Transmission rate comparison between rate adaptive and fixed coding quality algorithms

5 结束语

本文结合H.264视频编码技术和RTSP 协议等流媒体技术，实现了网络视频监控系统。针对编码效率和网络资源合理化利用的两点不足，提出了帧内预测模式的动态选择算法策略和基于网络状况的码率自适应策略。实验结果验证了方案的可行性，并收到了较好的监控效果，实现了网络视频监控。

［1］毛剑飞，张杰，蒋莉，等.基于改进的H.264的视频监控系统［J］.计算机系统应用，2014，23（4）：84－90.Mao Jian－fei，Zhang Jie，Jiang Li，et al.Video monitoring system based on improved H.264［J］.Computer Systems ＆Applications，2014，23（4）：84－90.

［2］李丰娟.H.264／AVC 编码标准模式选择快速算法研究［D］.重庆：重庆大学通信与信息系统学院，2010.Li Feng－juan.Study on fast mode selection algorithm for the coding standard H.264／AVC［D］.Chongqing：Communication and Informantion System Institute，Chongqing University，2010.

［3］Pan Feng，Lin Xiao，Susanto R，et al.Fast mode decision for intra prediction［C］∥Joint VideoTeam（JVT）Go13，7th Meeting：PattayaII，Thailand，2003.

［4］Cheng C C，Chang T S.Fast here step intra prediction algorithm for 4×4blocks in H.264［J］.ISCAS，2005，2（5）：1509－1512.

［5］Huang Y X，Huang G.Adaptive AIMD rate control for smooth multimedia streaming［C］∥IEEE the 12th International Conference on Computer Communications and Networks，Dallas，TX，2003：171－177.

［6］林志勇，叶桦，孙晓洁，等.3G 视频传输中码率自适应调整算法［J］.东南大学学报：自然科学版，2012，42（1）：45－50.Lin Zhi－yong，Ye Hua，Sun Xiao－jie，et al.Adaptive bitrate adjustment algorithm of video transmission based on 3Gnetwork［J］.Journal of Southeast University（Natural Science Edition），2012，42（1）：45－50.

［7］左冬红.面向TCP 的流媒体传输编码码率自适应算法［J］.中国图象图形学报，2011，16（4）：510－515.Zuo Dong－hong.An algorithm for encoding rate adaptive streaming media transmitting based on TCP［J］.Journal of Image and Graphics，2011，16（4）：510－515.

［8］廖顺和.H＿264在城市轨道交通视频监控中码率控制的研究［D］.上海：东华大学计算机应用技术学院，2008.Liao Shun－he.The research of H.264rate Control in video surveillance for urban rail transportation［D］.Shanghai：Applied Computer Technology Institute，Donghua University，2008.

［9］刘硕.H.264／AVC 编码算法的若干关键技术研究［D］.上海：上海交通大学电子信息与电气工程学院，2009.Liu Shuo.Investigations on key techniques of H.264／AVC encoder［D］.Shanghai：School of Electronic Information and Electrical Engineering，Shanghai Jiaotong University，2009.

［10］张久玲，练秋生.利用宏块特征的H.264／AVC 快速帧内模式决策［J］.计算机工程与应用，2012，48（14）：190－194.Zhang Jiu－ling，Lian Qiu－sheng.Fast intra mode decision for H.264／AVC using features of macro block［J］.Computer Engineering and Applications，2012，48（14）：190－194.

［11］牛平宏.面向实时压缩的H.264 优化研究［D］.西安：西安电子科技大学计算机应用技术学院，2006.Niu Ping－hong.Researches on H.264encoder optimization for real time compression［D］.Xi＇an：Applied Computer Technology Institute，Xidian University，2006.

［12］于溯，盛彦瑾，黄凯，等.RTP 自适应传输控制算法的研究［J］.计算机工程与科学，2005，27（11）：52－56.Yu Su，Sheng Yan－jin，Huang Kai，et al.Research on the algorithm of RTP adaptive transmission control［J］.Computer Engineering＆Science，2005，27（11）：52－56.

［13］Padhye J，Firoiu V，Towsley D，et al.Modeling TCP throughput：a simple model and its empirical validation［J］.Computer Communication Review，1998，28（4）：303－314.

［14］陶桂东，张占军.基于RTP协议H.264视频流传输QoS保证的研究［J］.装甲兵工程学院学报，2006，20（5）：58－61.Tao Gui－dong，Zhang Zhan－jun.Research on the QoS guarantee for H.264video stream transmission based on RTP［J］.Journal of Academy of Armored Force Engineering，2006，20（5）：58－61.