面向在线制作的集群转码系统设计*

孙思慧，孙 军，王兴东

（上海交通大学 电子工程系 图像通信与信息处理研究所，上海 200240；上海市数字媒体处理与传输重点实验室，上海 200240）

1 引言

在基于广域网环境的在线节目制作系统中，用户需要在制作过程中大量使用各种多媒体素材，它们往往具有不同的分辨力、制式、音视频压缩格式甚至是压缩参数，这会对节目制作系统的兼容性提出很高的要求，因此如何能够在一个统一的制作平台上自由使用这些素材是在线制作环境需要解决的重要问题。在专业节目制作领域，节目素材的导入是后期制作中的重要一环，通常如苹果平台下的Final Cut Pro这类的非线性编辑软件，会将需要导入的素材转码为统一的格式，从而满足后续编辑工作的需要。但是这种方式需要节目制作终端具有强大的运算能力，才能尽量降低素材导入所占用的时间。而对于普通的视频制作爱好者而言，更需要一台性能强大的计算机作为其素材导入、图像处理、特效渲染等一系列制作环节的重要工具。为了能搭建起一个基于广域网的在线节目制作系统，使更多普通用户能够参与到节目制作活动中，需要在网络前端建立一组为转码、特效合成等大运算量的工作提供保障的计算集群，这样的集群能针对运算任务进行适当的分解，利用多运算节点并发的优势，提高任务执行速度，从而满足多用户同时工作的需要。

2 集群转码系统设计

本文所要实现的集群转码系统将最常见的MPEG-2视频压缩及TS封装格式转码为目前最先进的H.264/AVC编码格式[1]。

2.1 集群转码系统的构成

整个集群转码系统由一台核心服务器和若干台计算节点组成，服务器和计算节点都配有千兆以太网卡，相互之间采用局域网交换机互联。转码任务分析和分解、多媒体素材的分割与分发以及最终的分段回收与合并等功能都由核心服务器承担，此服务器同时管理所有的计算节点，并在执行转码任务过程中对所有节点以负载均衡的方式进行调度。计算节点负责实际的转码运算，在预先配置好一组转码程序的情况下，由核心服务器的调度系统来负责启动节点上的转码运算。系统整体架构如图1所示。

图1 集群转码系统整体架构

2.2 Condor调度系统

Condor[2]是 Wisconsin-Madison大学 Condor研究计划中的一款开源软件系统，它能够提供高吞吐量的计算环境，有效利用那些通过网络互连的工作站的计算能力。同其他分布系统类似，Condor提供任务排队、调度策略、排序策略和资源管理等功能。本系统利用Condor对计算能力的调度控制来实现集群转码功能。

Condor系统利用一种称为ClassAd的机制来提供一个极端灵活的架构，从而实现任务与资源之间的匹配。在用户提交任务时可以标明需要满足的要求和一些参数，同样，在配置Condor系统中的设备资源时也可以指明该设备对希望执行的任务的要求和参数。通过这两组要求和参数，系统会为任务寻找网络中的可用计算资源，然后在那里执行任务。

另外，Condor系统中提供了一种名为有向非循环图（Directed Acyclic Graph，DAG）的任务提交机制。利用 DAG可以表示一组有依赖关系的任务，用DAG描述文件可以将一个或一组任务设置为另外一个或一组任务的子任务。

如图2所示，任务A即为B和C的父任务，反之，B和C为A的子任务。同样，B和C均为D的父任务，而D就是B和C共同的子任务。Condor会根据该描述文件，自动在所有的父任务执行完毕的情况下再开始分配执行子任务。这样的机制，为项目中子视频转码后再拼接的形式提供了有效的解决方案。

图2 DAG机制示例

3 集群转码系统的实现

集群转码系统按照上一章所述的架构完成硬件环境搭建，而软件部分的实现则包括任务生成、转码程序、结果生成等几个部分。

3.1 任务生成

在本文所设计的集群转码系统中，任务生成部分包括了多项功能，有素材格式分析及封装解包、视频流分割、子任务提交等步骤。

