EVC，VVC，LCEVC 测试：最新的 MPEG 编解码器性能如何？

2022-02-18 10:20:15 浏览数 (1)

来源：Streaming Media 原标题：Testing EVC, VVC, and LCEVC: How Do the Latest MPEG Codecs Stack Up? 翻译整理：徐鋆 本文测试了一系列编解码器，结果显示 VVenC 在低于预期的复杂度下提供了高质量。EVC 编解码器达到了它们的质量目标。但此二者都难以很快在软件中播放，必须等待硬件支持来部署它们。LCEVC 在 30% 的编码时间内提供了比全分辨率 x265 更好的质量，并具有相同或更好的播放效率。AV1 在质量上进一步领先，而 MainConcept HEVC FFmpeg 插件也比 x265 的表现好了近 20%。

目录

  • VVC、EVC 和 LCEVC
    • “太长不看”版测试总结
  • 测试什么
    • 测试片段
  • 如何测试
  • 命令行
  • 不针对指标进行优化
  • 编码时间
  • 质量
  • 解码
  • 参考链接

据我所知，这是第一次有研究对代表基本视频编码（Essential Video Coding，EVC）、通用视频编码（Versatile Video Coding，VVC）和低复杂度增强视频编码（Low Complexity Enhancement Video Coding，LCEVC）的编解码器以及 AV1、HEVC 和 H.264 的质量和性能进行比较。它并不像我希望的那样详尽，但结果应该有助于你了解三个较新的 MPEG 编解码器的目标，以及它们与旧编解码器的对比情况。

我将首先快速回顾一下这三个新的 MPEG 编解码器，包括它们的知识产权图片和预期性能包络。然后，我将确定测试的其他编解码器的编码时间、编码质量和解码性能。我将回顾这些结果，然后呈现给你。

VVC、EVC 和 LCEVC

表 1 显示了有关 2020 年推出的三个 MPEG 编解码器的基本数据。关于每个编解码器试图实现的目标的完整讨论，请查看这篇文章[1]。这里是精简指南版本。

VVC 是 H.264 和 HEVC 的合理继任者，有几十家公司贡献了 IP，有积极的质量目标（比 HEVC 高 30% 到 50%），直到开发周期的最后，媒体编码工业论坛[2]介入前，对编码/解码的复杂性的关注（10 倍 HEVC 就可以了）和对提出一个可负担的和有凝聚力的版权图片的关注都不高。

EVC 是 MPEG 对 AV1 和 HEVC 的灾难性版权费推出的回应。有两个配置文件，Baseline 和 Main。Baseline 配置文件应该取代 H.264，节省约 30% 的花费，而且应该是免版税的状态。Main 配置文件旨在取代 HEVC，可节省约 30% 的花费，而且由于只有四家公司提供了知识产权，因此其专利费政策比 HEVC 更明确，可能更便宜。此外，该编解码器是模块化设计的，因此，如果所有者拒绝提供公平的版税，可以很容易地关闭收取版税的工具。

表 1：关于 MPEG 2020 推出的编解码器

LCEVC 是 MPEG 在绿色方面的尝试，这种编解码器敢于在不增加 10 倍编码时间的情况下表现出色。作为一个增强型编解码器，LCEVC 部署了一个现有编解码器（如 x264）的低分辨率基础层和一个增强型 LCEVC 层。例如，在测试中，我们将 1080p 的 LCEVC 流配置为 960x540 的 x265 基础层和一个 LCEVC 层，将输出扩大到 1080p。由此产生的 MP4 流被呈现出来，以便与 LCEVC 不兼容的 HEVC 播放器将简单地播放低分辨率的 HEVC 流，提供向后兼容性。

就质量目标而言，LCEVC 希望提供比全分辨率版本的基础层编解码器（如这些测试中的 x265）更好的质量，并尽可能地接近下一代 MPEG 编解码器（如 VVC）。编码/解码性能包络不应该超过全分辨率下的基础层编解码器。编解码器公司 V-NOVA 拥有与 LCEVC 有关的大部分知识产权，并已宣布了其专利费政策[3]。

