一种多路视频流并行化处理方法_第1页
一种多路视频流并行化处理方法_第2页
一种多路视频流并行化处理方法_第3页
一种多路视频流并行化处理方法_第4页
全文预览已结束

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

一种多路视频流并行化处理方法

基于ha的基于源的分布计算结构,它是目前并行处理平台的代表,文献。1相关研究1.1实时应用程序控制Storm是实时的并具备高容错的分布式计算系统,主要由一个主节点(Nimbus)和一群工作节点(Worker)组成,同时每个工作节点上运行一个监督节点(Supervisor),通过Zookeeper进行协调。主节点负责任务分配,并监控状态。监督节点会监听所分配子节点机器的任务状态,根据需要启动/关闭工作进程。Storm中,各个组件间的消息流动形成逻辑上的拓扑结构,故运行一个实时应用程序通过提交拓扑(Topology)完成。如图1所示,Spout是消息的生产者,负责数据的抓取,从来源处读取数据放入拓扑,然后以元组(Tuple)的形式发送到数据流中,Bolt封装了所有的消息处理逻辑,通过流分组(StreamGrouping)将Spouts与Bolts连接起来。1.2st模型算法的并行人车分类主要分为4个部分:感兴趣前景区域的提取,目标跟踪预测,特征提取,目标分类。流程如图2所示。前景区域的提取是视频分析的最初阶段,将运动目标从背景中分离,为下一阶段的跟踪与识别做准备。目标跟踪是对场景中的感兴趣目标进行预测与定位,可以更准确地得到目标的运动状态。通过特征提取与目标识别对运动信息进行筛选,对人车信息进行识别。在Storm集群中每个处理的元组相互独立,算法的并行实际是基于文件的并行实现。本文使用多帧差分法提取前景区域,卡尔曼滤波实现目标跟踪预测,采用HOG算子与SVM算法实现目标的识别分类,在实现每段视频数据处理完整性的前提下也能准确检测出人车目标。2车分类及核心任务并行化本文利用Storm并行化处理框架实现基于海量视频流的人车分类,核心思想是将计算任务分配给多个节点,通过任务并行化达到提升性能的目的。主要包括如下步骤:缓存视频流获取、自定义VideoStreamSpout类组件、算法融合。2.1rtsp视频流的数据处理远程摄像头捕捉到的视频数据,通过网络传输到本地云平台处理。流媒体在传输的过程中,由于带宽等的影响,不可避免地会出现数据丢失或失序的现象,而且数据采集的速度和数据处理的速度不一定同步,会造成数据堵塞。RTSP视频流为帧与帧之间连续相关的非结构化数据流,物理分割会造成帧不完整、分割后缺少关键帧(I帧)的问题,因此需要对视频流数据解耦合。提出了一种基于关键帧的视频流缓存方法,如图3所示,视频图像以序列为单位进行组织,一个序列是一段图像编码后的数据流,以关键帧开始到下一个关键帧结束。根据关键帧的位置进行缓存,可以保证所有的缓存块都有必要的帧信息,不会出现缺少关键帧无法解码的问题。2.2存储独立sds的存储信息自定义VideoStreamSpout类组件,通过继承BaseRichSpout接口实现数据读取,数据读取流程如图4所示。如2.1节所述获取独立的缓存视频流,当缓存流达到元组要求就以队列形式推送。open()方法打开缓存流,将数据封装成一个个Tuple,通过nextTuple()方法不间断发送新的Tuple到消息队列。为保证数据的连续性,每个Tuple会随机分发唯一的ID。拓扑提交后会一直运行直到被手动杀死。此外,Storm在检测到一个元组被成功处理时调用ack()方法,否则调用fail()方法,这样保证了数据处理的可靠性。2.3c/c++语言及其数据资源整合计算任务主要在VideoStreamBolt环节实现,VideoStreamBolt组件与VideoStreamSpout组件之间通过松耦合的管道机制实现流传输,这种调度机制极大提升了并行计算的稳定性和可扩展性。Storm的拓扑结构通过Java语言实现,Java语言因其简单、面向对象、可移植、平台无关等特性,已成为分布式计算领域的主流程序设计语言。影响Java语言算法实现的最大问题是速度,在原始的Java解释器中,C语言的速度是解释过的Java语言的20倍左右,用Java语言来完成对性能敏感的高性能密集计算目前不是最好的选择。视频的解码及人车分类算法分别使用FFMPEG视频图像编解码库与Opencv开源计算机视觉处理库实现,采用C/C++语言编写,在不改变并行结构及算法效率的情况下,Java的JNI(JavaNativeInterface)接口实现了Java数据与C++本地库的数据交互,但频繁的数据拷贝会大大降低数据传递的效率及稳定性,且当交换数据块较大时,会造成内存泄漏,对计算机内存造成较大损耗。同时频繁的数据拷贝造成算法的延时在流式计算中会产生数据堵塞。本文提出了一种优化的高效并行内存共享机制,可以最大化优化代码的运算速度,具体结构如图5所示。在该机制中,Java端作为程序的起始端,负责任务的分发及资源调度,构建并行计算环境。当有数据交互发生时,Java端开辟堆内存空间与JNI层共享,并将数据信息导入共享内存,通过地址值的传递,实现本地算法与Java端的数据交互,同时,也可以通过并行内存共享机制,将本地算法处理完成后的人车等目标信息导入Java端。在不打破Storm并行计算框架和Java应用程序环境的情况下,通过内存共享机制,Java端与C++本地算法实现端数据同步变化,相比于普通的数组传递,效率更高更快,减少了数据堵塞的产生,且适合长期使用、频繁访问的大块内存的共享。3kvm系统环境本实验在操作系统为centos6.6的64位华硕服务器下实现,硬件环境如下:CPU为2个6核Intel(R)Xeon(R)CPUE5-2620处理器,内存为64Gbyte,通过KVM虚拟化技术搭建Storm集群,集群中设置1个Nimbus节点和3个Supervisor节点,网络环境为10.0.0.1网段的局域网。软件环境为apache-storm-0.9.2-incubating。测试视频为编码方式是H.264,像素为1920×1080高清视频流数据。3.1视频数据的能耗验证内存共享机制的高效性,测试在相同环境下本文方法与基于数组传递的方法处理不同大小的视频数据时耗如表1所示。从表1可以看出,两种机制分别实现人车分类算法,本文方法明显优于基于内存拷贝机制的方法,且随着数据量的增大,本文方法中每帧视频数据平均处理时间相对稳定,能满足JNI调用本地算法高效性需求。3.2两种模式下视频处理效果对比吞吐量指系统单位时间内处理数据的大小,是衡量并行系统实时高效性的重要指标。记录在Storm单机模式与集群模式下,随着数据量的增加,完成视频处理所需时间,对比两种模式下的结果如图6所示。由图6可知,当视频数据流比较小时,由于任务分发数据传输等都需要耗费一定的计算机资源和时间,单机模式下数据流处理时间低于集群模式的处理时间。但是随着数据流的增大,任务分发所需时间远小于视频处理的时耗,集群模式处理时间明显缩短。3.3高效节点高效存储负载均衡是并行计算中的一项重要指标,数据计算过多分布于同一计算节点,形成数据倾斜,会造成计算资源的浪费,影响集群稳定性。Storm并行框架的数据处理基于内存进行,在任务执行过程中使用nmon工具统计各节点内存使用情况如图7所示。图中IP为10.0.88.55的计算机为Nimbus节点,分配8Gbyte内存空间,其他为工作节点分配4Gbyte内存空间。Nimbus节点需要分配计算任务并监控集群状态,内存使用率高于工作节点,保持稳定。各工作节点在硬件资源分配相同的条件下,在任务开始阶段内存上升平稳,随后趋于稳定,由此可知各工作节点内存使用率大致相同,没有出现某一节点内存使用过高的情形,说明在任务执行过程中,集群内存使用相对合理,没有出现数据倾斜的情况,负载均衡。4实验结果分析针对海量监控视频流数据实时分析的需求,设计了基于多路视频流的并行处理框架,提高了视频流数据处理的效率

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论