素材格式分析：根据用户运行程序时提供的参数对素材内容进行一定的分析，获得素材格式的基本信息、包括封装格式、视音频的编码格式、视频参数等，对于转码程序不能适应的参数向用户返回不能支持的错误信息。

封装解包：将封装为TS流格式的原始素材进行解包，分别生成相应的音频和视频基本流。

视频流分割：视频数据本身的特性决定了它的分割点并不能处在码流中的任意位置，作为解码器处理的基本单元，必须保证同一视频帧的数据不能产生断点，否则将无法正常解码。另外，由于MPEG-2视频压缩编码采用了帧间预测技术，这就决定了视频码流中，不同的帧之间存在相互参考，必须将前后相关的若干帧图像数据同时送入一个解码器，才能保证解码的正确性，最典型的问题在于Open GoP和Close GoP之间的区别[3]，见图3。

图3 典型的GoP帧结构图

下面介绍一种有效的视频切割的解决方法[4]。由于MPEG-2标准规定，在GoP头信息的一个字段中指明了该GoP是Open还是Close，这就给图像分割带来了方便，可以根据切割点处GoP类型的不同设置不同的切割策略。首先，如果切割点后紧跟的第一个GoP是Close的话，则不用考虑其他策略，即在分割点将视频分为前后两段即可，不会使某一段视频产生无法解码的情况。若切割点之后紧跟的第一个GoP是Open的话，则需要使后一段视频前多加一个GoP。以图3为例，假设现在切割点正好取在 GoP（k-1）与 GoP（k）之间，当发现GoP（k）为Open GoP时，则第2段子视频的起始点应取在GoP（k-1）的起始位置，而第1段子视频的结束点仍然取在2个GoP的中间分界点上（如图4所示）。

分割之后，第2段视频中的GoP（k）可以保证每一帧都正常解码，然后在视频拼接时采取对应的方法，即可以实现连贯的视频无缝拼接。

图4 视频切割示意图

另外，视频切割中还有一点需要注意的是，对于解码器而言，每次对一段视频进行解码时，都是先寻找该段视频中的序列头信息，即sequence head字段。然而，通常一整段视频可能仅在开始处包含一个序列头，也可能在每个GoP前都附带有相同的序列头，这要视码流而定。这时，若碰到前一种情况，则需要在切割之后的每一段子视频前都添加上序列头，以保证解码器的正常运行。而若碰到后一种情况，则需要在切割时将每个序列头都视为GoP结构的一部分进行整体切割。

图5是本文所设计的集群转码系统中针对视频分割的代码流程框图。这里所实现的视频分割均是基于MPEG-2的TS流所设计的。

图5 视频切割代码流程图

3.2 结果生成

所有的运算节点在完成被分配的转码任务之后，会将转码的结果传回给核心服务器，因此需要将这些零散的视频片段重新组合成完成的视频，同时还要能够与音频文件一起通过格式封装等手段生成一个新的多媒体素材。由于视频分割与转码部分已经充分考虑到了无缝拼接的概念，因此两段子视频之间的图像帧是完全首尾相连的。如此，在拼接程序中就无须考虑帧的次序调整问题。需要指出的是，由于各段子视频是在不同的设备上分别进行转码运算的，因此在生成的码流中，各自都可以成为一段完整的视频，包括许多头部信息等稍显重复的内容。以实验中所使用的X264编码工具库为例，在生成码流的开始部分会加入一些特有信息，包括SPS以及编码器参数等。在合并码流的程序中，会减去除第一段外的其他子视频中的这些附加信息，这样可以减少最终码流的文件大小，但又不会影响码流的正常解码播放。

3.3 转码程序

在本课题中，视频转码程序的目的就是将原本符合MPEG-2标准的压缩码流转码为符合H.264标准的码流。由于这两种标准在压缩算法上存在较大的差异[5]，因此在使用软件进行转码时，最为合适的方案就是先将MPEG-2码流解码为原始YUV图像数据，再将其编码为H.264格式，这也就是所谓的“全解全编”转码方法。项目要求在H.264的编码中具有许多可调参数，这些参数的设置是由转码用户所决定的，因此利用这种“全解全编”的方法可以方便地调整编码器的参数。图6是整个转码程序的算法流程。

图6 视频转码程序流程