“太长不看”版测试总结

我们的测试显示了什么？Fraunhofer VVC 编解码器提供了目标质量，而编码的复杂性比预期的要低得多。两种 EVC 编解码器也都达到了它们的质量目标，其中 Baseline 配置文件在编码方面非常有效，而 Main 配置文件则不那么有效。这些编解码器都难以很快在软件中播放，所以你必须等待硬件支持来部署它们。

LCEVC 实现了三连冠，在 30% 的编码时间内提供了比全分辨率 x265 更好的质量，并具有相同或更好的播放效率。LCEVC 并不是唯一一个让 x265 看起来很糟糕的编解码器；AV1 在质量上进一步领先，而 MainConcept HEVC FFmpeg 插件也比 x265 的表现好了近 20%。

上面是“太长不看”版测试总结，以下是所做的和如何做的实验。

测试什么

我最初测试 EVC 参考编码器，但后来改用开源的 eXtra-fast Essential Video Encoder（XEVE）（0.3.1 版）[4]和 eXtra-fast Essential Video Decoder（XEVD）（0.2.1 版）[5]，它们的质量约为参考编码器的 99%，编码速度大大加快，解码帧率也有所提高。

我首先在这篇文章[6]中测试了 Fraunhofer 的 VVC 代码。在这次回顾中，我测试了 1.2 版的 VVenC 编码器和 VVdeC 解码器。我在这篇文章[7]中首次测试了 LCEVC；在本文中，我使用 V-NOVA 提供的 FFmpeg 4.4 中的 3.4.0 版本的编码器测试了 LCEVC。

我使用 2021-12-02-git-4a6aece703 版 FFmpeg 测试了 x264、x265 和 AV1，该版本于 2021 年 12 月 2 日从 www.gyan.dev 下载。因为 x265 被认为只具有中等水平的 HEVC 性能，我还测试了 MainConcept HEVC Encoder FFmpeg 插件的 2.0.0 版本。

测试片段

我用五个十秒钟的测试片段进行了测试，这些片段代表了一系列的电影、体育、动画和游戏内容，并加入了曲折的 Crowd Run 以衡量纯压缩性能。以下是这些片段简介。

  • Crowd Run：著名的公路比赛开始时的测试片段。
  • Elektra：Jennifer Garner 电影中的一个低动作、谈话头像序列。
  • EuroTruckSimulator2：来自具有挑战性的 Twitch 测试剪辑的片段。
  • Football：在 Dallas Cowboys 体育场拍摄的大学碗赛的 Harmonic 测试片段。
  • Sintel：来自著名的 Blender 动画的片段。

如何测试

我测试了使用基于固定 QP 的编码，在命令行中用 QP 或 CRF 值设置质量水平，编解码器以达到该质量水平所需的数据速率提供文件。为了计算 BD-Rate 统计值，需要四个参考点，所以选择四个 QP 级别，产生所需的质量分布。

在这次回顾中，我选择 x265 作为基线，并对五个测试片段中的四个进行反复编码，以找到四个 QP 值，使 VMAF 分数大致在 80 至 90 VMAF 点之间。然后，我对其他编解码器进行了迭代编码，以找到与 x265 数据率大致匹配的 QP 值。

在最后一个测试片段 Crowd Run 中，我选择了 9Mbps 左右的峰值速率，并顺理成章地下降到 4Mbps 左右，这使得 x265 编码器的 VMAF 值从 57 到 79 不等。然后我找到了相应的 QP 值，为其他编解码器提供相同的数据速率范围。

命令行

