蒋春燕，王佳斌，郑力新

　　（华侨大学 工学院，福建 泉州 362000）

　　摘要：随着社交网站崛起、通信和多媒体技术的高速发展，视频、图像日益增长并己成为人们传递和获取信息的重要方式，目前H.264和JPEG2000己成为视频和静止图像领域应用较为广泛的压缩标准。如何高效挖掘海量视频的价值已经成为当前研究的热点问题，然而视频解码是发掘海量视频知识的前提。重点研究在分布式平台下对SDV格式的网络监控视频进行解码，利用Xuggler视觉库设计了能在云环境下Hadoop平台上使用的视频数据类型，解决了Hadoop平台上直接分割视频遇到的帧不完整、缺关键帧和少头数据信息的问题，并比较了传统单机解码与分布式解码的优缺点。

　　关键词：云环境；分布式；视频解码

0引言

　　*基金项目：泉州市重点科研项目（2013Z12）当今社会随着移动终端设备和多媒体技术高速发展，Facebook、YouTube等大型社交网站迅速崛起，人类对信息的要求也越来越丰富，特别是直观性很强的图像和视频信息，人们可以从中获取更多的细节信息。然而，视频和数字化图像信息内容复杂，存在着一些明显的缺点，如信息量大，不适合应用于实时性要求高的场合，这给信息的存储和网络传输带来很大困难，进而成为制约人们获取和挖掘视频信息的主要瓶颈。而一种新型的网络视频点播格式——交换式视频广播［1］（Switch Digital Video, SDV）格式的视频系统通过虚拟资源列表能有效解决这一瓶颈。本文将针对该格式的视频进行云环境下的分布式解码［2］研究。

1研究现状

　　目前广播数字电视网中实现SDV系统主要基于两种技术架构:一种是1997年由美国Time Wanner Cable公司提出的基于开放协议的ISA［3］(交互服务架构);另一种是2007年由美国Comcast公司提出的基于私有协议框架的NGOD［4］(下一代视频点播服务架构)。

　　SDV［5］系统是广电网运营商提供的一种新型点播业务，意在允许用户通过点播广播数据的方式获取更多的广播电视资源，其实现方案依靠在网络中新增SDV服务器和SDV客户端，并通过它们的通信交互，完成HFC段带宽的交换式使用，实现资源列表提前下发。越来越多的网络监控视频也开始使用SDV的视频格式将监控视频保存在云端，用以形成监控视频云。

　　单机己经没有能力处理监控视频云端的大量视频数据，云环境下分布式平台能解决这一难题，因此需要借助云计算技术及分布式技术来分析问题并解决问题。但是现有的分布式计算平台如Hadoop［6］一般是处理文本数据，只提供处理文本数据的接口。而视频文件一般是压缩文件，且视频编码技术十分复杂，视频文件编码格式多种多样，如果要使用Hadoop云平台进行视频处理［7］，还有许多工作要做，而基于内容的视频分析中视频解码是视频中内容分析的前提。

2设计数据接口

　　2.1Hadoop数据类型的分析

　　Hadoop在与用户写的Mapper和Reducer通信时，总是使用类型化的数据从文件读入到Mapper中，Mapper向Reducer提交的文件和Reducer输出的文件均以Java对象存储。而可以与文件和网络相互通信的对象必须遵循特定的接口，叫做Writable［8］，它允许Hadoop以一种序列化的形式读写数据以适用于传输。Hadoop的io包中提供了几个基本的Writable类型，如BooleanWritable(标准布尔型数值)、ByteWritable（单字节数值）、DoubleWritable（双字节数值）、FloatWritable(浮点数)、IntWritable(整型数)、LongWritable(长整型数)、Text(使用UTF8格式存储的文本)、NullWritable（当〈key,value〉中的key或value为空时使用）等，Hadoop自带的数据类型如图1所示。图1Hadoop自带的数据类型这些都是基本数据类型，复杂数据类型如xml文本、图片、视频等都需要用户自定义数据类型。自定义数据类型就得继承接口Writable,实现其方法write()和readFields(), 以便该数据能被序列化后完成网络传输或文件输入/输出。如果该数据需要作为主键key使用，或需要比较数值大小，则需要实现WritalbeComparable接口,实现其方法write()、readFields()等，在MapReduce中使用时，设置相应的Map或Reduce的class类型即可。

