分布式视频处理框架及基于Hadoop的参考实现

2016-12-12丁圣勇樊勇兵陈楠

广东通信技术 2016年11期

［丁圣勇樊勇兵陈楠］

［丁圣勇樊勇兵陈楠］

随着互联网、智能终端以及APP的快速发展，视频数据成为极其重要的数据来源，视频中包含了大量文本无法承载的信息。由于视频数据具有量大、高度非结构化特点，大规模视频数据处理非常困难。文章提出一种基于大数据平台的视频处理系统，该系统充分利用大数据平台的能力实现视频处理的分布式调度，使得开发者仅需要关注算法部分，从而大幅度提升开发效率。

大数据视频处理视频解码 Hadoop

中国电信广州研究院，2001年本科毕业于中国科技大学，2015年获中山大学计算机博士学位，长期从事云计算和大数据技术及应用研究。

樊勇兵

中国电信广州研究院。

陈楠

中国电信广州研究院。

1 引言

随着互联网以及智能终端的发展，视频数据规模呈现爆炸式增长。有报告指出[1]：“智能视频监控、视频内容分析和视频分析每年处理数万亿小时的视频监视图像”。而据邬贺铨院士报告指出：“在线视频将成为消费者互联网流量的主导，网络视频流量比例将从2015年的37.4%增长到2019年的52%；网络视频流量占消费者互联网流量比例从2015年66%增长到2019年80%。2019年以电视机为终端的互联网视频将比2014年增长4倍”。

文本、语音、图像以及图像的序列视频是自然界最重要的信息载体，文本往往用来表达概念，图像和语音则往往记录更为真实的场景，彼此互补而又不可替代。由于图片的摄取更为方便，随着移动互联网的发展，用户越来越倾向于使用图片或视频记录场景。此外，大量的摄像头监控存储了海量数据，这些数据准确记录了监控场景中发生的各种事件。由于视频数据包含了文本数据无法承载的信息，准确挖掘视频数据中包含的信息对实际应用具有重要的意义。

相比文本数据，视频数据处理有几个难点。（1）数据规模远远超过文本，这导致视频数据处理的计算量特别大；（2）视频数据具有高度非结构化特点，原始数据必须经过滤波、检测、识别等一系列复杂操作才能得到有价值的信息。随着深度学习等技术的发展，对视频数据的理解能力越来越高，计算瓶颈问题则相对更为突出。

只有通过瑞士联邦计量研究院 (METAS) 的严苛检测，才能获得印有“MASTER CHRONOMETER CERTIFICATE”的红色认证卡。

由于视频计算密集，单机已经很难满足大规模视频处理需求。对一个大型视频处理系统，尽管开发者可以从头搭建分布式处理系统，但需要花费大量的精力在底层处理框架，如任务加载、数据分割、结果汇总等。考虑到大规模视频处理有相当部分的工作可以重复利用，我们提出一种通用的大规模视频处理平台方案，使得用户只需关注业务逻辑和核心算法。由于大数据技术已经提供了大量的分布式计算方案，我们进一步基于Hadoop平台提出一种参照实现，该框架使用Hadoop的HDFS模块存储数据，视频处理部分使用Hadoop MapReduce通用计算框架，在Hadoop上叠加一层Hadoop Video，负责封装通用的视频处理任务，如视频切割、解码以及接口封装。基于Hadoop Video，应用系统只需实现特定的接口即可实现大规模处理系统。

后续我们称大规模视频处理框架为Big Video，基于Hadoop实现的框架则成为Hadoop Video。

2 系统需求

从开发者角度，Big Video需要支持一下核心功能：

视频存储。首先集群应该提供一个超大的存储空间，用户能够方便的上传并存储视频。支持各种大小的视频文件，同时兼容图像数据。

视频解码。Big Video应该自动提供解码功能，适应各种不同的视频格式。

