基于Storm平台的实时视频分析系统

韩 杰，陈耀武

（浙江大学数字技术及仪器研究所，杭州310027）

1 概述

随着安防监控行业的高速发展，智能监控和云计算技术的结合成为重要的研究方向［1－2］。智能视频监控通过对视频画面中的海量数据进行高速分析，能快速提供感兴趣的信息或实时异常告警［3］。由于通用计算机强大的处理能力和低廉的价格，可以利用集群为多台监控终端提供耗时的视频分析服务。目前很多视频分析系统基于离线视频处理［4－5］，应用Hadoop分割视频并通过集群完成大规模运算，但是数据收集、备份以及磁盘操作使得其很难实现秒级的延时。

Storm［6］是Twitter开源的一个流计算框架，和其他流计算产品相比更加成熟。Storm能快速可靠地处理源源不断的消息，具有良好的容错机制，并且提供任务分配、集群管理、性能监控等功能。

本文设计一个基于Storm云平台的实时视频分析系统，并进行以下工作：（1）根据H．264视频特点设计一个实时环境下的流分割方案；（2）提出视频处理机制，利用工作窃取机制加速算法执行；（3）通过改进Storm调度算法提高系统的实时性能。

2 整体设计

系统的整体设计框图如图1所示。首先缓存主要考虑到设备码率的波动，添加缓存可以保证集群均匀地订阅视频流，改善集群性能和稳定性，对整体时延的增加也不明显；另外对设备和Storm集群进行隔离，并且方便应用层对系统进行控制。

图1 基于Storm的实时视频分析系统总体框架

Storm集群由运行Nimbus的主控节点和运行Supervisor的工作节点组成，Supervisor负责接收任务并管理自己的worker进程，worker进程中运行着Topology任务。每路设备作为一个拓扑提交Nimbus。Spout实例抽象成一路设备订阅缓存中的一路码流，将连续的流进行完整性分割，然后发射到集群进行后续处理，并行度设置为1。DecAlgBolt任务负责分割单元的解码以及视频分析，这个最耗时的任务在集群中会实例化多个以充分利用集群的性能。MergeBolt任务负责收集识别结果并且实时通知应用层或者持久化写入数据库。应用服务层提供实时订阅、系统监控、结果检索等服务。

3 Storm平台下实时视频分析系统的实现

3．1 视频流分割

视频原始数据会占用巨大的网络传输带宽，以D1＠25fps为例，如果在集群中采用还原的原始视频数据，每一路视频需要150Mb／s带宽，在千兆以太网的集群内最多为6路设备提供服务。

本文针对H．264视频的特点，以GOP为单位处理视频，并且由于组件的无状态性，需要附上该通道最新的序列参数集（Sequence Parameter Set，SPS）和图像参数集（Picture Parameter Set，PPS）为解码器提供解码参数。具体流分割过程如图2的步骤（1）～步骤（5）所示。

图2 视频流分割具体步骤

GOP大小的选取是带宽和集群性能之间的博弈。较小的GOP会大幅增加视频码流的带宽，但大的GOP导致消息的处理时间过长影响集群的性能。文献［7］在MPEG视频人脸识别系统中选择12帧～15帧的GOP长度，而且由于视频中的目标在画面中的存在时间通常大于一个12帧～15帧的GOP时长，因此选择GOP长度为12，相比于1s的GOP设置，在静态场景下会有不超过50%的带宽提高，但是由于静态场景的本身码率很低，而且在场景变化剧烈的情况下，GOP＝12较GOP＝25带宽变化并不明显。选择12的另一个原则是基于均匀跳帧考虑的，可以间隔1帧、2帧、3帧、5帧减小冗余运算。

3．2 FFmpeg解码与视频分析

采用FFmpeg完成H．264解码工作。FFmpeg是一个集录制、转换、音／视频编码解码功能为一体的完整开源解决方案［8］，由于是 C／C＋＋开发，在Java环境中为了高效执行解码任务，通过Java本地接口（Java Native Interface，JNI）技术调用FFmpeg本地库中的方法，提高解码效率。

