随着视频和音频编码技术的最新进展，MPEG-2 格式现在被用于数字视频广播 (DVB) 传输和 DVD 存储，并被广泛的硬件设备支持。MPEG-2 电影文件的大小通常在 3–6GB 之间，这种大小适合 DVD，但不适合 CD-R。同样，高质量的 MPEG-2 视频适合 DVB-S 或 DVB-T 网络，但不适合 IEEE 802.11b 或家庭 HomePlug 传输。为了解决这些问题，改进的编码技术得到了发展，MPEG-4 也因此被标准化。MPEG-4 格式可以将电影大小缩小到 700MB 左右，并保持相当好的质量。

由于许多多媒体内容以 DVD MPEG-2 文件的形式提供，因此有必要将它们转码以获得 MPEG-4 等效文件。在本文中，我们提出了一个基于 Condor 元计算平台的 Linux 框架，以实现高吞吐量的 DVD 转码。尽管存在一些用于固定机器集的 LAN 并行转码工具，但我们尚不清楚是否有任何用于并行转码的元计算系统。元计算指的是隐藏物理资源，而是提供简化的虚拟机视图的架构。例如，我们使用的 Condor 工具“窃取”可用机器的周期，当用户或高优先级进程未使用它们时。

由于廉价 DVD 播放器的普及，以及 DVD 作为存储介质相比 VHS 录像带的稳健性等等，DVD 电影市场蓬勃发展。然而，DVD 刻录介质市场尚处于起步阶段。由于 CD-R 技术已经出现一段时间，并且 CD-R 光盘比 DVD 光盘便宜得多，家庭用户已经找到了将 DVD 电影存储在 CD 上并获得类似主观质量的方法。这种存储方式之所以成为可能，要归功于最新一代的视频和音频编解码器。它们基于 MPEG-4 标准，并提供高压缩比。然而，对于许多台式 PC 而言，将 DVD 转码以使其内容适合 CD 仍然在计算上是昂贵的。

并行化是加速 DVD 转码的一种有希望的解决方案。最明显的方法是手动并行化，即将输入文件手动分成块，在不同的机器上转码这些块，并将结果连接成单个文件。对于希望跟踪整个过程的用户来说，手动并行化可能是足够的。然而，使用元计算来实现高吞吐量、提交即忘的 DVD 转码可能更有优势。

并行化一个进程需要将其分解为基本任务，调度这些任务并收集其结果。因此，资源管理工具是必要的。Condor 和 Globus 等工具提供了基本的元计算和并行化软件。在我们的例子中，我们选择了 Condor，因为它没有增加额外的复杂性，易于安装和配置，并且在 Linux 上运行良好。最后，Condor 不需要专用集群。

Condor 是一个专门用于计算密集型作业的工作负载管理系统。与其他功能齐全的批处理系统一样，Condor 提供作业排队机制、调度策略、优先级方案、资源监控和资源管理。用户将他们的串行或并行作业提交给 Condor，Condor 将它们放入队列中，根据策略选择何时何地运行作业，监控它们的进度，并最终通知用户作业的完成情况。

虽然 Condor 提供的功能与任何传统的批处理排队系统类似，但 Condor 的架构使其能够在传统调度系统失败的领域取得成功。独特的机制使 Condor 能够利用原本空闲的台式计算机中浪费的 CPU 能力。例如，Condor 可以配置为仅在键盘和鼠标空闲时使用台式机器。如果 Condor 检测到机器不再可用（例如，检测到按键），它能够产生透明的检查点并将作业迁移到另一台原本空闲的机器。Condor 还能够透明地将所有作业的 I/O 请求重定向回提交机器。因此，Condor 可以用于无缝地组合社区中的所有计算能力。

