海量视频人脸提取与识别并行框架设计及优化

作者李海跃,谭郁松,伍复慧机构国防科学技术大学计算机学院发表期刊《计算机应用研究》预排期卷2017年第34卷第12期访问地址http://www.
arocmag.
com/article/02-2017-12-001.
html发布日期2017-01-2315:02:40引用格式李海跃,谭郁松,伍复慧.
海量视频人脸提取与识别并行框架设计及优化[J/OL].
[2017-01-23].
http://www.
arocmag.
com/article/02-2017-12-001.
html.
摘要为了实现海量视频数据的高效并行处理,将视频数据集解耦合实现任务的高并行度,通过Spark读取数据流的同时获取关键帧的方式解决了解耦视频数据引起数据倍增问题,并对图片特征数据进行优化,进而在Spark上实现了具有高可扩展性并行处理海量视频数据的框架.
在天河二号云平台上进行部署实验,分析实验结果表明随着处理节点个数增加本框架可以获得近线性的加速比.
关键词Spark,分布式系统,视频处理,人脸识别,并行计算中图分类号TP391.
41基金项目国家"863"计划资助项目(2013AA01A212)优先出版计算机应用研究第34卷基金项目:国家"863"计划资助项目(2013AA01A212).
作者简介:李海跃(1988-),男,硕士研究生,主要研究方向为大数据,云计算;谭郁松(1976-),男,研究员,博士,主要研究方向为操作系统、云计算;伍复慧(1987-),男,博士研究生,主要研究方向为系统软件、云计算.
海量视频人脸提取与识别并行框架设计及优化*李海跃,谭郁松,伍复慧(国防科学技术大学计算机学院,长沙410073)摘要:为了实现海量视频数据的高效并行处理,将视频数据集解耦合实现任务的高并行度,通过Spark读取数据流的同时获取关键帧的方式解决了解耦视频数据引起数据倍增问题,并对图片特征数据进行优化,进而在Spark上实现了具有高可扩展性并行处理海量视频数据的框架.
在天河二号云平台上进行部署实验,分析实验结果表明随着处理节点个数增加本框架可以获得近线性的加速比.
关键词:Spark;分布式系统;视频处理;人脸识别;并行计算中图分类号:TP391.
41Parallelframeworkforextractionandrecognitionforlarge-scalevideoLiHaiYue,TanYuSong,WuFuHui(SchoolofComputer,NationalUniversityofDefenseTechnology,Changsha410073,China)Abstract:Inrecentyears,alargenumberofmonitoringequipmenthasbeenusedinintelligenturbanconstruction,andgeneratemassivevideodatawhichareinurgentneedofafastandefficientprocessing.
inordertorealizingtheeffectiveprocessingofmassivevideodatainparallel.
Thispaperdecouplesvideofilesforgettinghighdegreeoftasksparallelism,resolvestheproblemofmultiplieddataafterdecouplingvideofilesandoptimizesthefeatureofpicture,thispaperrealizesthebetterscalableframeworkofprocessingvideodataonSpark.
BydeployingandexperimentingoverKylinCloudonTianhe-2,theexperimentalresultsshowthattheframeworkgetslinearspeed-upratiowiththeincreaseofprocessingnode.
KeyWords:spark;distributedsystem;processingvideos;facerecognition;parallelcomputing0引言随着智慧城市的建设,视频监控网络系统大量部署.
这些系统产生的数据具有大量、高速等大数据的特点.
视频数据信息丰富,然而又是一种非结构化的数据,因此在解决海量视频数据的存储、处理和内容处理等方面面临巨大挑战.
在实际生产生活中通常会有从大量的离线视频文件中寻找某个人的需求,而面对TB级别的视频数据,人工查找已经显得无能为力.
在这种紧迫的需求下,目前仍然没有一个有效的用于从海量视频中提取人脸和识别的框架.
近年来随着大数据处理技术的发展,基于Hadoop的大数据处理技术应用广泛[1].
Hadoop可以运行在普通廉价机器的异构集群上不仅易于扩展而且对于节点故障有很强的容错性.
然而压缩的视频文件中各帧之间有依赖关系,这种数据紧耦合关系使其不像普通文本文件一样能够通过分片实现分布式处理.
文献[2]中将视频切割成更小的视频片段实现了视频在Hadoop上的处理,文中分析了利用Hadoop进行分布式转码的性能,表明分布式处理视频数据极大的提高了视频的处理速度.
同样文献[3]通过扩展FFmpeg[4],在Hadoop上将视频文件分解为视频帧组(GroupofPictures,GOP)实现了一个对人脸跟踪的分布式处理框架.
文献[5]实现了Hadoop从HDFS[6]中读取视频文件的接口,并通过编写JNI调用本地函数实现对视频文件进行处理.
Spark[7]分布式计算框架基于弹性数据集(ResilientDistributedDatasets,RDD)实现了基于内存的分布式运算系统,其基于"血统"的容错机制和高效的数据共享特点使其相比于Hadoop在性能上要高出几十倍[8].
面对日益剧增的视频数据,这就需要一种能够结合当前分布式系统有效处理视频数据的框架.
然而视频文件是一个压缩数据文件,在对视频处理时需要参考视频帧前后数据进行解压,像普通文件一样进行粗暴地切分将导致文件无法解压,这就限制了视频处理的并行实现.
文献[2][3]表明更小的视频数据粒度,在处理上能够获得更高并行度进而增加扩展性和处理速度.
然而文献[2][3]分别调用外部库将视频切割成小视频片段或GOP实现视频的并行处理.
以上方法虽然能够实现视频数据的并行处理,但视频切割为小片段视频或GOP得到的数据粒度依然很大.
这种实现方法在对视频进行人脸提取和识别任务上并行度和可扩展性都不是优先出版计算机应用研究第34卷很高.
本文利用对视频进行人脸提取和识别实质上是对单个视频帧处理而非像视频转码需要关注连续视频帧的特点,将视频数据解耦合为图片数据集进行处理.
然而由于视频的高压缩率导致解压后图片数据量的倍增,这使得对数据的储存和处理代价变高,本文基于视频中相邻图片序列相识度高的特点,在Spark读取数据流的同时,将数据流解析为视频数据包并从中计算获取关键帧来减少解压后图片信息的冗余,实现了一个高可扩展的并行提取视频中人脸图片并进行识别的框架.
1海量视频人脸提取与识别框架设计1.
1框架目标面对海量视频数据,视频处理框架需要具有并行处理数据的能力,本文在框架设计时充分利用所执行任务的特点,使框架获得更高的可扩展性.
为了达到这个目的,本文需要完成两个阶段:得到视频数据中的人脸,随即对人脸数据库进行快速识别.
本文基于Spark平台实现并行处理视频数据,要解决以下三个问题.
1)如何解决视频数据之间的耦合关系在Spark分布式处理框架中,并行计算的核心是基于RDD实现的数据内存共享机制,RDD数据分片之间的窄依赖关系不仅能有利于执行速度的提升而且能使框架具有更高的扩展性[8].
RDD的关系如图1所示,RDD1到RDD2之间为窄依赖关系,即下一个RDD中数据分片只会依赖上一个RDD数据分片中的一个生成,而RDD2到RDD3之间是宽依赖关系,即下一个RDD中数据分片会依赖上一个RDD数据分片中的多个生成.
宽依赖关系将引起Spark费时的Shuffle操作[8].
因此有效减少RDD转换过程中数据依赖关系将大大加快Spark的运行速度.
图1Spark中RDD依赖关系然而视频文件是一种高度压缩的数据文件,对其处理时需要先对其进行解压,解压过程视频帧之间相互依赖,这种紧耦合关系使数据很难进行并行化处理.
解压过程如图2所示,其中I帧为独立帧其解压不参考其他帧,B帧的解压需要参考其前后的I帧P帧,P帧的解压则需要参考其前的I帧或P帧.
另外视频封装格式等视频元信息也只在视频数据头部出现.
如果在Spark上对视频数据直接切分进行分布式计算将导致视频数据无法正常解压.
另外在RDD的变换中参考这种前后帧信息,Spark中RDD数据分片之间将出现宽依赖关系也会影响Spark的运行速度.
文献[2]中在实现对视频转码的处理时,将视频切割成更小的完整视频片段来提高任务的并行处理能力,而文献[3]将视频的处理切分为更小的GOP进行处理.
图2视频解码各帧依赖关系经过分析,对视频进行人脸的提取和识别是针对单个视频帧内容的处理,而不像视频转码一样需要关注视频帧时序问题.
因此本文在Spark读取数据流的同时将视频文件解耦成独立的图片集,仅对图片数据集中的人脸进行提取和识别,从而达到对视频进行人脸提取和识别的目的.
由于完全消除视频帧的前后依赖,使得对视频中人脸提取和识别的任务能够并行运行,并且由于处理的数据粒度更小,任务的并行度也大大提高,使得框架获得更好的扩展能力.
然而将视频数据集转为图片数据进行处理,由于视频文件的解压会造成图片数据的倍增,这就对存储系统造成巨大压力.
通过对比发现视频每秒几十帧的数据中,各帧之间差异很小,相邻图片序列的信息完全可以通过计算图片的距离差异选择阈度内的图片作为图片序列进行浓缩.
基于此本文通过计算数据流中相邻图片序列的距离选取关键帧的方式对数据集做了一些优化.
2)如何对图片集进行处理通过解耦得到图片集后,任务的处理只在单张图片上进行,这种数据的独立特性使得对图片的处理能够并行化.
将视频文件数据集解耦成图片数据集之后,消除了数据之间的依赖关系,对视频数据集的处理转为对图片数据集的处理.
图片数据集中生成的RDD分片在内容上不再相互依赖,使得前后代RDD之间的为窄依赖关系.
而这种的窄依赖关系提高框架在海量数据情况下的高可扩展性.
本文通过使用Spark并行化运行,检测图片中的人脸,并对图片中的人脸进行提取并保存到数据库.
数据集的处理就同普通文本文件的处理类似.
在视频和图像处理方面有非常成熟的开源库,但是这些处理库大部分由C++语言编写(如OpenCV[9]),如果能在实现视频处理框架上直接使用这些现有的函数库,将大大减少框架的复杂度增加框架的通用性.
在对外部处理库的调用中有多种实现,如通过JNI[10]、SparkPipe.
文献[11]中调用了JavaCV(OpenCV提供的java版)对视频处理.
而文献[5]通过实验将JNI、pipe、以及streaming等实现方法进行对比,结果显示使用JNI的方式调用外部库在视频处理上有更高的性能.
3)如何快速响应用户查询在对人脸识别时为了加快用户查询人脸图片的速度,本文通过比较存储在HDFS中由计算得到的图片特征向量的相识度作为识别指标,并将结果返回给用户.
在用户对给定目标进行查询时希望框架能够快速响应,然而当用户通过给定的图片去匹配数据库中的人脸图片时,需要遍历数据库中每张人脸并且计算图片的特征进行识别操作,每次查询都会进行重复计算,因此本文将图片存入数据库的同时对人脸提取特征向量.
而且特优先出版计算机应用研究第34卷征向量结构简单、数据量小,将RDD中数据分片中的特征向量作为一个文件进行存储可以减少管理数据的开销.
本文将特征向量转成二进制码直接存入HDFS中,由HDFS完成本地存储.
本文对存储在HDFS中的特征向量进行了优化处理,大大减少了特征向量的数据量,加快了框架的运行速度.
Spark在对数据进行读取时,对内存空间敏感,如果能有效利用内存将提高计算性能[7].
假设文档中的数据记录有100条,当存储的数据较大时,假设内存调页时一页中的数据为5条,每次读磁盘的时间为t,访问内存的时间为T,那么100条记录需要调页20次,则读取100条数据记录的时间为100T+20t.
如果对数据进行优化,使得每页包含数据8条,则读取磁盘消耗的时间为12.
5t,则访问100条记录的时间为100T+12.
5t,而访问磁盘的时间t要远远大于访问内存的时间T,因此减小记录的数据量能够有效提升运算的速度.
通过分析输出结果,发现提取到的图片特征向量是稀疏的,可以对向量压缩优化来减少数据量,对数据压缩的同时,要求压缩和解压缩的计算量非常轻量,不会出现因为计算的复杂性而导致计算负载加重.
图3视频处理框架1.
2框架设计本文提出的框架将视频数据处理的阶段分为两个单独的处理阶段,即为视频处理阶段和人脸识别阶段,分别如图3、图4所示.
为了实现上文中的目标,本文通过以下设计进行实现.
a)为了实现对视频文件的解耦合,在Spark读取视频数据时,本文通过调用Xuggler[12]将Spark读入的二进制数据解析为视频流,并对得到的视频流进行解码,从解码得到的数据包中依次读取数据获得视频图片序列.
根据视频帧中相邻图片序列信息差异小的特点,本文通过Spark读取数据流与相邻图片序列距离计算同时进行的方式得到能够代表图片序列的关键帧来减少图片信息的冗余.
视频数据是一种高度压缩的数据形式,在将视频数据转换为图片数据的过程中,Spark读取视频数据的二进制数据流,并调用外部处理库进行解压得到视频帧图片,同时对图片进行缓存用于下阶段的处理.
然而通过解码视频数据中的视频帧得到的数据量将成倍增长.
如30MB大小480*320分辨率每秒25帧的视频解压成图片后的数据大约为301.
32MB,数据量扩大了十倍左右,巨大的数据量不仅会对数据存储和管理造成很大压力而且因为图片数据信息的冗余处理效率也会受到影响.
本文对视频转换为视频图片的过程进行了优化.
为了解决视频解压后数据量倍增的问题,经过对比产生的视频图片发现,视频解压的图片序列相邻图片的差异非常的小,对这些图片进行人脸识别得到结果差别很小.
因此本文在读取数据流的同时通过计算解压所得图片的差异,选出能够代表相邻图片的关键帧,从而大大降低图片的数据量.
假设从数据包中获得的图片序列为I,,每张图片为RGB三维的像素矩阵,初始状态下本文把第一张图片作为本数据包中第一个关键帧,假设某时刻得到的关键帧为,该时刻解压得到的图片为,通过公式(1)计算两者的曼哈顿距离作为两张图片的差异E.
(1)其中,分别为和第k维的像素值,本文取阈值为,将E与阈值比较,通过公式(2)得到图像操作布尔值d.
(2)阈值是一个经验参数,其决定了得到的关键帧之间相识程度.
选取过大将导致视频信息的丢失,过小则不能有效地减少图片帧的冗余,会使得框架计算量增加、作业时间运行时间长,可根据实际情况来选择合适的使得数据帧信息不丢失的前提下得到更少的冗余信息.
当d为true时,图片作为下一个关键帧,并将放入缓存队列中,当d为false时,丢弃本张图片从数据包中获得下一张图片.
直到读完本数据包中的数据,并从视频流中获取下一数据包,循环运行得到下一阶段处理所需的关键帧序列.
优先出版计算机应用研究第34卷经过优化后,视频获取关键帧与Spark读取数据流同时进行.
但是这也增加了从视频中获取图片的时间开销,本文在单节点上对50MB的视频文件进行处理结果如表1所示.
经过优化后,提取到的关键帧图片数据量大大减少,虽然处理图片的时间有所增加,但数据量的减少使得后续的处理时间降低,加快了整个视频处理框架的速度.
表1提取关键帧优化前后对比优化前优化后图片数据量468.
3MB3.
7MB运行时间10321ms12251msb)本文通过JavaCPP[13]实现了对现有的开源图像处理库OpenCV的JNI调用,实现了对图片的人脸检测以及人脸截取等有关图像的操作,JavaCPP能够实现对C++的高效JNI调用,在此不做过多讨论.
OpenCV中提供了已经训练完成的级联分类器,可以方便的用来进行人脸检测.
本文使用Haar[14]级联分类器作为本文框架的人脸检测方法.
本文将检测到的人脸图片通过OpenCV中提供的操作,将人脸区域截取保存将图片并送入下一个处理过程.
c)在人脸识别阶段,需要检索整个人脸数据集空间找出与给定人脸最相近的结果,本文通过提取并优化人脸特征向量以及利用数据本地性特征来达到快速人脸识别的目的.
图片主要有颜色特征[15]、纹理特征[16]、形状特征[17]等,纹理特征更适用于人脸识别.
本文实现了基于纹理的人脸特征向量进行相似度计算的分布式方法,通过计算特征距离向用户返回人脸识别结果.
由于计算特征向量距离简单,本框架面对海量视频不仅在运算速度上而且在高可扩展性上都有着很大的优势.
获得图片纹理特征成熟的方法是通过计算局部二值模式(LocalBinaryPattern,LBP)得到,本文通过计算LBP特征得到图片的纹理特征.
LBP特征提取简单而且在表征图像的纹理特征上对光照的鲁棒性很强[18].
本文采用的是改进的LBP——圆形LBP算子提取特征.
通过计算LBP特征的直方图得到人脸的特征向量.
本文中使用人脸识别中广泛应用图4人脸识别框架的卡方距离对向量进行距离计算[9].
假设从用户给定图片中的人脸通过计算得到特征向量为,当前检索特征向量为,特征向量为的矩阵,则向量距离D通过式(3)计算.
(3)其中m为向量中的分量个数,通过得到的向量距离与人脸识别筛选阈值比较,通过公式(4)得到图片返回操作布尔值t.
(4)阈值是用于度量计算所得的特征之间的差异程度.
阈值选取过大将使相同的人脸错分为不同的人脸,选取过小将使得大量的非同一人脸错分为相同的人脸.
因此阈值的选择影响了检索出的人脸的正确率与误正率(将同一个人的图像作为不同人的比例)之间的平衡.
在实际使用中可通过多次实验平衡检索结果的精度和误正率选取适当的.
当t为true时,将通过获取的索引从数据库中返回该图片,t为false时,则跳过.
继续遍历所有图片特征向量.
通过对特征向量的分析,发现提取到的特征向量中相邻的元素零值会连续出现而这些零值大约是特征向量数据中非零元素所占空间的7倍左右.
基于此特征,本文对向量数据进行压缩优化.
压缩过程如图5所示.
将一维特征向量的浮点数转换为字节形式,经过转换后的稀疏矩阵可以获得更多的8位字节型0,将连续的0表示为连续0的个数n和一个0,即可将多个0数值元素压缩.
本优化中将0作为特殊标志表示其前的数值n标志0的个数,最终得到一个只含少数零值约为原来数据量八分之一的字节数组.
本文中的优化过程结合特征向量的特点,大大的减少了特征向量所占的空间.
对特征向量进行计算时只需要简单的逆运算便可恢复原来的特征.
图5特征向量压缩2海量视频人脸提取与识别并行框架实现通过对视频处理任务特点的分析,本文在读取数据流的同时解耦视频数据获得松耦合的图片数据集,在图片集上实现对优先出版计算机应用研究第34卷图片的并行处理从而提高框架的可扩展性.
以下介绍本框架的主要代码实现.
1)视频数据读取实现Spark处理视频数据时,需要从HDFS上读取视频数据,通过调用Spark提供的接口newAPIHadoopFile()来读取HDFS文件.
该函数需要四个主要的参数,文件路径、FileInputFormat类、key值类型和value类型.
为了实现视频数据从HDFS到Spark的高效通道,定义了以下三个类.
a、VideoInputFormat类,Spark通过该类获得HDFS中数据的逻辑切分单元以及获取将数据转为键值对的RecordReader类.
该类扩展Spark提供的mapreduce包中的FileInputFormat,Spark通过调用该类中的getSplits()方法读取数据分片,其中通过isSplitable()来判断是否对数据进行切分.
b、VideoRecorderReader类,Spark通过该类获得从视频文件获得键值对的方法.
该类扩展RecordReader类重载其中的方法,在initialize中为了实现对各种视频格式的处理,本文调用了Xuggler作为读取视频的工具,在initialize()方法中从逻辑分片地址读取视频流获得视频格式信息,初始化视频解码器.
c、ImageWritable类,Spark读取视频中的关键帧,将关键帧封装为ImageWritable,作为K/V对中的值进行下一步处理.
该类扩展Writable类实现数据的写入和读取.
2)对图片进行人脸检测为了检测关键帧中的人脸本文实现了RecognizeFaces类供Spark来调用.
Spark通过javaCPP调用OpenCV处理库.
3)提取人脸特征向量本文实现了自定义类GetFaceFeature来获得人脸的特征,本文通过定义getFaceLBPH()方法得到特征向量.
本文实现方法compressFea()和decompressFea()对特征向量进行了压缩优化和解压.
4)图片与特征向量存储实现了SaveImageAndFea类来完成框架中对数据存储管理.
包括连接数据库、存储图片查找图片以及存储特征.
为了加快对人脸图片的识别,本文对图片和特征向量进行存储.
人脸图片存储于MongoDB作为识别结果返回给用户.
本文利用MongoDB中GridFS对图片进行存储[19].
3性能测试3.
1实验环境本文中的Spark实验平台基于广州天河2号云平台,使用CDH构建的SparkonYarn集群.
集群共有10个节点,1个主节点和9个从节点.
节点系统为Ubuntukylin14.
04.
其中Master节点配置为8核CPU,16G内存,260G虚拟硬盘.
8个worker节点配置为4核CPU,8G内存,260G虚拟硬盘.
3.
2框架视频处理扩展性分析为了验证本框架处理视频数据的可扩展性,本系统在spark的Standalone模式下,将worker节点分别设置为1、3、5、7、9.
通过测量处理200GB数据的所用的时间,来测试本框架的处理视频的扩展性.
本文定义系统总时间等于应用运行时间与计算节点数的乘积,即:(5)用于衡量系统全部机器运行时间.
定义加速比为1个计算节点时的运行时间与个计算节点运行时间的比值即:(6)用来表征系统的可扩展性.
实验结果如图6所示.
实验表明9个计算节点时系统处理200GB图片需耗时10180秒,系统的总运行时间比单节点时运行时间增加4737秒,约占单节点系统总时间的5.
45%,同时实验数据表明9个计算节点时,系统比单节点加速8.
53倍.
因此该系统在随着处理节点的增加系统的加速比基本成线性增长,系统总运行时间增长较少,系统具有良好的可扩展性.
图6处理视频的可扩展性图7系统识别人脸性能图8主要模块执行时间3.
3框架人脸识别扩展性分析同样在spark的standalone模式下,对框架识别人脸的可扩展性进行了实验.
测试数据为200GB视频提取到的图片特征向量,提取到数据为143850张人脸图片的特征共约1269MB,本文选取两张人脸进行识别.
因为本系统的数据处理时间在秒级优先出版计算机应用研究第34卷完成,系统的启动时间也就是Spark启动计算节点的时间随着运算节点的增加也会增加.
Spark启动任务消耗的时间为固定时间,当系统耗时较少时,启动计算节点的时间会占系统时间的很大比例.
因此本文对计算节点为时,spark启动任务所用时间进行了测量.
本文单独计算出系统处理作业的时间,用于表征系统的可扩展性.
(7)当作业处理数据增加时,同样集群下spark启动计算节点的时间并不会随之增加.
因此,通过分析作业的运行时间可以来衡量系统的可扩展性.
同样本文定义作业的加速比为1个计算节点是作业的运行时间与i个计算节点时的运行时间的比值,用来衡量系统的可扩展性.
即:(8)实验结果如图7所示,实验表明9个计算节点时处理系统在识别人脸时处理143850张图片的系统耗时17.
057秒,减去系统启动计算节点的时间,运行作业的时间为2.
738秒.
9个计算节点时运行作业的时间比单节点是加快了7.
96倍.
本系统在识别人脸时不仅能够快速完成同时具有良好的扩展性.
3.
4框架模块执行时间分析为了进一步分析系统的执行效率,通过对视频数据的处理,本文测出整个框架主要模块的执行时间,实验中本框架使用了200GB视频数据,1个主节点和9个从节点.
执行时间如图8所示.
从视频流中获取关键帧和人脸识别两个模块的执行时间占整个任务执行时间的89.
64%.
通过日志输出分析,获取关键帧模块中主要时间用于视频文件的解码上,整个解码过程大约占获取关键帧模块时间的97%.
而在人脸检测模块主要的时间花费用于对图片进行人脸检测,约占该模块执行时间的93.
8%.
本文使用了OpenCV中cvHaarDetectObjects方法进行人脸检测,该方法提供了多个可选参数,因此本框架提供了scaleFactor、minSize、maxSize等参数的选择,通过调节这些参数达到不同的检测要求,优化框架运行时间.
scaleFactor、minSize和maxSize分别用于设定图像前后两次扫描的窗口大小比例以及检测窗口的最小和最大值,scaleFactor值越大则从最小窗口增大到最大窗口的步长越大,检测的速度越快,但可能出现漏检的结果.
同时通过设定检测窗口的最小和最大值,也可以影响到检测的准确度和速度,具体的调节可参考OpenCV的文档说明.
例如scaleFactor参数用于调节前后两次扫描中搜索窗口的比例系数,本文将其从1.
1增大1.
5时,框架的运行时间从10180秒降为7581秒,时间减少了原来的25.
55%,人脸检测时间也从原来的3816秒减少至1423秒,但是检测到的人脸从原来的143850张减少到了68548张.
这表明实际运行可以根据具体的需求定制不同的参数配置,满足不同的处理需求.
3.
5特征向量优化分析为了测试本文对特征向量的优化是否减少了框架的执行时间,本文对200GB视频数据处理得到的特征数据进行了压缩、非压缩实验.
实验证明,本文的数据优化方法大大减少了特征数据的数据量,比非优化状态下数据减少了7.
08倍,同时也加快了识别人脸的过程.
实验结果如下表2所示.
实验表明本文的数据优化方法大大减少特征数据量的同时减少了框架的总运行时间.
表2压缩与不压缩特征数据结果压缩非压缩比例特征数据量1269MB8996MB1:7.
08总运行时间17.
05s26.
96s1:1.
58作业时间2.
73s12.
60s1:4.
62特征处理时间2.
31s1.
56s1.
48:14结束语Spark基于内存的分布式计算框架,本身具有很强的计算性能,本文基于Spark实现了海量视频人脸的提取和识别的并行框架.
本文根据Spark框架的特点,将视频数据集的处理转换为对图片数据集的处理,使得数据处理产生RDD时使用单依赖关系,避免多依赖进行shuffle操作带来的系统消耗,并通过提取关键帧减少数据量.
实验结果表明本文提出的框架在处理视频数据上提高了框架的并行度并且获得了很好的可扩展性,随计算节点的增加,计算速度几乎线性增加.
在进行人脸识别时,本文提出的分布式识别方法同样有很好的可扩展性.
在识别海量人脸图片时,本文将特征数据进行压缩优化,进一步减少识别人脸图片时任务的完成时间.
为处理海量视频独立内容(如人脸检测、物体识别等,另一种处理则需要内容相互依赖,如视频转码、视频浓缩、运动跟踪等)提供了一种实现.
参考文献[1]WhiteT.
Hadoop:Thedefinitiveguide[M].
[S.
1.
]:O'ReillyMedia,Inc,2012:10-109.
[2]GarciaA,KalvaH,FurhtB,Astudyoftranscodingoncloudenvironmentsforvideocontentdelivery[C]//ProcofACMMultimediaWorkshoponMobileCloud.
2010:13–18.
[3]RyuC,LeeD,JangM,etal.
ExtensibleVideoProcessingFrameworkinApacheHadoop[C]//ProcofIEEEInternationalConferenceonCloudComputingTechnologyandScience.
2013:305-310.
[4]FFmpeg,Acomplete,cross-platformsolutiontorecord,convertandstreamaudioandvideo[EB/OL].
2016(2016-4-29).
https://ffmpeg.
org/.
[5]ZhaoX,MaH,ZhangH,etal.
HVPI:ExtendingHadooptoSupportVideoAnalyticApplications[C]//ProcofInternationalConferenceonCloudComputing.
WashingtonDC:IEEEComputerSociety,2015:789-796.
[6]BorthakurD.
Thehadoopdistributedfilesystem:Architectureanddesign[J].
HadoopProjectWebsite,2007,11(11):1-10.
[7]KarauH,KonwinskiA,WendellP,etal.
Learningspark:lightning-fastbigdataanalysis[M].
[S.
l.
]:O'ReillyMedia,Inc.
2015:15-321.
[8]ZahariaM,ChowdhuryM,DasT,etal.
Resilientdistributeddatasets:afault-tolerantabstractionforin-memoryclustercomputing[C]//ProcofUsenixConferenceonNetworkedSystemsDesignandImplementation.
优先出版计算机应用研究第34卷2012:141-146.
[9]OpenCV.
OpenSourceComputerVisionLibrary[EB/OL].
2016(2016-01-01).
http://opencv.
org/.
[10]GordonR.
EssentialJNI:Javanativeinterface[M].
[S.
1]:Prentice-Hall,Inc.
,1998:1-245.
[11]TanH,ChenL.
AnapproachforfastandparallelvideoprocessingonApacheHadoopclusters[C].
[S.
l.
]:InternationalConferenceonMultimediaandExpo.
2014:1-6.
[12]ConnectSolutions,LLC.
XugglerDocumentation[EB/OL].
2016(2016-01-01).
http://www.
xuggle.
com/xuggler/.
[13]javaCPP.
JavacppIntroductionandOverview[EB/OL].
2015(2015-03-15).
https://github.
com/bytedeco/javacpp.
[14]LienhartR,MaydtJ.
AnextendedsetofHaar-likefeaturesforrapidobjectdetection[C]//ProcofInternationalConferenceonImageProcessing.
2002:I-900-I-903vol.
1.
[15]AlataO,BurieJC,MoussaA,etal.
Choiceofapertinentcolorspaceforcolortexturecharacterizationusingparametricspectralanalysis[J].
PatternRecognition,2011,44(1):16-31.
[16]RahmanMH,PickeringMR,FraterMR,etal.
Texturefeatureextractionmethodforscaleandrotationinvariantimageretrieval[J].
Electronicsletters,2012,48(11):626-627.
[17]DharaniT,AroquiarajIL.
Asurveyoncontentbasedimageretrieval[C]//ProcofInternationalConferenceonPatternRecognition,InformaticsandMobileEngineering.
2013:485-490.
[18]OjalaT,PietikainenM,HarwoodD.
PerformanceevaluationoftexturemeasureswithclassificationbasedonKullbackdiscriminationofdistributions[C]//ProcofInternationalConferenceonPatternRecognition:ComputerVision&ImageProcessing.
1994:582-585.
[19]ChodorowK.
MongoDB:thedefinitiveguide[M].
[S.
1]:O'ReillyMedia,Inc.
,2013:23-256.