CN106982356B - 一种分布式大规模视频流处理*** - Google Patents

Abstract

本发明属于数字图像处理、分布式计算技术领域，具体为一种分布式大规模视频流处理***。本发明建立了一种分布式大规模视频流处理的模型，并根据此模型提出分布式视频流处理***。本发明用多机集群的方式对大规模视频流协同处理，用多台机器进行视频流采集，提高吞吐量；主要提供两种接口，一种针对视频不可分割（帧与帧之间前后依赖）的情形，如行人跟踪等，另一种是视频可以分割的情形，如行人检测等。另外，本发明提供了比较科学合理的资源监控方法（主要是CPU资源和内存资源），对于集群的资源扩展提供了依据。此外，引入CPU时间占用率，提出CPU时间占用率来衡量集群的利用率，更加直观和科学。

Description

一种分布式大规模视频流处理***

技术领域

本发明属于数字图像处理、分布式计算技术领域，具体涉及一种分布式大规模视频流处理***。

背景技术

智能视频监控技术在公共安全、交通管理、智慧城市等方面有着广泛的运用前景，需求日益增长。随着摄像头安装的数量越来越多，采集的图像的数据量越来越大，靠单台计算机处理已经远远不能满足需求了。并且智能视频监控很多情况下是要求对采集图像进行实时处理。数量众多的监控摄像头，庞大的监控网络，很短时间之内就会产生海量的图像视频数据，如何从这些海量数据中高效地提取出有用的信息，就成为智能视频监控技术要解决的问题[7]。分布式计算的兴起与发展为解决大规模的数据处理问题提供了很好的途径。

很多“大数据”是实时接收得到的，这些数据往往在得到时具有最大的价值[1]。并且这些不断产生的“大数据”无论是数据存储还是数据快速处理问题都已经不是单台物理机器能够解决的。因此，许多分布式流式处理平台不断被开发出来，如Twitter公司开发的Storm[2]、Yahoo!公司开发的S4 [3]、微软的Timestream[4]以及UC Berkeley AMPLab开发的Spark Streaming[5]等。这里Spark Streaming是基于D-Steam[1]模型并构建在Spark计算引擎上[6]的分布式流式计算框架，其特点是结合了流式处理和批处理。由于一些视频流处理存在帧与帧之间的依赖关系，这些框架不适合该类视频流的处理。针对这些问题，本发明采用了两种处理模式来解决现有框架在大规模视频流处理方面的问题。

发明内容

本发明的在于提供一种数据采集速度快、处理效率高的分布式大规模视频流处理***。

本发明提供的大规模视频流处理***，如附图1所示，采用集群的形式，集群中，主节点负责客户端进行交互、集群中从节点的状况监控以及视频流处理任务调度，从节点的状况信息包括硬盘状况、CPU状况、内存状况、运行的任务状况等；从节点负责对视频帧进行采集和处理，其中采集器是运行在从节点的一个进程，负责采集视频流数据；视频数据处理结果通过调用视频/图像处理库的相应接口存储到存储***中，如本地文件***、分布式文件***等；视频/图像处理库可以动态添加，如行人检测等。

本发明中，利用多台机器采集视频数据，当视频帧前后存在依赖关系时可以在本地处理，否则，先解码，然后按照一定的格式组织成字节数组的形式（数据包），随机选择一个节点（属于从节点，为了与其他从节点区分，这里称其为元数据管理节点，下同）记录数据包的元数据，元数据管理节点负责分发任务到集群的其他从节点，由这些节点对数据包进行处理，处理结果返回元数据管理节点。在整个过程中对集群的资源情况进行监控，进而调整集群的资源分配情况。

整个***包括视频数据采集模块、视频数据处理模块和数据存储模块。视频数据采集模块，利用多台机器采集视频数据，采用poll的方式从外部获取视频流数据，支持RTSP、HTTP等多种视频流传输协议，并且在获取视频流数据的过程中支持失败重试、断点续传；视频数据处理模块对视频帧数据进行结构化组织，形成数据包的形式，然后由主节点来进行任务划分和调度，从节点从视频库中调用相应算法来对数据包中的数据进行处理；数据存储模块提供了包括本地文件***、分布式文件***以及数据库的存储接口，视频数据处理后的结果由数据存储模块负责存储。

