基于Hadoop的流媒体转码系统设计

（三明学院 现代教育技术中心，福建 三明365004）

1、前言

近年来流媒体用户快速增加，如何以最低的成本来满足所有用户的流媒体需求是现今网络内容服务业者关切的热点。由于网络带宽的限制以及多样化的多媒体设备与视频格式，网络内容服务业者将视频传递到用户必须通过视频转码，将视频流媒体转换成相对应的视频格式，视频转码的用途主要是将视频流进行压缩以减少数据量的传递[1,2]。分布式视频转码是将一视频切割成许多区块，再把这些区块分配给多台服务器主机进行视频转码工作，转码完成后再将各个区块合并成一个视频文件，此方法可提高视频编码的效率，降低用户观看视频的等待时间[3,4]。然而传统分布式视频转码系统，软硬件设备的更新维护及扩充，对于网络内容服务业者成本而言是相当大的负担，网络内容服务业者为了架设分布式转码服务器，必须耗费额外工作量，人力成本也极高[5,6]。为了克服软硬件扩充的问题，并改善编码时间，可将分布式转码计算应用在云服务系统上。云服务系统可提供可靠且更安全的网络资料储存，在软硬件设备更新与扩充都由云服务支持，使用者只需租用云服务器即可使用软硬件设备；在成本方面，相较于自行架设服务器，租用云服务系统器成本较低。研究基于云服务使用Hadoop分布式文件系统(HDFS)储存视频区块，并利用MapReduce框架与FFmpeg视频编码软件进行分布式转码，可实现云服务器视频串流转码系统，以提高视频观看的流畅性。

2、相关研究

2.1 云计算技术

云计算架构主要可分为以下三层：基础设施服务(Infrastructure as a Service，IaaS)，像是 Amazon 隶属的Amazon EC2与S3；平台服务 (Platform as a Service，PaaS)，如 Amazon Web Service 和 Google APP Engine；软件服务(Software as a Service，SaaS)，例如Microsoft的网络更新服务与Google Maps等[7]。

基于云计算的Hadoop基础设施服务构架，主要分为HDFS与MapReduce两部分。HDFS采主从式(Master/Slave)架构，由一个名称节点(name节点)与多个数据节点(data节点)这两种角色组成。一般部署情况下，Master上只运行一个名称节点(name节点)，负责处理文件系统的管理及储存，并记录文件的各个数据区块放置在具体的数据节点(data节点)上。而在每一个Slave上皆有一个数据节点(data节点)，负责处理用户存取数据区块上的请求，并定时回复数据区块的状态给名称节点(name节点)。当有任何一个数据节点(data节点)损坏时，名称节点(name节点)作重做操作[8]。Hadoop MapReduce主要架构是由Map与Reduce两个函数所组成，Map函数的输入为一组key/value序对，输出则为多组inter mediate key/value序对组。Reduce函数则将相同inter mediate key的value做合并动作，最后产生输出结果key/value序对，MapReduce流程如图一所示。

图1 MapReduce流程图

2.2 视频转码模式

目前视频转码的模式可以分成三大类，分别为：(1)单机模式：使用单一机器或服务器来进行视频转码的工作。这种模式的优点就是操作与维护都较简单，但缺点就是扩展性差，且转码速度将受限于单一机器的效能。此外，一旦涌入大量的转码需求时，系统将无法及时地处理这些工作。(2)分布式计算模式：同时使用多台机器（包括服务器）进行视频转码的工作。在进行视频转码工作前，系统会将输入的视频文件分割成较小的视频片段，之后将每个片段传送到不同的机器上进行转码，在完成转码后，再将每个转码后的视频片段传送到特定机器上进行合并。这种模式的优点是转码时间短，且可以应付大量的转码工作需求；但缺点就是实作上较单机模式复杂，且须考虑单一机器当机以及转码程序在任一机器上执行错误时的处理方式。(3)云计算模式：使用现有云服务提供商，如Amazon的Elastic Compute Cloud(EC2)，来执行视频转码的工作。其中，EC2提供的一个实例就可以负责处理一个视频转码的任务，这种模式的优点就是无需管理系统的硬件，成本控制也更灵活[9,10]。

3、非实时性视频转码系统

3.1 视频转码需求分析