　　2.2hadoop平台上视频数据类型的设计

　　Hadoop的分布式文件系统HDFS设计之初是为了处理文本大数据，但只要被写入的数据很少被改动，并且对数据的操作主要是大规模的流式读取和小规模的随机读取，原则上HDFS就可以存储任何类型的数据，因此，视频数据可以上传到HDFS之上。但要分析HDFS上视频帧数据，就得设计视频数据接口。本文设计了视频数据接口HVPI。本研究的对象是SDV格式的网络监控视频，该视频是由小视频组合的，通过不分割视频，即让整个数据块作为输入分片被传给视频录入接口,它使用开源视频编解码库Xuggler来解析视频中的帧。Xuggler支持非常多的视频编码格式，基于它的视频读写接口VRWI也同样支持很多格式。它将视频文件转化为键值对，这些键值对被逐一地传给map函数。HVPI接口结构图如图2所示。

　　视频读写接口VRWI位于分布式计算框架MapReduce和分布式文件系统HDFS之间，将视频文件转化为MapReduce计算框架Map阶段可以读取键值对的形式。MapReduce依赖于InputFormat抽象读取输入数据，将其转化为传送给Map函数的键值对。这一输入分片抽象类主要包含两个抽象方法，得到分片方法和视频录入接口方法。如图2所示， 视频读写接口首先将视频文件抽象为InputSplits(输入文件的逻辑分片），一个输入分片交由一个Mapper处理。然后视频接口解析每个输入分片生成键值对<视频文件路径帧号，帧图像>，并传递每个键值对到Map函数，为后期对监控视频内容进行分布式处理打下基础。

3Hadoop平台处理视频数据

　　3.1在Hadoop上直接处理视频数据的局限性

　　视频文件上传到HDFS之后，根据用户设定的Block大小，分布式地存储于集群中的数据节点之上，此时，所有按默认顺序分配到各数据块上的文件若大于64 MB，将都被物理分割。数据节点通过维护文件系统的元数据对文件进行管理，而HDFS面向用户的接口又是一个完整连续的文件，HDFS对用户隐藏了分割的细节，视频文件是经过编码和压缩后的帧序列，解码生产帧序列时需要视频的头数据和关键帧。若头数据和关键帧不在同一个数据块，则分割后的视频数据块将会缺少关键帧或头数据。因为帧序列大小不一，分割后很可能还会出现帧不完整，如图3所示。

　　由图3可知，若一个视频大于Hadoop默认的数据块大小，若严格按默认数据块大小分割，则数据块可能出现帧不完整，如数据块Block1、Block2、Block3；也可能缺少关键帧，如数据块Block2；或缺少头数据，如数据块Block2、Block3、Block4。故数据块Block1、Block2、Block3、Block4均无法得到完整的帧序列。直接使用Hadoop分割监控视频只适用于本地监控视频数据大小与HDFS默认的数据块大小相等的视频数据，否则将出现以上问题。

　　3.2在Hadoop上直接处理视频数据的方法

　　现有的SDV格式的监控视频数据的特征是，监控视频都是前景变化才录制，并将监控视频数据存储在云端，且每段监控视频的大小从8 MB到32 MB不一。若每个本地视频在上传到HDFS上之前选经过预处理：在上传缓冲区中计算每段视频的大小，当该视频大小上传到HDFS上后的数据块累加大小接近默认数据块大小时，才允许上传，否则计算下一段本地视频大小，依次类推。这样在HDFS上的数据块大小都接近默认数据块大小，在Map阶段进行处理时的逻辑分割中保证每个数据块都不再分割，一个Map任务处理一个数据块，这样在分布式处理时的数据负载均衡也会得到保证，本文设计的HVPI数据分割示意图如图4所示。

　　若HVPI接口中的split()［9］函数返回值为错误，即不分割数据块上的数据，则让整个数据块作为输入分片传给视频录入接口，实现每个Map任务处理一个数据块。这样本地SDV格式的监控视频上传到HDFS上的数据块后，在MapReduce计算框架中解码时，将会避免直接使用Hadoop分割视频时出现的问题。

4实验分析

　　4.1实验集群概述

　　硬件环境：Hadoop集群由3台PC组成，每台PC的CPU为Intel(R) Pentium(R) 4 CPU 2.80 GHz，内存为2 GB，硬盘为455 GB。其中1台作为集群Master，2台作为集群Slave。运行环境：操作系统Ubuntu 14.04.1， Hadoop 2.6.0，JDK 1.7.0_79，Eclipse 4.5（64位），Xuggler 5.4。配置： 本Hadoop平台包括一个master节点，即namenode节点，主要负责任务分配和调度；两个slave节点，即datanode节点，负责数据存储和计算。

　　4.2视频解码方法

　　本实验数据使用的是某监控视频中的一个摄像头的监控视频数据，该监控视频格式是SDV格式，该监控视频的特点是只有前景变化时才会开启录制模式，当前景消失在目标检测区域时，停止录制并将录制视频数据保存到该设备对应的云环境中。

　　本实验选取了某天的监控视频上传到本实验环境所在的本地系统中，并进行解码实验，单机处理视频解码的流程图如图5所示，本地监控视频通过OpencV接口的IplImage图像处理函数库，逐个进行视频解码。在Hadoop上处理分布式视频解码的流程图如图6所示，本地视频通过HVPI接口、视频大小统计等算法上传至HDFS上，进行分布式并行视频解码处理。

　　相比早期版本，Hadoop2.X版本的中HDFS文件块大小增加了一倍，数据块增大的原因有减轻了命名节点的压力，因为Hadoop集群在启动的时候，数据节点会上报自己的Block信息给命名节点，命名节点把这些信息放到内存中。如果块变大了，命名节点记录的信息相对减少，所以命名节点就有更多的内存去做别的事情，使得整个集群的性能增强。因为这个可以灵活设置，所以这里不是问题。关键是什么时候，该如何设置。如果数据量级别为PB的话，建议把Block设置得大一些。如果数据量相对较少，可以设置得小一些，如64 MB也可以。如果网络环境不好，可能会造成重新传输。

　　使用Hadoop2.X中HDFS文件块默认的大小128 MB，在上传本地视频之前先计算待上传视频的大小，并累计大小，若超过128 MB，则再判断下一个视频数据的大小，保证HDFS上每个视频数据块的大小接近128 MB，从而保证每个数据块对应一个Map任务，流程图如图7所示，解码无需分割视频块，同时也保证了整个Hadoop分布式任务的负载均衡性。

　　4.3实验结果分析

　　如图8所示，使用单机处理进行解码，数据存储和解码都在本地进行，目前流行的视频播放软件均采用这种模式。该方式的优点是架构简单，不需提供额外的视频管理机制，即用即解；缺点是解码效率受节点配置影响，拓展性较差，数据安全性也较差，对大数据的处理能力有限。

　　然而用云平台下分布式系统进行解码，监控视频无需分割，在上传缓冲区计算各分块的大小，然后上传到分布式文件系统上。该方式的优点是利用了分布式计算框架，通过并行处理提高了解码效率，充分利用分布式文件系统存储的优点；不足在于监控视频数据定时读取而不能实时上传到分布式文件系统中，难以实现在线实时处理。

5结论

　　本文主要针对SDV格式监控视频特点，提出了一种处理监控视频解码的分布式方法，并进行了实验。实验证明了云环境下分布式解码效率比单机处理的优势，然而解码的正确率和更大集群的分布式在线测试有待更深入的研究。

参考文献

　　［1］ 李福堂，卢强，刘继华.同洲电子SDV解决方案［C］. 2010国际传输与覆盖研讨会论文集，2010：327338.

　　［2］ 郭奕希.基于Hadoop的视频转码系统设计与实现［D］.武汉：华中科技大学，2011.

　　［3］ PEGASUS Interactive Services Architecture 1.4［S］.USA: Time Warner 2003.

　　［4］ Comcast Corp. NGOD Overall Architecture.Version 2.0［Z］. 2006.

　　［5］ 颜文清.交换式数字电视(SDV)的应用与推广［J］.有线电视技术，2012 (1):6064.

　　［6］ 何海林,皮建勇. 大数据处理平台比较与分析［J］. 微型机与应用,2015,34(11):79,17.

　　［7］ 高东海，李文生，张海涛.基于Hadoop的离线视频处理技术研究与实现［J］.软件，2013,34(11): 59.

　　［8］ WHITH T.Hadoop:the definitive guide: the definitive 2009［C］.O′Reilly Media Inc，2009:105151.

　　［9］ 赵晓萌.云环境下监控视频结构化分析研究与实现［D］.北京：北京邮电大学，2015.