上述大规模视频流处理***的工作具体流程如下：

步骤1、客户端向主节点提交视频流处理请求，请求信息包括视频流来源（可通过网络获取该视频流数据）、视频流的处理方式以及存储方式。主节点得到对请求信息进行检查，检查内容包括对视频流来源是否可以访问等。如果检查不通过，则主节点向从节点返回错误信息，否则主节点对该请求一个唯一的ID，并将ID返回给客户端，客户端通过ID向主节点实时查询任务的状态。

步骤2、多路视频流数据的采集

采用多台（n台）机器对多视频流数据进行采集（采集器），充分利用各个机器的网络带宽，可极大提高网络吞吐量。设各台机器的吞吐量分别为

,则平台总的吞吐量为

。

步骤3、 对视频进行解码

当视频帧前后存在依赖关系时，可以在本地处理；否则，在视频进行处理之前需要对视频流进行解码，将视频里面的视频帧解码出来，并给每一帧打上标签，标签包括id（从0开始递增），***（host地址等形式），视频流唯一标识（每一路视频对应一个唯一的标识）。以字节数组的形式进行封装，组成数据包；数据包的组织形式如图2所示，其中，数据块0为数据包头部，整形，4个字节，记录后面一个数据的总长度；数据块2k+1为整形，4个字节，记录数据块2k+2的字节长度 (k=0,1,2…n)；数据块2k+2为任意长的字节数组，是真正的数据 (k=0,1,2…n)；数据块2k+3为CRC校验，一个字节。

步骤4、将视频帧提交到集群中处理

步骤2和步骤3产生的数据由所在的机器管理，而这些数据的元数据（视频流唯一标识、数据块唯一标识、所在的机器位置）由单独一个进程管理（元数据管理节点），元数据管理节点根据步骤2的元数据产生任务，然后将这些任务分发给其他从节点；接收到任务的从节点，首先向数据所在的节点获取要处理的数据，并对这些数据进行处理，处理后数据返回到元数据管理节点。

步骤5、元数据管理节点维护数据的顺序

元数据管理节点会收到多路视频处理后的数据，由于视频中的帧与帧之间有先后顺序，并且不同视频流之间的帧是独立的。这里采用哈希表和最小堆（可称为资源池）的形式维护数据的顺序性与独立性。资源池中的数据可以进行与业务相关的应用。

步骤6、集群资源的监控与调整，

本发明提出采用CPU时间占用率来衡量集群的资源的使用情况，并根据此来调整集群资源。

CPU时间占有率表示某一段时间内CPU各个核数用于数据处理的时间占总时间的比率。由于每个任务都在单独的线程中运行，统计任务的运行时间，就不难得出线程处理数据的时间。

设N表示为用户所需的最大使用的CPU核数，

表示第n个核t时刻（以毫秒为单位）的使用状态，

，则

可表示为：

；

则从1到K时刻第n个核的时间占用率为

。由于多核CPU中无法确定线程使用的是哪个核，因此第n个核的时间占用率比较难得到，但这里可以得到从1到K时刻N个核总的时间占用率

，表示为：

越大，也就是处理数据的时间占任务的总时间（包括处理数据的时间、任务调度时间，网络传输时间等）的比重也大，说明平台越高效。当

过大时需要增加集群资源，可以通过加机器的形式实现。

步骤7、视频数据存储

数据处理的过程得到的结果可以通过元数据管理节点直接存储到本地文件***、分布式文件***或者数据库中。数据的存储格式以及存储方式可以由客户端来指定，如结构化的数据可以存到数据库中，数据量比较大的情况可以存到分布式文件***中。

与现有技术相比，本发明的优点和效果有：

1、数据采集速度快。对于视频的采集，采用多台机器同时采集，极大提高了数据采集的速度；

2、资源整合利用。集群中的CPU资源、内存资源等作为一个资源池的形式进行分配，可以充分利用到集群的资源；

3、中间数据优先保存在内存。为了提高速度，中间数据优先保存在内存中而不是磁盘中，当内存不足时才保存在磁盘中。由于对内存数据的读取速度远远大于对磁盘数据的读取速度，因此可以大大提高***效率；

