2025 年在 Graviton 上进行视频编码

2022 年，我们发布了一篇文章，描述了在 Amazon Graviton 处理器上运行视频编码工作负载的优势。从那时起，亚马逊云科技推出了基于 Graviton4 的 C8g 实例，其性能比 Graviton3 高出 30％。在视频编码工作负载上，Graviton4 的性能比 Graviton3 好 12-15％，具体取决于编码器，如下图所示。同时，亚马逊云科技和其他合作伙伴为 x265 和 SVT-AV1 等开源项目做出了贡献，提高了它们的性能。自 3.6 版本发布以来，x265 库的性能提高了 16-34%。SVT-AV1 也有所改进；在 2022 年，它缺少重要的优化，在 Graviton 上的运行速度比在其他亚马逊云科技弹性计算云（Amazon EC2）实例类型上的运行速度要慢很多倍。

图 1：将 C8g（Graviton4）与 C7g（Graviton3）进行比较时，四种不同编码工作负载的每秒帧数提高了百分比。

软件视频编码器比硬件加速编码器更灵活，因此它们可以成为许多用例的优秀选择，尤其是离线转码或使用自定义过滤器时。对于需要极低延迟的工作负载，例如实时视频转码，硬件加速编码器可能是正确的选择。但是，如果软件编码解决方案适合您的工作负载，Graviton 实例可以为许多工作负载提供优秀的性价比，为其他工作负载提供有竞争力的性价比。对于使用竞价型实例的客户，启用 Graviton 实例可以拓宽您的实例类型的选择范围，因此您始终可以在最便宜的可用实例上运行。

对于许多视频编码工作负载，Graviton 仍然是最具成本效益的处理器。使用与 2022 年博客文章相同的基准测试并更新到该软件的最新版本，Graviton4 在测试的实例类型中实现了优秀的性价比。Graviton 驱动的实例在测试实例的前五名中名列前三，这表明即使是 2019 年发布的 Graviton2 对于许多用例来说仍然非常有吸引力。

图 2：FFmpeg 工作负载上每种实例类型与 C5 相比的性价比，该工作负载使用 x264 和"非常慢"的预设将单个 4k 输入编码为五种不同大小的不同输出。

x265 的性能改进

对用于编码 H.265 视频的广泛使用的开源库 x265 的贡献提高了一系列编码预设的性能。视频编码器中一些最耗时的函数是许多算法所共有的，包括绝对差和值 (SAD)、卷积和离散余弦变换 (DCT)。提高这些功能的性能对整个编码器的性能产生了巨大影响。这些功能的改进导致了多代 Graviton 的性能改进，但一些最好的改进出现在支持最新指令（例如 SVE2）的 Graviton4 上。这些图表显示了 x265 版本 4.1 与 3.6 版本分支相比的改进百分比。与 2022 年推出的发布版本 3.5 相比，改进更为显著，Graviton 实例的性能提高了 2.3-2.5 倍。

最大限度地提高 Graviton 性能的技巧

为了在 Graviton 上获得优秀的编码性能，您可以遵循一些提示。你能做的最重要的事情是确保尽可能使用最新的源代码构建编码器管道。最近有许多贡献提高了 Graviton 的性能，尤其是在 x265 和 SVT-AV1 中。如果您使用这两种编码器中的任何一个，请在从主分支的尖端进行构建时测试性能。也请经常回来查看，因为在撰写本文时，这些项目的工作仍在进行中。

可以提高 Graviton 性能的另一件事是使用适用于您的操作系统的最新编译器进行编译，或者更好的是，安装更新的编译器，例如 Clang-17 或更高版本。（最简单的方法通常是从发行版的包管理器进行安装。）这可以提高 x265 等较新库的性能，这些库中有许多编码器内核是使用编译器内核实现的，而不是直接在汇编中实现的。

对于某些库，尤其是 x265，使用最新版本的 Clang 而不是 GCC 进行编译可以显著提高性能；在使用 C8g 进行测试时，使用 Clang 在 Ubuntu Noble 24.04 上构建，使用 Clang-18 的打包版本，与 GCC-13 的打包版本相比，x265 在基准测试中的平均表现要好 11%。

图 4：与 Ubuntu Noble（24.04）上的 GCC-13 相比，使用 Clang-18 编译时 x265 的 C8g 的性能有所改善。

新的指令支持可实现更多优化