对于开源的 EVC 编解码器 XEVE，我使用三星的一位 EVC 开发人员提供的命令行进行了测试，三星是为 EVC 项目贡献知识产权的四家公司[8]之一。开源编码器提供了四个预设：快、中、慢和安慰剂(placebo)。为了选择合适的预设，我使用相同的 QP 值和所有四种预设对两个文件进行了编码，然后测量了编码时间和 VMAF 质量，你可以在图 1 中看到以 100% 分数的百分比呈现。

这表明，对于 Baseline 配置文件，从 fast 到 slow 的编码时间没有什么区别，质量从 98.7% 增加到 99.36%。追逐最后的 0.64% 将增加三倍的编码时间，这似乎不值得，所以我在对 Baseline 配置文件进行编码时使用了 slow 预设。类似的分析和更长的编码时间使我在 Main 配置上使用 medium 预设。

图 1：这一分析表明，slow 预设对 Baseline EVC 编解码器来说是最佳的

作出这一决定后，我使用以下命令行进行 XEVE 编码，使用 Baseline 编码器时，命令行中换成了 slow 和 baseline。

代码语言：javascript复制
xeve_app.exe -i Football.yuv -w 1920 -h 1080 -q 29 -z 30 -I 64 -v 1 
--frames 300 -o Football_main_29.evc -r Football_main_29_rec.yuv -v 3 
--preset medium  --profile main --threads 4

可以用 -q 选项设置 QP 级别，在命令行中设置为 29。像许多早期阶段的编解码器一样，你必须将 I 帧设置为 16 的倍数，这意味着对于像 Football 片段这样的帧率为 30 的文件来说是 64。像许多编码器一样，XEVE 可以在编码周期内从编码的文件中产生一个 YUV 输出文件，这为质量测试节省了一个步骤。这就是命令行中可以看到的 YUV 文件。为了说明的完整性，-z 是帧率，而 -v 设置命令窗口中传回的信息的粗略程度。

不针对指标进行优化

当我在 2020 年底回顾 Franhaufer VVC 编码器时，我让所有编码针对 VMAF 进行优化处理。这一次，我没有调整，因为很少有出版商为生产编码进行调整，而且对 VMAF 指标的改进应该最大限度地减少并最终消除对指标来说好看的东西和对人眼来说好看的东西之间的差异。这是一个复杂的问题，值得更多的讨论（见这篇文章[9]）。就本研究而言，请注意这个决定稍微降低了 VVC、x264 和 x265 的分数，但对其他编解码器的影响不大。

这是我用于 VVenC 编码器的命令行；关于我的理由，请查看之前的文章[10]。这里唯一的变化是启用“感知驱动的 QP 适应”，这是默认设置，也是决定停止调整指标的结果。这使 VVC 平均损失了 0.5 个 VMAF 分数。

代码语言：javascript复制
vvencapp -i Football.yuv -s 1920x1080 -c yuv420 -r 30 --preset medium 
--qp 28 --qpa 1 -ip 64 -t 4 -o Football_vvc_qp28.266

这是 x264 的命令行：

代码语言：javascript复制
ffmpeg -y -i Football.mp4 -c:v libx264 -qp 32 -preset veryslow -threads 4 
-g 60 -keyint_min 60 -sc_threshold 0 Football.mp4_x264_cq_32.mp4

这是 x265 的命令行：

代码语言：javascript复制
ffmpeg -y -i Football.mp4 -c:v libx265 -qp 32 -preset veryslow -threads 4 
-x265-params keyint=60:min-keyint=60:scenecut=0:open-gop=0 Football_x265_qp32.mp4

除了去掉针对指标的优化机制外，两者与上次相比都没有变化。

在 VVC 的文章[11]中，我用开放媒体联盟的独立编码器进行了编码；这次我用了 libaom-AV1，FFmpeg 中的 AV1 编解码器。下面是命令行：

代码语言：javascript复制
ffmpeg -y -i Football.mp4 -c:v libaom-av1 -b:v 0 -g 60 -keyint_min 60  
-cpu-used 3  -auto-alt-ref 1 -threads 4 -tile-columns 1 -tile-rows 0 
-row-mt 1 -lag-in-frames 25 -crf 41  Football_libaom_41.mkv