商业元计算转码系统明显缺乏可能存在，因为元计算主要与 UNIX 科学界联系在一起。另一方面，娱乐软件设计师仍然将最高优先级给予对元计算不友好的 Microsoft Windows 世界。例如，最新版本的 DivX 编解码器——在撰写本文时为 v.5.0.5——是 Linux 转码开发的关键工具，但它在 Pentium 4 Linux 机器上无法正常工作。之前的版本是 v.5.0.1alpha，这是一个前一年发布的、不稳定的版本。这个例子提供了一个想法，即在尝试将娱乐应用程序移植到对元计算友好的 Linux 平台时可能遇到的问题。

尽管有各种各样的转码应用程序可用，我们概述了我们发现最有趣的三个

DVD 基于 ISO/IEC 11172 (MPEG-1) 和 ISO/IEC 13818 (MPEG-2) 标准的子集。DVD 电影分为三个部分：视频对象 (VOB) 文件，每个文件最大大小为 1GB，多路复用视频和音频源。

存在三种类型的 MPEG-2 帧：I（帧内）、P（预测）和 B（双向预测）。I 帧表示完整图像，而 P 帧和 B 帧编码先前和/或未来帧之间的差异。原则上，视频流剪切点必须位于 I 帧的开头，这似乎是显而易见的。这几乎是正确的，但并不完全正确。必须考虑一些参数，例如帧速率和大小。此信息是序列标头的一部分。因此，选择作为剪切点的包必须具有序列标头。幸运的是，每个 I 帧之前都有一个序列标头。

另一个重要的问题是由于 P 帧和 B 帧的存在而导致的帧重新排序。在 I 帧之后，可能会跟随 B 帧，这些 B 帧依赖于在 I 帧之前出现的 P 帧。如果在该 I 帧的开始处对视频流进行分区，则不可能保持视频转码的一致性。解决方案是将后期 B 帧分配给前一个块。因此，视频预处理增加了一些额外的复杂性。

显然，将视频碎片化到最大限度是没有意义的，因为块的大小会太小。通常，两个连续的 I 帧之间大约存在 300KB，尽管此长度取决于多个参数，例如比特率或图像大小。

我们为我们的项目考虑了两种基本的负载均衡策略。第一种称为小块（Small-Chunks），DVD 电影被分成固定大小的小块。Condor 将一个块分配给每台可用的计算机。当一台计算机完成一个块的转码后，它会请求另一个块。这个过程一直重复，直到服务器上没有剩余的块。在另一种策略中，称为主-从（Master-Worker），负载均衡取决于份额，份额由主处理器决定。显然，其他参与的计算机是工作者。这种策略通常用于高吞吐量计算。对于本项目，每个特定计算机的块大小是根据训练阶段分配的，如下一节所述。

应该理解的是，我们有意不考虑机器故障或用户干扰的可能性。如果这些事件发生，本项目中简单的主-从实现的性能将会下降。然而，我们的两种方法具有说明意义，因为它们是极端情况，一方面是纯粹的主-从，另一方面是小块的高粒度。容错/抗干扰的主-从策略介于两者之间。我们的目的是评估我们的应用程序在这两个极端情况下的行为是否相似，从处理时间和转码文件大小的角度来看。正如本文中描述的结果所表明的那样，小块可能更具优势，因为它简单（不需要训练阶段），并且因为它自然地适应 Condor 对机器不可用性的管理。

为了向主-从协调器提供信息，有必要预先评估所有计算机。评估在训练阶段执行，该阶段估计每台计算机的转码速率，单位为帧/秒。我们原型的训练阶段包括在目标计算机集中转码各种小型视频序列，并估计每台计算机提供的平均帧/秒数。然后，此结果用于设置数据块的大小，数据块的大小与每台计算机的估计性能成正比。理想情况下，这种方法可以最大限度地缩短 DVD 转码时间，因为所有计算机都应该同时完成其作业。

我们的测试平台模拟了一个典型的异构计算环境，包括在其使用寿命末期的机器。它由五台计算机组成（见表 1），根据其处理能力分为三组。第一组有两台机器（gigabyte 和 kilobyte），第二组有一台计算机（nazgul），第三组有两台性能最差的机器（titan 和 brio）。