在本节中，我们将详细讨论 Graviton3 和 4 的新功能如何提高性能。所有 Graviton 处理器都支持 NEON 指令集，支持 128 位单指令多数据 (SIMD) 处理。使用这些指令，Graviton 在处理 8 位视频时，每条指令可以处理 16 个像素通道。这些类型的指令是在 CPU 上实现高性能视频编码的基础。Graviton3 增加了对另一组新指令，即可扩展向量扩展 (SVE) 的支持。Graviton4 在此基础上进一步发展，增加了对 SVE2 的支持。虽然 SVE 没有增加 Graviton 的总并行吞吐量，但它确实引入了一种新的、更简单的 SIMD 代码编写方式，这种方法通常使用更少的指令。它还添加了 NEON 中不可用的指令类型，可以对视频编码进行更多优化。

例如，在 x265 中，一组调用的函数 saoCuStatsE0 可以使用 Graviton4 上调用的 SVE2 指令，histseg 该指令可以计算第二个向量的每个字节匹配的字节数。这使该函数能够根据源数据中的值建立一个小型频率表。要使用 NEON 指令执行此操作，必须掩盖每个值，并使用单独的指令分别计算每个值。

该 saoCuStatsE0 函数执行的任务之一是计算正在处理的区块中 5 种不同边缘类型的总数。要使用 NEON 指令执行此操作，在使用一些简单的数学运算来计算边缘类型后，会针对这五种边缘类型分别使用比较指令构造一个掩码。然后，这 5 个掩码中的每一个都加上一个更宽的配对加指令 sadalp，该指令仅限于 Graviton3 和 Graviton4 上 SIMD 带宽的一半。这行得通，有助于将速度比 C 实现提高 2.7 倍。但是，随着 Graviton4 中 SVE2 的上线，我们可以用单条指令和标准 NEON 指令替换 5 条比较指令和 5 条成对相加 histseg 指令，而这 add 条指令没有扩大对的带宽限制。add 这有助于该函数的 SVE2 实现速度比 C 实现提高 3.2 倍。

这只是 Graviton3 和 Graviton4 上提供的新指令所带来的好处的一个例子。还有其他类似的案例，实施这些案例帮助 Graviton3 和 Graviton4 实现了比 Graviton2 更高的性能优势，而仅凭提高芯片性能就可能实现了这种优势。对于致力于在 Graviton 上实现优秀性能的工程师，我们的亚马逊云科技 Graviton 技术指南中提供了有关编写优化汇编和内在函数的信息。

HDR 和 10 位视频

上一篇文章指出，还有更多工作要做，尤其是当 HDR 内容使用超过 8 位的色深时。与 8 位相比，10 和 12 位色深需要两倍的 SIMD 计算，并且在大多数情况下，需要将优化的内核与 8 位版本分开实现。尽管如此复杂，但此后在加速 10 位编码方面已经完成了大量工作。大部分工作都集中在 x265 和 SVT-AV1 上，因为这些编解码器更常用于提供 HDR 内容。对于 x265，这些图表显示了三代 Graviton 的 FPS 分数有所提高，C8g、C7g 和 C6g 的平均分数分别提高了 12％、8％ 和 10％。

基准测试方法

在此处表示的每个基准测试中，有足够的编码实例并行运行，以便完全加载被测实例。该模型对工作负载进行优化，以实现最低的编码成本，而编码每个视频的总时间则不那么重要。除了 FFmpeg 缩放基准（与 2022 年博客文章中使用的基准测试相同）外，本博客文章的每个基准测试都采用 y4m 容器中的原始源视频文件，并直接使用编码器 x264、x265 或 SVT-AV1 对其进行编码。编码运行时使用了足够的并行实例，可以完全加载被测系统的所有内核。

结论

希望降低视频编码成本或提高性能的客户应考虑使用基于 Graviton3 和 Graviton4 的实例。基于 Graviton4 的 C8g 实例特别适合视频编码，在 x265 基准测试中，其性能比 Graviton3 高 12%，比 Graviton2 高 73%。为了从 Graviton 获得优秀性能，请使用最新的编码器来源，并考虑使用 Clang 而不是 GCC 进行构建。对这些开源项目的贡献仍在继续，因此请经常检查源包的更新。有关迁移到 Graviton 的更多信息，请参阅亚马逊云科技 Graviton 技术指南。

Jonathan Swinney

乔纳森·斯威尼是亚马逊云科技（安纳布尔纳实验室）的软件开发工程师，负责德克萨斯州奥斯汀的 Graviton 处理器的软件优化。他为提高 Graviton 性能的各种开源项目做出了贡献，包括 FFmpeg、OpenSSL、Golang 等。在开发 Graviton 之前，他帮助启动和维护了 EC2 F1 实例。