4、引入CPU时间占用率。本发明提出CPU时间占用率来衡量集群的利用率，更加直观和科学。

附图说明

图1为分布式大规模视频流处理平台架构图示。

图2为视频帧封装数据包结构图。

图3为分布式大规模视频流处理平台部署示意图。

图4为测试视频流信息的检测效果图示。

图5为本发明（分布式处理）取得的处理速度与单台同样机器（单机处理）处理速度的对比图示。

具体实施方式

下面结合附图对本发明所述技术方案进一步说明。此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

图3是分布式大规模视频流处理平台部署示意图，主节点和从节点之间的信息交互通过交换机完成，客户端通过以太网与集群进行信息机交互，集群通过以太网获取视频流数据。本发明主节点数量为1台，机器配置如下：

从节点数量为3台，机器配置如下：

。

具体流程如下：

1、启动集群，从节点向主节点发送节点的CPU、内存和硬盘信息，完成从节点向主节点的注册过程，此后从节点以心跳包的形式定时向主节点更新从节点的状态信息；

2、客户端向主节点提交视频流处理请求，请求信息包括视频源的网络地址，处理的方式，如行人检测、车牌识别等。本发明采用的测试视频流信息如下表所示，采用的处理方式为HOG特[8]的行人检测，检测效果如图4所示；

；

3、主节点通过网络来检查视频源的网络地址是否正确，通过检查后为该请求生成唯一ID返回给客户端，同时将任务交由元数据管理节点运行；

4、元数据管理节点启动采集器来采集视频流数据，具体数据保存在采集器所在的机器，采集器将元数据交由元数据管理节点管理，元数据管理节点根据元数据以及客户端请求的处理方式生成具体的计算任务；

5、从节点不断从元数据管理节点获取要处理的任务，并根据元数据信息获取实际的视频帧数据来进行处理；

6、处理结果返回元数据管理节点，由元数据管理节点输出；此外元数据管理节点不断向主节点汇报任务的运行状态；

7、客户端可以通过ID来向主节点查询任务运行的状态；

8、在本发明的实际部署条件下和在相同处理方式的情况下，本发明（分布式处理）取得的处理速度是单台同样机器（单机处理）处理速度的35倍左右，如图5所示。

参考文献：

[1] Matei Z, Tathagata D, Haoyuan L, et al. Discretized Streams:Fault-Tolerant Streaming Computation at Scala[C]//Proc of the Twenty-FourthACM Symposium on Operating Systems Principles, Farmington, Pennsylvania, USA:ACM,2013.

[2] Apache Software Foundation. Storm, distributed and fault-tolerantreal time computation[EB/OL]. [2015-06-25]. http://storm.apache.org/.

[3]Neumeyer L, Robbins B, Nair A, Kesari A. S4: Distributedstreamcomputing platform[C]//Proc of the 10th IEEE Int’l ConfonData MiningWorkshops (ICDMW 2010). Sydney: IEEE Press, 2010.

[4]Z. Qian, Y. He, C. Su, et al. Timestream: Reliable streamcomputation in the cloud[C]//Proc of the 8th ACM European Conf on ComputerSystems. New York, NY, USA: ACM,2013.

[5] Apache Software Foundation. Apache Spark, lightning-fast clustercomputing [EB/OL]. [2015-06-28]. http://spark.apache.org/.

[6] M. Zaharia, M. Chowdhury, T. Das,etal.Resilient distributeddatasets: A faulttolerantabstraction for in-memory cluster computing [C]//Proceedings of the 9th USENIX conference on Networked Systems Design andImplementation. CA,USA: USENIX Association, 2012.

[7]黄凯奇，陈晓棠，康运锋，等. 智能视频监控技术综述[J]. 计算机学报,2015,38(6):1094-1094.

[8]NavneetDalal , Bill Triggs. Histograms of Oriented Gradients forHuman Detection[C]//Proc of the 2005 IEEE Computer Society Conf on ComputerVision and Pattern Recognition. San Diego, CA, USA:IEEE,2005。

Claims (2)