DecodeAnalyseBolt为解码单元和视频分析单元的任务处理器，主要流程如下：

Step1DecodeAnalyseBolt在Storm集群中实例化，在prepare方法中创建H264Decoder，创建实际的视频分析服务，创建FrameManager用于解码和视频分析线程之间的缓冲，创建视频分析线程。

Step2运行时，接收消息，并同时执行H．264解码以及视频分析算法，每分析完一帧发射处理结果，最终处理完整个消息发出回应。由于解码速度通常会远大于视频分析算法的速度，因此可以利用多核处理器优势，使用工作窃取（work stealing）［9］机制，在相应视频帧解码完成后“窃取”分析线程任务队列另外一端的任务，并调用前面创建的视频分析服务，减小算法的执行时间。图3为跳帧间隔为1和2下的任务序列。

图3 工作窃取机制下的任务序列

3．3 Storm调度算法改进

Storm默认的调度器采用了round－robin机制将每个spout，bolt组件的实例依次分配到配置好的workers中，并将所有workers尽量等量地分配到每台Worker节点。这种简单的分配机制有时也带来了一定的限制，如图4所示，后加入机器c，d的Topology4，Topology 5的任务属于重负载，那么c，d就可能会长期处于overload状态，影响整体性能，而对于其他机器来说可能存在部分性能浪费。

图4 默认调度器下的任务分配结果

文献［10－11］从Tuple的传输角度改进Storm默认的调度机制，避免大量的网络传输来改善系统性能。本文从worker的迁移角度动态调节系统的负载。调度器的实现机制如图5所示。worker后台线程通过zk写入该worker平均CPU占用率，Worker节点上的Supervisor后台进程也有一个监控线程，该线程记录的是本节点的平均CPU load。

图5 调度器实现机制

调度算法使用了贪心和置换策略。具体描述如下：对于新提交的Topology，可以使用默认的调度器将该Topology需要的worker数分配到空闲的slot。对于已经分配的任务，找到当前Load最高的Worker Nodei，现在目标是要将该节点上的某个worker移动或者置换到其他节点j，使该节点Wi1和移动（满足式（1））或置换（满足式（2））后的节点Wi2满足以下约束条件：

式（1）的做法是直接将wj（workerj）中的executors分配到Wi2可用的slot中。式（2）是因为已经没有slot数可用了但是此时的负载存在着不均衡，这时为了改善节点i的性能，采取的做法是找到节点k，在k上寻找一个 workerwk，j，将wk，j中的任务踢出去，空出的slot用于完成式（1）的分配，被提出的任务需要分配到节点i空出的slot，称为一次置换过程。如果遍历所有节点采用式（1）和式（2）没有找到符合条件的方案，则本次处理失败。如果多次在同一个节点失败，则可能要考虑找出这个节点中load最大的worker并终止属于它的topology。算法的伪代码描述如下：

4 实验结果与分析

实验环境为枪机和球机设备以及由PC组成的集群。监控设备的输出码流规格为：H264MP，D1＠25fps以及720＠25fps，VBR，GOP＝12，设备和集群通过千 兆 交 换 机 连 接，PC 为i5－34704GRAM，运 行Ubuntu，系统上安装JDK1．6，Zookeeper，ZeroMQ2．17，FFmpeg2．2．4及Storm0．9．1。

本次视频分析对象是人脸，人脸算法使用的是OpenCV的级联目标分类器识别算法［12］，表1给出了本次实验单机测试下的耗时。

表1 单机下的各项耗时 ms

从表1中可以看出，在一组GOP测试中，由于使用了work stealing机制，使跳帧为6下的处理速度提高了30%，跳帧为10下由于一组只有2帧，一帧的分析时间和帧组的解码时间接近因此提升不明显。