MPEG-2解码和H.264编码均采用了调用函数库的形式，其中MPEG-2解码开始采用的是ffmpeg；H.264编码则采用的是X264开源工具库。后处理部分主要是指对H.264码流的帧顺序的调整，以及调用函数库时所分配的数据结构的内存释放。

4 系统测试分析

笔者对本文所设计的集群转码系统进行测试。测试环境如表1所示。图7是Condor系统对于各个设备的资源列表。其中，Condor将双CPU计算机视为2台设备。

图7 condor_status命令显示设备池信息

表1 集群转码设备配置信息

对于集群转码设备的平台环境，笔者考虑以Linux为基本的操作系统平台，主要是由于笔者在对Condor基于Windows和Linux两种操作系统平台进行了测试之后发现，Linux平台中Condor不会在DAG模式下占用过多起始运行时间，这样能够提高整体转码系统的效率。

对于同一计算机而言，在执行相同参数的视频转码任务时的运算效率基本上是一定的，即视频转码的时间与视频文件的原始大小成正比。因此在对视频分割的子视频文件大小进行设定时就有了依据，对于同一段视频，无论其如何分割，在所有执行终端的运算速度相当的前提下，纯粹的转码运算时间是一定的。那么尽量将视频文件分割为若干等量的小任务，并且根据各运算节点的运行情况灵活分配，这样能够最大限度地利用运算节点的能力。但同时又必须考虑到每次分配任务的系统开销，太多的子任务也必然增大系统中的调度消耗，因此取得这之间的平衡是分割的关键因素。从笔者的实验来看，选择运算节点数目整数倍的分段数量可以最大限度地同时利用多个运算节点共同完成转码任务，可以想象在相同性能的运算节点不出现意外死机等现象而能够保持系统正常运转时，这样的结论是合理的。

根据上述分割片段大小的分析可以发现，有一条重要的切割依据是集群设备的数量。

从图8中可以明显地看到转码时间随终端个数而减少的趋势。这样的减少是有一定前提的，即转码的目标数据大小相同，且分割的子视频个数也是相同的。根据以上数据，可以得到的结论是：转码时间在转码源数据一定时随集群终端个数的增加而减少。图8中的黑色虚线是根据现有数据所拟和的二次曲线，并作了适当的延展，可以明显地看到曲线逐渐随终端数目的增大而趋于饱和。

图8 计算节点数目与转码效率的关系

图8中的数据表明，当集群数量达到一定规模之后，完全可以超过单机软件转码的效率。之所以在集群数量较少的情况下多机转码反而比单机的时间更长，是因为集群调度系统在任务调度上的时间消耗延长了任务执行时间。这些时间损耗包括：DAG机制的初始化时间和数据的网络传输时间。

当然，转码时间肯定不会随终端个数的增加而不断减小，在终端数目增加到一定程度时，必然对本地网络传输产生相当的压力，并由此产生了瓶颈，导致转码时间趋于饱和，甚至反向增加。

5 结论

本文的集群转码系统对于广域网在线制作这样的由服务端承担主要运算工作的应用来讲，不但能够提高系统对单个用户的响应速度，还能够帮助提高设备的利用率，减少设备投入，因此本文所设计的集群转码系统将对在线编辑应用具有很大的价值。

[1]WIEGAND T，SULLIVAN G J，BJONTEGAARD G，et al.Overview of the H.264/AVC video coding standard[J].IEEE Trans.Circuits and Systems for Video Technology， 2003， 13（17）:560-576.

[2]Condor Team.University of wisconsin-madison,condor version 6.8.3 manual[EB/OL].[2009-05-20].http://www.cl.cam.ac.uk/manuals/condor-V6_8_3-Manual/.

[3]SANBE Y，WATANABE S，YU Dong,et al.High-speed distributed video transcoding for multiple rates and formats[EB/OL].[2009-05-20].http://www.anarg.jp/achievements/web2005/papers/sambe05IEICE-transcoding.pdf.

[4]赵坚勇.电视原理与接收技术[M].北京：国防工业出版社，2007.

[5]孙景琪，孙京.数字视频技术及应用[M].北京：北京工业大学出版社，2006.