你可以在这篇文章[12]中找到这个命令行的原理。

下面是 MainConcept 推荐的命令行。

代码语言：javascript复制
ffmpeg" -i Football.mp4 -c:v omx_enc_hevc -omx_core omxil_core.dll -omx_name
OMX.MainConcept.enc_hevc.video -omx_param
"force_omx_param=1:preset=main:perf_level=30:[HEVC
Settings]:fixed_intra_position=1:max_intra_period=60:[HEVC Layer
0000]:bit_rate_mode=4:rate_factor=41" Football_mc_hevc_qp41.mp4 -y

最后，这是 LCEVC 编解码器的命令行，它使用 x265 编解码器作为基础层。V-Nova 提供了这些参数，并建议我也测试 AV1 作为基础层，但我没有时间加入这个版本。

代码语言：javascript复制
ffmpeg -y  -i "Football.mp4" -g 60 -c:v lcevc_hevc  -base_encoder x265 -r
29.97 -s 1920x1080 -b:v 0k -eil_params
"preset=veryslow;rc_pcrf=33;scenecut=0;min-keyint=60;frame-threads=4;
residual_mode_priority_enabled=0;temporal_use_priority_map=0" 
football_pCRF33_LCEVC_x265.mp4

用 x265 而不是 AV1 进行测试是很重要的，因为作为一个增强型编解码器，LCEVC 的性能与基础层编解码器的质量相关联。正如预期的那样，除了 x264 之外，x265 的质量是所有测试的编解码器中最低的，这必然也会降低 LCEVC 的得分。在质量分析中会有更多关于这个问题的内容。

编码时间

我在惠普工作站上测试了编码时间，该工作站采用 3.4GHz 英特尔 i7-3770 处理器，拥有 16GB 内存和 4 个核心，在启用 HTT 的情况下有 8 个线程。表 2 中显示的结果是两个 10 秒测试文件的综合时间，以及与 x265 相比的编码时间和实时百分比。

表 2：被测编解码器的编码时间

请注意，Fraunhofer VVC 编解码器的编码时间约为 x265 的 2 倍，远远低于预期的 10 倍。LCEVC 大约是 x265 编码时间的 0.3 倍，MainConcept HEVC 编解码器大约是 0.83 倍。

XEVE 编码器在 H.264 编码时间的 2 倍以下产生了 Baseline EVC 文件，这令人印象深刻。虽然 Main 配置的编码时间看起来很慢，但请记住，当我们在 2018 年首次测试 AV1 时，它约为 45,000 倍实时时间[13]，看看它已经走了多远，基本上与使用 very slow 预设的 x265 编码速度相同。

为了记录，我一开始使用的 EVC 参考编码器时间在 2:33:56（是的，这是两个小时，33 分钟和 56 秒）中产生了两个 Baseline 文件，在 9:08:39 中产生了 Main 文件。当我发现开源的 EVC 编码器可以在很小的时间内提供几乎相同的质量，切换到开源软件的决定就变得很明显了。

质量

表 3 显示了所列编解码器的 BD-Rate 结果。当你按行阅读时，这些表格是最有意义的。因此，如果你从 x265 行开始，x265 编解码器可以在低 33.86% 的比特率下产生与 x264 相同的质量（绿色是好的），但必须增加 24.44% 的比特率来匹配 MainConcept 编码器的质量（粉红色是坏的）。

表 3：所有被测编解码器的 BD-Rate 对比

在低质量一侧，正如预期的那样，EVC Baseline 编解码器以大约 30% 的比特率降低产生了与 x264 相同的质量，但远远落后于 HEVC 编解码器和 AV1。自 VVC 比较以来，AV1 对 x264 和 x265 的领先优势增加了约 10 个点；大部分的增加是因为我没有像上次那样对 x264 和 x265 进行针对指标的优化。在上次回顾中，我没有对 AV1 进行针对指标的优化，因为它没有什么区别，这次我也没有调整。