为测量系统实时性和Storm调度算法的改进效果，预先录制了一段固定时间间隔（5 s）出现人脸的视频，然后在大屏幕播放并对着不同制式的网络摄像机，同时运行该系统统计MergeBolt的识别结果出现时间，消息处理延时定义为分割完成到识别结束的时间。有一台运行缓存系统，集群中1台运行Nimbus，UI以及Zookeeper，还有3台运行supervisor，终端共接入12路IPC，其中9路为D1码流，3路为720P。图6为其中一路D1枪机在默认调度器以及改进调度器下随时间消息处理延时的情况（跳帧为10）。

图6 某D1通道下的消息处理延时

从图6可以看出，由于加入了3个720P负载较大的设备，因此默认情况下发现其中2台机器的负载情况一直很高，workers在这2台机器上的消息处理时间就会大大增加。在改进的调度器下，在20s时进行了rebalance，因此后面的消息延时相对比较稳定，并低于默认的情况。表2为上述集群配置下系统的整体延时测试。

表2 系统整体延时 ms

从表2看出，负载增加时，系统整体延时增加并不明显。由于终端和缓存的时间比较固定，通常在600 ms左右，主要是在负载增加时会导致延时增加，但因为集群的动态负载调节所以延时增加并不明显。因此基于Storm平台的实时视频分析系统能在多路负载的情况下提供低于1 s的视频分析服务，并且基于Storm本身高度容错的特点，该系统能在云环境下提供可靠的服务。

5 结束语

本文根据云计算平台下智能视频分析的实时性需求，设计了基于Storm的实时视频处理系统。利用GOP流分割策略降低系统整体延时，解码和视频分析算法利用工作窃取机制加速集群内消息的处理速度，并通过Storm平台调度器的改进防止任务分配不均。实验结果表明，本文提出的系统能为网络环境中的多路终端设备提供实时视频分析服务，延时为1 s～2 s，基本满足视频分析的需求。本文系统基于H．264格式以及较短的GOP设置，但是云环境下视频的格式以及规格较多，如何兼容这些视频并适合分布式处理是下一步的研究重点。

［1］Neal D，Rahman S．Video Surveillance in the Cloud［J］．International Journal of Cryptography and Information Security，2012，2（3）．

［2］武文斌．智能视频分析的现状与未来发展趋势［J］．科技情报开发与经济，2011，21（31）：168－171．

［3］郑世宝．智能视频监控技术与应用［J］．电视技术，2009，（1）：94－96．

［4］高东海，李文生，张海涛．基于 Hadoop的离线视频处理技术研究与实现［J］．软件，2013，34（11）：5－9．

［5］Yang Fan，Shen Qiwei．Distributed Video Transcoding on Hadoop［J］．Computer Systems ＆ Applications，2011，20（11）：80－85．

［6］Lee H，Sull S．A VBR Video Encoding for Locally Consistent Picture Quality with Small Buffering Delay Under Limited Bandwidth［J］．IEEE Transactions on Broadcasting，2012，58（1）：47－56．

［7］Wang Hualu，Chang Shih－Fu．A Highly Efficient System for Automatic Face Region Detection in MPEG Video［J］．IEEE Transactions on Circuits and Systems for Video Technology，1997，7（4）：615－628．

［8］Bellard F．Ffmpeg［EB／OL］．（2014－10－10）．http：／／www．ffmpeg．org．

［9］Blumofe R D， Leiserson C E． Scheduling Multithreaded Computations by Work Stealing［J］．Journal of the ACM，1999，46（5）：720－748．

［10］Aniello L，Baldoni R，Querzoni L．Adaptive Online Scheduling in Storm［C］／／Proceedings of the 7th ACM International Conference on Distributed Event－based Systems．New York，USA：ACM Press，2013：207－218．

［11］Xu Jielong，Chen Zhenhua，Tang Jian，et al．T－storm：Traffic－aware Online Scheduling in Storm ［C］／／Proceedings of the 34th International Conference on Distributed Computing Systems．Washington D．C．，USA：IEEE Press，2014：535－544．

［12］Heisele B，Serre T，Poggio T．A Component－based Framework for Face Detection and Identification［J］．International Journal of Computer Vision，2007，74（2）：167－181．