VP9 编解码性能对比 HEVC/H.264

原文： https://blogs.gnome.org/rbult...

发表于 2015 年9 月 28 日，由 rbultje

很久以前，我发布了关于 ffvp9，FFmpeg用于 VP9 视频编解码器的本机解码器，其性能明显优于 Google 的解码器（libvpx 的一部分）。我们还讨论了编码性能（主要是质量），并表明 VP9 的性能明显优于 H.264，尽管速度要慢得多。从那时起，房间里的大象问题一直是：HEVC 怎么样？当时我无法解决这个问题，因为博客文章主要是关于解码器的，而 FFmpeg 的 HEVC 解码器不成熟（从性能角度来看）。幸运的是，这个问题已经解决了！所以在这里，我将比较 VP9 与 HEVC/H.264 的编码（质量+速度）和解码（速度）性能。[我之前在 Webm 峰会和VDD15上介绍过这个 ，并且还提供了该演讲的Youtube 版本。]

视频编解码器最重要的问题是质量。从科学上讲，我们通常使用标准编解码器设置以各种目标比特率对一个或多个视频剪辑进行编码，然后测量每个输出剪辑的客观质量。推荐的视频质量客观指标是SSIM。通过在图中绘制这些比特率/质量值对，我们可以比较视频编解码器。现在，当我说“编解码器”时，我的真正意思是“编码器”。为了进行比较，我比较了 libvpx (VP9)、x264 (H.264) 和x265 (HEVC)，每个都使用 2-pass 编码到一组目标比特率 (x264/x265: –bitrate=250-16000 ; libvpx: –target-bitrate=250-16000 ) 与 SSIM 调整 ( –tune=ssim) 在最慢（即最高质量）设置（x264/5: –preset=veryslow ; libvpx: –cpu-used=0）下，所有形式的线程/平铺/切片/wpp 被禁用，关键帧间隔为 5 秒. 作为测试片段，我使用了钢铁之泪 （1920×800）的2分钟片段（别点了，链接已失效）。

这是一个典型的质量/比特率图表。请注意，两个轴都是对数轴。让我们首先将我们的两个下一代编解码器（libvpx/x265 作为 VP9/HEVC 的编码器）与 x264/H.264 进行比较：它们要好得多（绿色线在蓝色的左边，这意味着“相同质量的具有较小文件大小” ，或者您可以说它们在上面，这意味着“相同文件大小的质量更好”）。无论哪种方式，他们都更好。这是意料之中的。

好多少呢？因此，我们通常会尝试通过将实际红色点与蓝线的内插点（在相同的 SSIM 分数下）进行比较来估计“蓝色”需要多少位才能实现与（例如）“红色”相同的质量. 例如，1960kbps 处的红点的 SSIM 分数为 18.16。蓝线在 17.52 (1950) 和 18.63 (3900kbps) 有两个点。插值给出了 SSIM=18.16 大约 2920kbps 的估计点，大了 49%。因此，要实现相同的 SSIM 分数（质量），x264 需要比 libvpx 多 49% 的比特率。因此，在这个比特率下，libvpx 比 x264 好 49%，这被称为比特率改进（%）。在此比特率下，x265 与 libvpx 相比，x264 的改进大致相同。

红/绿线和蓝线之间的距离随着比特率的降低而变大，因此编解码器在低比特率下具有更高的比特率改进。随着比特率上升，改进下降。我们还可以看到此剪辑的 x265/libvpx 之间的细微差异：在低比特率下，x265 略胜于 libvpx。在高比特率下，libvpx 优于 x265。不过，与任一编码器对 x264 的改进相比，这些差异很小。

所以，这些下一代编解码器听起来很棒。现在让我们谈谈速度。编码器开发人员不喜欢同时谈论速度和质量，因为它们不能很好地结合在一起。老实说：x264 是一种非常优化的编码器，而且很多人仍在使用它。并不是他们不想要更好的比特率/质量比，而是他们抱怨当他们尝试切换时，结果发现这些新编解码器的编码器速度要慢得多，并且当您增加它们的速度设置时（这会降低它们的质量） ，收益消失。让我们来衡量一下！因此，我为每个编码器选择了 4000kbps 的目标比特率，使用与之前相同的设置，但我没有使用慢速预设，而是使用变速预设（x265/x264：–preset=placebo-ultrafast；libvpx： – cpu-used=0-7）。

这是一个人们不经常谈论的图表，所以让我们这样做。在水平方向上，您会看到每帧的编码时间（以 秒为单位）。垂直地，我们看到比特率改进，我们之前介绍的指标，基本上是质量 (SSIM) 和比特率的组合，与参考点相比（x264 @veryslow 是这里的参考点，这就是为什么比特率改进本身为 0 %）。