MainConcept 编解码器的性能大大优于 x265，如前所述，它是一个 FFmpeg 插件。你可以在这里[14]买到该插件的版本。虽然它的价格只有 99 美元，但它有一个很大的“非商业用途”要求，所以如果你想在生产中部署编解码器，你必须与 MainConcept 协商费用。

以 x265 为基础层的 LCEVC 比 x265 的效率高 22.47%，这是令人印象深刻的。在近期的某个时间点，我们必须测试一下，看看使用 AV1 作为基础层是否会将性能提高到高于 AV1、EVC Main 和 VVC 。

在高质量侧，所有的荣耀都归于 VVenC，尽管 EVC Main 编解码器意外地接近。同样，如果我们像上次那样对指标进行调整，VVenC 的比较性能会更高。同时，EVC Main 编解码器产生了与 x265 和 MainConcept HEVC 编码器相同的质量，比特率降低了 41.56% 和 27.04%，符合质量目标。

图 2 以速率-失真曲线展示了相同的结果。你看到 x264，孤独地在底部，其次是绿色的 EVC Baseline 和橙色的 x265。显然，EVC Baseline 的设计是为了取代 H.264，而不是与更高端的编解码器争夺。

图 2：被测编解码器的速率失真曲线

在最高端，VVenC 略微超过了 EVC Main 和 AV1，但差别并不明显。很可能是一些其他因素，如解码性能、播放兼容性，甚至是许可成本，将决定你在这三种编解码器中的决策。

在测试和分析过程中，我不断回到 AV1 和两个 HEVC 版本之间的质量差距，特别是 x265。我检查了几个片段以确认这些发现，并想与你分享图 3。这是一个分屏视图，Libaom-AV1 在左边，x265 在右边。在网上，尤其是在印刷品中，这总是很困难的，但希望你能看到 Libaom-AV1 编码的人工草皮是如何保持其完整性的，而 x265 编码的草地则是高度伪装的。这是一个极端的案例，但所有的主观比较都证实了得分的差异。

图 3：Libaom-AV1 保留了人工草皮的视觉完整性，而 x265 则破坏了它

解码

虽然编码时间决定了编码成本，而输出质量决定了新编解码器所带来的带宽节省（或 QoE 改善），但解码性能决定了你可以在哪里实际使用编解码器。特别是对于移动分发，如果手机或平板电脑不能在不影响电池寿命的情况下以全帧率播放视频，那么生产商就不会部署新的编解码器，直到有了基于硬件的播放。这就是解码性能如此重要的原因。

我在与编码器相同的机器上测试了解码性能，将文件存储在 RAM 磁盘中，并按照这里[15]的描述解码到 RAM 磁盘。我使用 2 分钟版本的 Harmonic Football 测试片段测试了大多数解码器，但对 VVC 和两个版本的 EVC 测试了 10 秒版本。

我使用标准版本的 FFmpeg 解码 H.264、H.265 和 AV1，以及 V-NOVA 和 MainConcept 提供的定制版本的 FFmpeg 解码各自的编解码器。我对 VVC 使用了 Fraunhofer 的 VVDeC 解码器，对 EVC 使用了开源的 XEVD 解码器。表 4 显示了所有解码器所达到的每秒帧数。

表 4：每个解码器达到的每秒帧数

正如你在图 4 中看到的，H.264、H.265，特别是 AV1 在利用可用的算力方面非常有效，就像 Fraunhofer 的 VVDeC 解码器一样，尽管帧率并不接近。即使在解码脚本中指定了 8 个线程，EVC 开源解码器也不能完全利用可用的处理能力，导致帧率相对较低。

图 4：解码帧率和解码器使用的 CPU 资源