内嵌函数。Big Video应当提供丰富的图像处理套件，如常用特征抽取，各种矩阵操作函数，滤波函数以及经典的物体检测、识别等。

编程接口。同时提供视频级和帧级别的编程接口，满足有状态和无状态任务需求。在帧级别接口用户仅需对帧进行操作，属于无状态计算。在视频级接口，用户可以使用序列进行操作，也就是能够获得视频整个的序列。

并发调度。能够提供高效的并发调度机制，需要考虑到数据的物理位置尽可能减少跨节点传输。

性能要求。系统能够提供接近线性的扩展能力，也就是处理容量能够随CPU核心数目成准线性增加。同时能够支持GPU并行处理并进行丰富的功能封装，用户无需使用复杂的GPU底层编程接口。

3 关键设计

视频存储：为了并行处理，并减少带宽需求，视频数据应尽可能分布到不同的计算节点，实现一般采用块方式。考虑到视频数据的特殊性，每个块应携带必要的视频编码信息，以保证能够独立解码。

分布处理：由于视频数据巨量，应尽可能减少数据跨节点的传输，包括原始视频数据和解码后的帧数据。因此每个加载的任务应就近处理所在物理节点的数据，这种就近访问思想是大数据平台的重要设计理念。基于此原则，视频解码以及帧处理都应当尽可能在视频段所在的物理机完成。图1给出了相应的示意图。

开发接口：根据任务的不同，我们简单分无状态计算和有状态计算。无状态计算指视频帧的处理不具有前后依赖关系；有状态则相反。这两种不同类型的任务要求平台能够暴露视频级处理接口和帧级处理接口。由于处理任务非常多样，平台需设计层次化的接口，简单可分为Low level和High level接口。Low level接口设计面向一般性计算，不做任何特定假设，比如将所有处理结果抽象为对，key，value是任意对象类型。而High level接口则可以封装为对象检测、物体搜索、背景建模等特定任务。

视频解码：视频解码是视频处理系统特有的前置环节，也是计算密集的环节。视频解码需要考虑的因素包括：

（1）格式支持：应支持主流视频格式，如mp4,mkv,avi,rmvb等。

（2）解码速度：对720p分辨率视频，CPU主频2.5GHZ下，单CPU应能支持每秒300帧以上。

4 Hadoop参照实现

图1 分布式视频处理框架

很多大数据平台如Hadoop在很大程度上已经实现了Big Video处理的基础工作，但由于视频数据的特殊性，从头基于Hadoop开发大规模视频处理系统仍需大量工作（如视频解码，数据切块），在Hadoop上叠加Hadoop Video Layer仍然可以大幅度简化视频处理任务的开发。我们以Hadoop平台为参照，解释如何利用现有的Hadoop功能以及新增的Hadoop Video Layer开发实现Big Video处理框架。

视频存储：利用Hadoop的HDFS模块存储视频，将视频文件存储为Sequence File存储结构，称为Video Sequence File。Sequence File中Key的设计应当能够保证每个视频块可以索引到原始的视频块，以方便后续的回放追踪等。每个value应可以独立解码。由于一个视频文件可能非常大，转储到Sequence File需要预先做切割。切割工具可以使用ffmpeg或基于其开发。从原始视频上传到Hadoop的指定结构称为Hadoop Video的上传模块，由Hadoop Video Layer提供。

视频解码：视频解码通过Map Reduce实现并行。Map的输入为Sequence File，因此一条记录就是一个完整的视频块。Map函数对视频块执行解码，生成一系列frame，并进一步调用由用户实现的FrameProcessor接口的process方法，该方法的输入是解码好的frame，输出是对，output key和output value的具体语义由用户定义。

结果汇总：结果汇总直接使用Reducer实现。由于Reducer的逻辑是按照Map函数的output key进行合并，用户需要重载Reduce函数。

最后，从应用开发角度看，用户程序仅需要重载FrameProcesser和Reducer类，其他全部由Hadoop Video完成。