视频转码可以根据输入数据的特性分成两大类，其一是针对已存在的视频数据进行转码的工作；另一类则是针对实时性的视频数据进行转码的工作。针对第一种类型的数据来说，系统设计的目标就是希望视频转码的时间越低越好。然而，针对第二种类型的文件来说，系统设计的目标就不是尽可能地降低视频转码的时间，而是在不高于一指定的时间下，让系统可以同时处理越多的视频转码工作越好。例如，假设实时性视频帧率是每秒30帧，则转码系统就只须在33毫秒处理完一个帧的画面即可达到即时性的要求。

为了达到上述的目标，可以通过将视频转码这项工作平行化来降低转码的时间或增加系统负载量。平行化指的是将视频转码这项工作分割成若干件较小的工作，且这些工作彼此间不存在任何的相依性，也就是任一工作无需等待其他工作执行完毕后才能开始执行。因此，若这些分割后工作不存在任何相依性时，就可以将这些工作同时分派至分布式计算平台上不同的节点来处理，以达到上述的目标。

对于已存在的视频数据来说，平行化的方式就是将输入的视频数据分割成数个较小的视频块，并把每个分割好的视频块传送到不同的节点上进行转码。另一方面，对于实时性的数据来说，平行化的方式有两种，分别为：(1)基于帧率来平行化：这类作法就是将输入的视频文件复制成N份后(N取决于输出的帧率），将每一份交由分布式计算平台上的一个节点来处理。(2)基于图像群组(Group of pictures，GOP)与帧率来平行化：这类的作法就是先将输入视频文件以GOP为单位切成较小的视频块，接着根据输出的帧率数复制数份视频块，并把每个复制后的视频块传送到不同的节点上进行转码[11]。

3.2 非实时性视频转码系统设计

非实时性视频转码系统的输入是需要转码的视频文件和使用者的配置文件，输出则是转换后的视频文件。在目前的系统中，输出的文件有两种不同的形式，一种是单一数据，另一种是分割后的数据。其中，产生第二种形式的目的是为了便于跟HLS或DASH等标准整合。第二种形式的文件就可以直接输出至特定的HTTP服务器来发布。整个非实时性视频转码系统主要包含有视频封装格式转换器、视频数据分割器与视频编解码器，视频封装格式转换器的功能就是将输入的视频文件转换成视频文件分割器可以处理的文件格式。为了减少视频文件分割器的操作复杂度，目前视频数据分割器只接受特定的视频封装格式。因此，在对视频文件进行分割前，系统就得对输入的视频文件进行格式上的转换。通常，格式转换的速度非常的快，基本上是不会增加太多的转码时间[12]。

根据实验结果，在CPU4核的配置上，视频封装格式转换器的处理速度可以达到约每秒一千多帧(对1080P的视频）。在格式转换后，第二步就是视频分割，将格式转换后的视频分割成较小的视频块，对于压缩后的影片来说，一个GOP就是一个最小的处理单位。在视频分割时，若影片的某一段GOP边界恰好不在整数秒时，影片分割的结果将可能大于或小于使用者设定的秒数，例如，当影片分割的单位被设为10秒时，视频文件分割器分割后的结果可能是8.x秒，也有可能是10多秒，这主要取决于GOP边界的位置。影片分割的下一步就是对每个视频块进行转码，在对每个视频块进行转码前，先把每个视频块上传到Hadoop平台上的文件系统，也就是HDFS，之后再调用FFmpeg转码程序来进行转码。在Hadoop平台上所使用的编程模型是MapReduce。在系统中，Map函数是转码程序，每个Map函数的输入是一个视频块，各个云计算节点接收视频块并进行转码，转码完成后，通过Reduce函数完成视频的合并，由于在本系统中因为配置文件有记录了每个视频编号信息，Reduce函数只执行将转码的结果排序并转发到流媒体服务器，流媒体服务器依据配置信息推送视频流到用户设备上，从而实现非实时性视频转码，如图2。

图2 基于hadoop系统流媒体转码结构设计

4、实验方法与结果

4.1 实验方法

实验为了测试非实时视频转码系统的执行效率，通过计时获取视频转码的时间。测试方案如下：(1)在相同节点数目下，不同视频输出格式所需视频转码时间。(2)在不同节点数目下，不同视频输出格式所需视频转码时间。(3)在相同节点数目下，不同的视频块大小对于视频转码时间的影响。

实验采用Hadoop0.20.203版作为系统的软件平台。硬件的部分，每台节点配置4核CPU，内存8GB。每台节点间千兆网络连接。在本实验中，输入是一段长度为10秒的影片，其中影片是采用H.264的影像压缩技术，影片的分辨率为1920x1080(1080P)，帧率为 30fps，码率为 3500kbps；声音的部分则是采用AAC的压缩技术，声音的采样频率为44kHz，码率为125Kbps。输出的部分主要差异是在影像的分辨率与码率上的不同。表1为本实验输入与输出的视频文件格式列表。

表1 视频输入输出格式

4.2 实验结果

通过测试在相同节点数目下，不同视频输出格式所需视频转码时间，如图3是在相同节点数目下（在这个实验中，节点数目是3台），不同帧率与分辨率所需的转码时间，T1、T2、T3代表的是三次实验的结果，Avg则是这三次实验的平均值。从图3的数据中，可以看出：第一，转码时间的长短主要取决于分辨率而非帧率，这点可以从比对200K与400K以及600K与1200K来看出；第二，对于五种输出格式，三次实验所得到的结果会有所差异。造成这样差异的主要原因是在于转码程序执行错误的比例，以及在不同时间可能存在的不同系统开销。

图3 不同分辨率转码时间比较

根据经验，在通过Hadoop来执行转码程序时，通常会有约1～2%左右的程序发生错误。此时，Hadoop就会将这些发生错误的程序移除后，再到其他节点上从新执行。由此一来，这将会增加整个转码时间。因此，若转码程序执行错误的比例越低时，则整个转码时间就会越短。然而，根试验的经验，转码程序执行错误的情况还具有随机性。

图4 不同节点数量转码时间比较

通过测试得到了在不同节点数目下，不同视频输出格式所需视频转码时间，如图4中1节点表示在单一节点且无使用Hadoop的情况下所需的转码时间，2节点与3节点则是在使用2与3台节点且使用Hadoop的情况下所需的转码时间。从图4中不难发现，当节点数目增加时，视频转码时间就会随着下降，相较于单一主机的情况，在一个拥有3个节点的Hadoop系统上执行视频转码，平均节省38.64%转码时间，如表2所列。

表2 不同节点数量转码时间及效率提高情况比较（单位：S）

图5 不同数据块长度转码数据比较

通过测试在相同节点数目下，不同的视频块大小对于视频转码时间的影响，如图5是在相同节点数目下，就趋势上来看，视频转码的时间是反比于视频块的大小，当视频块大小增加时，视频转码的时间通常会跟着下降，造成这现象的主因是网络传输与启动视频转码程序的时间成本。此外，因为目前架构的系统只有3台节点，而每个节点上只有4颗CPU核心，也就是最多同时只能执行12个转码程序。因此，当文件切割后的视频块个数大于12时，有些文件就无法平行地被处理。当系统的节点数足够多时，视频块越小，则可以平行处理的视频块个数就越多，此时整体的转码时间就可以缩短。因此，视频块的大小应该是取决于系统里的节点个数。

5、结论与讨论

本文主要针对HLS与DASH等串流标准提出了一套云计算视频转码系统，根据实验的结果显示：（1）在转码时间上，本实验设计的系统有着相当不错表现，较于单一主机的情况，在一个拥有3个节点的Hadoop系统上执行视频转码，平均节省38.64%转码时间；(2)不同的视频块大小对于视频转码时间的影响，就趋势上来看，视频转码的时间是反比于视频块的大小，当视频块大小增加时，视频转码的时间通常会跟着下降，造成这现象的主因是网络传输与启动视频转码程序的时间成本。

根据实验的观察，如果使用Hadoop平台作为实时性视频转码系统，由于处理延迟的影响，很难满足实时性视频的需求，尤其是HLS与DASH等串流标准本身就存在一定的处理延迟。如果针对非实时性与实时性的视频转码需求分别各设计一套专用的视频转码系统，在管理上又将造成使用效率不高。因此，最好的方式就是针对HLS与DASH等串流标准开发一套可以同时支持非实时性与实时性的视频转码服务的通用视频转码系统。此外，通过通用图形处理器（GPGPU)来加速视频转码程序在每台机器上的执行效率也是一个值得探究的方向。因此，在后续的研究，将持续朝这两大方向来发展。