那么这些结果意味着什么呢？嗯，首先，是的，当然，正如声称的那样，x265/libvpx 比 x264 好约 50%。 但是，它们也慢了 10-20 倍。这不好！如果您对相等的 CPU 使用率进行标准化，您会注意到（再次查看 0%、0.61 秒/帧处的 x264 点），如果您查看垂直上方的红线 (libvpx) 的相交点，则比特率提高标准化的 CPU 使用率 仅为20-30%。对于 x265，只有 10%。更糟糕的是，x265 线实际上 与它左边的 x264 线相交。实际上，这意味着如果 x264 的 CPU 使用率目标比非常慢要快，那么您基本上希望继续使用 x264，因为 在相同的 CPU 使用率目标下，对于相同的比特率，x265 将提供比 x264 更差的质量。libvpx 的情况略好于 x265，但很明显，这些下一代编解码器在这方面还有很多工作要做。这并不奇怪，x264 是比 x265/libvpx 成熟得多的软件。

现在让我们看看解码器的性能。为了测试解码器，我选择了 4000kbps 的 x265/libvpx 生成文件，并以 6500kbps 的速度创建了一个额外的 x264 文件，所有这些文件的 SSIM 分数大致匹配，约为 19.2 (PSNR=46.5)。作为解码器，我使用 FFmpeg 的原生 VP9/H264/HEVC 解码器、 libvpx 和 openHEVC。OpenHEVC 是 FFmpeg 的原生 HEVC 解码器的“上游”，并且具有稍微更好的汇编优化（因为他们在 idct 例程中使用了内在函数(intrinsics)，而 FFmpeg 在这个地方仍然运行 C 代码，因为它不喜欢内在函数）。

那么这是什么意思？让我们从比较 ffh264 和 ffvp9 开始。这些是 FFmpeg 的 H.264 和 VP9 原生解码器。它们的解码速度大致相同，ffvp9 实际上略快，大约快 5%。现在，有趣的事来了。当学者们通常谈论下一代编解码器时，他们声称它会慢50% 。为什么我们在这里看不到？答案很简单：因为我们正在比较相同质量（而不是相同比特率）的文件。如此优化和成熟的解码器往往会将大部分时间花在解码系数上。如果比特率大 50%，则意味着您在系数解码上花费的时间多 50%。所以，虽然编解码器工具在 VP9 中可能比在 VP8/H.264 中复杂得多，比特率节省使我们不会花更多时间在相同质量下进行实际解码任务。

接下来，让我们将 ffvp9 与 libvpx-vp9 进行比较。差别非常大：ffvp9 快了 30%！但我们已经知道了。这是因为 FFmpeg 的代码库比 libvpx 优化得更好。这也为潜在的编码器优化引入了有趣的概念：显然（理论上）我们应该能够制作出比 libvpx 优化得更好（因此速度更快）的编码器。那不是很好吗？

最后，让我们将 ffvp9 与 ffhevc 进行比较：VP9 快了 55%。这部分是因为 HEVC 比 VP9 复杂得多，部分是因为 ffhevc 中的 C idct 例程。为了规范化，我们还与 openhevc（具有 idct 内在函数）进行了比较。它仍然慢了 35%，所以此时 VP9 的故事似乎比 HEVC 更有趣。FFmpeg 的 HEVC 解码器还有很多工作要做。

多线程解码

最后来看一下多线程解码性能：

![ffmpeg-libvpx-openhevc-解码器-mt
](https://blogs.gnome.org/rbult...)

同样，让我们​​从比较 ffvp9 和 ffh264 开始：ffh264 的扩展性要好得多。这是意料之中的，VP9 中的 向后自适应特性在一定程度上影响了多线程缩放，而 ffh264 没有这样的特性。接下来，ffvp9 与 ffhevc/openhevc：它们的缩放比例大致相同。最后：libvpx-vp9。发生了什么？好吧，当在 VP9 比特流中启用后向自适应并禁用平铺时，libvpx 根本不使用多线程，因此我将其称为 libvpx 中的 TODO 项。正如 ffvp9 所证明的那样，没有理由会出现这种情况。

与 x264 相比，下一代编解码器提供 50% 的比特率改进，但在实现此类结果所需的最高设置下，其速度要慢 10-20 倍。

对 CPU 使用进行标准化，libvpx 与 x264 相比已经有一些卖点；除了非常高端的场景外，x265 在大多数实际场景中仍然太慢而无法使用。

ffvp9 是一个非常棒的解码器，其性能优于所有其他解码器。

最后，我在 VDD15 演讲中被问到这个问题，这是一个公平的问题，所以我想在这里解决这个问题：为什么我不谈论编码器多线程？那里肯定有很大的讨论范围（切片、平铺、框架多线程、WPP）。答案是我的编码器部分的主要目标是 VOD（例如 Youtube），他们并不真正关心多线程，因为它不会影响总工作量。如果您在 4 核机器上并行编码四个文件，每个文件需要 1 分钟，或者您使用 4 个线程对每个文件进行串行编码，其中每个需要 15 秒，那么无论哪种方式，您都将使用整个机器 1 分钟。对于 VOD 流媒体服务的客户来说，这是不同的，因为你和我通常一次观看一个 Youtube 视频。