我向 V-Nova 询问了他们的帧率和 CPU 使用情况，因为这些结果从表面上看是令人失望的。他们的回答很有启发性。“一般来说，我们从不为超出实时要求的最大解码帧率进行优化，而是为功耗进行优化。只要解码器的 FPS 在合理的硬件上远远超过实时性，这个数字就变得相当不重要，而功耗确实很重要。”

为了验证这一点，我通过在 FFmpeg 中使用 -re 选项强制实时播放，并使用 Windows 应用程序性能监控器监控 CPU 的使用情况来测量 CPU 的使用。你可以在图 5 中看到 H.264、HEVC、AV1 和 LCEVC 的结果。

图 5：虽然 LCEVC 的帧率没有竞争力，但在功耗方面肯定是有竞争力的

结果证实了 V-Nova 的说法。整体的 CPU 利用率当然比 AV1 低，而且看起来也比 HEVC 平均低。除非你绝对需要每秒 300-400 帧，否则以 HEVC 为基础层的 LCEVC 似乎至少与在软件中播放的 HEVC 一样有效，甚至更有效。

那么，我们该怎么办呢？

两种 EVC 编解码器都达到了它们的质量目标，而且 Baseline 编解码器显示了令人印象深刻的编码速度。Main 编解码器提供了更高的质量，但编码速度要慢得多，两者都需要硬件来实现合理功耗下的全帧率播放。

VVenC 的编码速度大约是 x265 的一半，与我们之前的测试相比有了很大的改进，并提供了一流的质量，即使只是高一点点。像 EVC 编解码器一样，VVC 在短期内似乎不会在移动设备上的软件中有效播放。

以 x265 为基础层的 LCEVC 的编码时间为 x265 的 30%，以大约 78% 的数据速率提供相同的质量，并且在解码时比直接的 HEVC 更有效率。同样，看看 LCEVC 的性能如何与作为基础层的更高性能的编解码器相比较，将会非常有趣。

从质量和编码时间的角度来看，AV1 越来越有竞争力，特别是与 x265 相比。说到 x265，我不知道 MainConcept 编解码器的授权费用是多少，但至少在我们基于 QP 的测试中，它在稍快的编码时间内比 x265 减少了约 20% 的带宽。如果你是 x265/FFmpeg 的用户，请购买或试用 MainConcept 插件，用你现有的参数进行比较，看看是否有必要转换。

参考链接

  1. https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=134694
  2. https://www.streamingmedia.com/Articles/News/Online-Video-News/VVC-Patent-Pools-And-Then-There-Were-Two-144949.aspx
  3. https://www.streamingmedia.com/Articles/News/Online-Video-News/V-Nova-LCEVC-Royalty-Structure-Announced-147003.aspx?
  4. https://github.com/mpeg5/xeve
  5. https://github.com/mpeg5/xevd
  6. https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/How-Does-VVC-Measure-Up-Right-Now-144235.aspx?utm_source=related_articles&utm_medium=gutenberg&utm_campaign=editors_selection
  7. https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/How-to-Encode-with-LCEVC-139705.aspx
  8. https://en.wikipedia.org/wiki/Essential_Video_Coding
  9. https://streaminglearningcenter.com/encoding/best-practices-for-netflixs-vmaf-metric.html
  10. https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=144235
  11. https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=144235
  12. https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/AV1-Has-Arrived-Comparing-Codecs-from-AOMedia-Visionular-and-Intel-Netflix-142941.aspx?utm_source=related_articles&utm_medium=gutenberg&utm_campaign=editors_selection
  13. https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/AV1-A-First-Look-127133.aspx
  14. https://www.mainconcept.com/ffmpeg?hsLang=en#try-free
  15. https://streaminglearningcenter.com/ffmpeg/ffmpeg-to-the-rescue-decoding-files-into-ram-for-decode-testing.html
图像处理 腾讯云测试服务 https 网络安全 视频处理

0 人点赞