1.一种大规模视频流处理***，采用集群的形式，其特征在于，集群中，主节点负责客户端进行交互、集群中从节点的状况监控以及视频流处理任务调度，从节点的状况信息包括硬盘状况、CPU状况、内存状况、运行的任务状况；从节点负责对视频帧进行采集和处理，其中采集器是运行在从节点的一个进程，负责采集视频流数据；视频数据处理结果通过调用视频/图像处理库的相应接口存储到存储***中；视频/图像处理库可以动态添加；

其中，由多台机器采集视频数据，当视频帧前后存在依赖关系时，在本地处理；否则，先解码，然后按照一定的格式组织成字节数组的形式即数据包，随机选择一个节点，称其为元数据管理节点，记录数据包的元数据，元数据管理节点负责分发任务到集群的其他从节点，由这些节点对数据包进行处理，处理结果返回元数据管理节点；在整个过程中对集群的资源情况进行监控，进而调整集群的资源分配情况；

整个***包括视频数据采集模块、视频数据处理模块和数据存储模块；其中，视频数据采集模块，利用多台机器采集视频数据，采用poll的方式从外部获取视频流数据，支持多种视频流传输协议，并且在获取视频流数据的过程中支持失败重试、断点续传；视频数据处理模块对视频帧数据进行结构化组织，形成数据包的形式，然后由主节点来进行任务划分和调度，从节点从视频库中调用相应算法来对数据包中的数据进行处理；数据存储模块提供了包括本地文件***、分布式文件***以及数据库的存储接口，视频数据处理后的结果由数据存储模块负责存储。

2.一种基于权利要求1所述***的大规模视频流处理方法，其特征在于，具体步骤如下：

步骤1、客户端向主节点提交视频流处理请求，请求信息包括视频流来源、视频流的处理方式以及存储方式；主节点对得到的请求信息进行检查；如果检查不通过，则主节点向从节点返回错误信息，否则主节点对该请求生成一个唯一的ID，并将ID返回给客户端，客户端通过ID向主节点实时查询任务的状态；

步骤2、多路视频流数据的采集

采用多台机器对多路视频流数据进行采集，设各台机器的吞吐量分别为

，则平台总的吞吐量为

；

步骤3、 对视频进行解码

当视频帧前后存在依赖关系时，在本地处理；否则，在视频进行处理之前需要对视频流进行解码，将视频里面的视频帧解码出来，并给每一帧打上标签，标签包括id，***，视频流唯一标识；以字节数组的形式进行封装，组成数据包；

步骤4、将视频帧提交到集群中处理

步骤2和步骤3产生的数据由所在的机器管理，这些数据的元数据，包括视频流唯一标识、数据块唯一标识、所在的机器位置，由单独一个进程管理，元数据管理节点根据步骤2的元数据产生任务，然后将这些任务分发给其他从节点；接收到任务的从节点，首先向数据所在的节点获取要处理的数据，并对这些数据进行处理，处理后数据返回到元数据管理节点；

步骤5、元数据管理节点维护数据的顺序

元数据管理节点收到多路视频处理后的数据，由于视频中的帧与帧之间有先后顺序，并且不同视频流之间的帧是独立的；这里采用哈希表和最小堆的形式维护数据的顺序性与独立性，哈希表和最小堆称为资源池，资源池中的数据可以进行与业务相关的应用；

步骤6、集群资源的监控与调整，

采用CPU时间占用率来衡量集群的资源的使用情况，并根据此来调整集群资源；

这里，CPU时间占有率表示某一段时间内CPU各个核数用于数据处理的时间占总时间的比率；由于每个任务都在单独的线程中运行，统计任务的运行时间，就得出线程处理数据的时间；

设N表示为用户所需的最大使用的CPU核数，

表示第n个核t时刻的使用状态，时刻t以毫秒为单位，

，则

表示为：

从1到K时刻第n个核的时间占用率为

；N个核总的时间占用率

为：

越大，表示处理数据的时间占任务的总时间，包括处理数据的时间、任务调度时间，网络传输时间等的比重也大，说明平台越高效；

步骤7、视频数据存储

数据处理的过程得到的结果通过元数据管理节点直接存储到本地文件***、分布式文件***或者数据库中；数据的存储格式以及存储方式由客户端来指定。

Images