此外，所有计算机都连接到 100Mbps 以太网网络，并且所有计算机中使用的操作系统都是 Red Hat Linux 8.0。所有计算机共享相同的用户空间（由 NIS 服务器定义）和相同的文件系统（gigabyte 中的 NFS 服务器）。最后，我们安装了 Condor v. 6.4.7，gigabyte 是中央管理器。Condor 配置为将所有作业保留在其各自的处理器中，而不管用户活动如何。因此，本节中的计时是最佳情况结果，如上所述。

DVD 到 DivX 的并行转码器是使用以下库实现的

视频分区阶段完成后，视频数据块被提交给 Condor 转码作业。这些作业在 Condor Vanilla universe 中处理，因为它们动态加载 DivX 库。

为了转码数据块，每个转码器直接从源 VOB 读取数据。输出数据写入到同一个文件夹。读/写操作是在逐帧的基础上执行的：转码器读取一帧，对其进行转码，然后将结果写回。这种策略比将整个块传递给工作者、在工作者本地文件系统中转码它们以及将整个转码结果从工作者发送到服务器计算机进行连接的效果更好。所有计算机都使用 NFS 共享输入 VOB 文件和输出文件夹。并行转码阶段完成后，转码结果是一组独立的文件，这些文件在主计算机上连接以生成 DivX 电影。表 2 显示了结果。

我们使用了两种负载均衡策略：小块和主-从。测试电影是 All about My Mother，时长 1 小时 37 分钟，原始大小为 2.94GB。表 2 comp 列中的元组是测试平台计算机名称的首字母，例如，g 指的是 gigabyte，t 指的是 titan。符号 - 表示该计算机未在该特定测试中使用。小块中的块大小设置为 60MB。视频预处理时间未包括在内，因为它在所有情况下都可以忽略不计。

表 2. 计算结果（t = 时间，Fps = 帧/秒）

可以从表 2 中得出几个结论。首先，根据 Fps 列，主-从的负载均衡比小块的负载均衡更好。差异很小，但随着使用机器数量的增加，差异趋于增大。总的来说，并行化提高了转码性能，这在添加第二台强大的机器时很明显（参见 [g----] 与 [gk---]）。连续添加低端机器的影响很小（参见 [gk---] 与 [gk--b] 以及 [gk--b] 与 [gkntb]）。然而，所有低端机器的综合影响是显着的，特别是当从单台可用强大机器的情况出发时（参见 [g----] 与 [g-ntb]）。

为了进一步评估原型的行为，我们将其与两种流行的转码工具 Mencoder 和 FlaskMpeg 进行了比较。表 3 显示了这些结果。我们的原型单处理器版本的速度介于 FlaskMpeg 和 Mencoder 之间。关于输出大小，在最坏的情况下（小块），我们的原型交付的 DivX 电影仅比 FlaskMpeg 的输出大 2.6%。实际上，小块 (24.67%) 和 FlaskMpeg (24.05%) 实现的全局压缩率相似，如果考虑处理速度的提高，这种差异并不重要。重要的是要注意，FlaskMpeg 使用 DivX 编解码器 v. 5.0.5 Pro，在撰写本文时，该编解码器在 Linux 上不可用。因此，当 Linux 版本可用时，压缩性能可能会更接近。

表 3. 比较结果，最先进的转码应用程序

最后，图 1 和图 2 显示了系统原型中机器的吞吐量，小块和主-从都用于负载均衡。计算机并没有完全同时完成它们的任务。但这应该是预期的，因为小块负载均衡只是近似的。此外，主-从作业大小是根据训练阶段的结果分配的，训练阶段具有代表性但不完全准确。

图 1. 单个计算机吞吐量，小块

图 2. 单个计算机吞吐量，主-从

在本文中，我们介绍了一个用于 Linux 的 Condor 高吞吐量 DVD 转码系统。我们的结果表明，面向元计算的并行转码具有实际意义，并且与现有的单处理器 Windows 工具相比，它可以实现显着的改进。

考虑到我们的案例研究的统计数据，纯粹的主-从产生的结果比小块更好，但差异很小，在实践中似乎无关紧要。