2021年12月29日
By 1月时特约编辑
专题文章

测试EVC, VVC，和LCEVC:如何做最新的MPEG编解码器堆栈?

好吧，我会说的. 据我所知, 这是第一次有研究比较了代表基本视频编码(EVC)的编解码器的质量和性能。, 通用视频编码(VVC), 低复杂度增强视频编码(LCEVC), 以及AV1, HEVC, 和H.264. 它没有我想的那么详尽, 但结果应该可以帮助您了解三种新MPEG编解码器的目标以及它们与旧编解码器的比较.

我将从快速回顾三种新的MPEG编解码器开始, 包括他们的IP图片和预期的性能信封. 然后，我将确定我们测试的编码时间的其他编解码器, 编码质量, 以及解码性能. 我会检查结果，然后送你上路.

VVC, EVC和LCEVC(天哪!)

表1显示了2020年推出的三种MPEG编解码器的基本数据. For a complete discussion of what each codec was attempting to accomplish, please check 这篇文章. 这是CliffsNotes的版本.

VVC是H的合理继承者.264和HEVC, 有几十家公司提供知识产权, 积极的质量目标(超过HEVC 30% - 50%), 对编码/解码复杂性的关注最小(10倍HEVC即可), 而对于呈现出一幅可负担且具有凝聚力的版税图景的关注也很少，直到开发周期的最后媒体编码产业论坛介入.

EVC是MPEG对AV1和HEVC灾难性的版税推出的回应. 有两个配置文件，基线和主. 基线概要文件应该取代 H.264 有大约30%的储蓄和所谓的免版税的姿态. 主配置文件的目的是替换 HEVC, 有大约30%的储蓄和一个更清晰的, 可能比HEVC更便宜的版税政策，因为只有四家公司贡献了知识产权. 除了, 编解码器是模块化设计的，因此如果所有者拒绝提供公平的版税，可以很容易地关闭版税工具.

表1. 关于MPEG的2020级编解码器.

LCEVC是MPEG走向绿色的尝试, 一个无需增加10倍编码时间的编解码器. 作为增强编解码器, LCEVC将现有编解码器(如x264)的低分辨率基础层与增强的LCEVC层部署在一起. 例如, 在我们的测试中, 我们将1080p LCEVC流配置为960x540 x265基础层和将输出扩展到1080p的LCEVC层. 由此产生的MP4流被呈现出来，这样与LCEVC不兼容的HEVC播放器将简单地播放低分辨率的HEVC流, 提供向后兼容性.

在质量目标方面, LCEVC aspires to deliver better quality than a full-resolution version of the base-layer codec (e.g. x265)，并尽可能接近下一代MPEG编解码器(例如.g. VVC). The encode/decode performance envelope shouldn't exceed that of the base layer codec at full resolution. 完成这幅图， codec company V-NOVA owns most of the IP related to LCEVC 和 has already 宣布它的版税政策.

TL /博士

我们的测试结果如何? 好吧, the Fraunhofer VVC codec delivered the targeted quality with much less encoding complexity than expected. 两个EVC编解码器都达到了它们的质量目标, 基线配置文件在编码方面非常有效, 主配置文件没有那么多. 这些编解码器都不会很快在软件中播放, 因此，您必须等待硬件支持来部署它们.

LCEVC达到了三连冠, 在30%的编码时间内提供比full-rez x265更好的质量，具有相同或更好的播放效率. LCEVC wasn't the only codec that made x265 look bad; AV1 pulled ahead even further in quality while the MainConcept HEVC FFmpeg plug-in also outperformed x265 by just under 20%.

That's the TL /博士 version; 在这里's what I did 和 how I did it.

我测试了什么

我开始测试EVC参考编码器，但后来切换到开源超高速基本视频编码器(XEVE)(版本0.3.1)和超高速基本视频解码器(XEVD) (版本0.2.1)它提供了参考编码器质量的99%，编码速度快得多，解码帧率也提高了.

我首先测试了弗劳恩霍夫的VVC代码在这里. 在本文中，我测试了版本1.2台VVenC编码器和VVdeC解码器. 我首先测试了LCEVC 在这里; 在本文中，我使用版本3测试了LCEVC.4.0的编码器提供在一个FFmpeg 4.4由V-NOVA建造.

I tested x264, x265, 和 AV1 using FFmpeg version 2021-12-02-git-4a6aece703, downloaded from www.吉安.2021年12月2日. Because x265 is recognized as a middle-of-the-road HEVC performer, I also tested version 2.0.0的MainConcept HEVC编码器FFmpeg插件.

测试视频

我用5个10秒的测试片段来测试一系列电影, 体育, 动画, 以及游戏内容, 加入了曲折的人群运行来衡量纯压缩性能. 以下是视频片段.

人群中运行-众所周知的公路赛开始的测试片段.

厄勒克特拉——詹妮弗·加纳电影中一个低动作、会说话的头部镜头.

EuroTruckSimulator2-一个片段从具有挑战性的Twitch测试剪辑.

足球-在达拉斯牛仔队体育场拍摄的大学碗比赛的谐波测试片段.

Sintel—一个片段从著名的Blender动画.

我是如何测试的

我测试使用固定的基于qp的编码, 您在命令字符串中使用QP或CRF值设置质量级别，编解码器以达到该质量级别所需的数据速率传送文件. 计算BD-Rate统计, 你需要四个参考点, 所以你可以选择四个QP级别来产生理想的质量分布.

回顾一下, 我选择x265作为基线，并对五个测试片段中的四个进行迭代编码，以找到四个QP值，这些值提供的VMAF分数大致在80到90 VMAF点之间. 然后我使用其他编解码器进行迭代编码，以找到与x265数据速率大致匹配的QP值.

最后一个测试片段， 人群中运行, 我选择9Mbps左右的峰值速率，然后按逻辑逐步降至4Mbps左右, 它产生的VMAF值范围从57到79的x265编码器. 然后我发现QP值为其他编解码器提供了相同的数据速率范围.

命令字符串

使用开源的EVC编解码器, XEVE, 我使用三星EVC开发人员提供的命令字符串进行了测试, 其中之一四家公司为EVC项目贡献知识产权. 开源编码器提供四种预设:快速、中速、慢速和安慰剂. 选择合适的预设, 我使用相同的QP值和所有四个预设编码了两个文件，然后测量了编码时间和VMAF质量, 你看到了百分百分数的百分比吗图1.

这显示了基线概要文件, t在这里 was little difference in encoding time from fast through 慢和 that quality increased from 98.7%的最大值为99.36%. 追逐最后一个 .64%的人会将编码时间增加三倍，这似乎不值得, 所以我在编码基线配置文件时使用了慢速预设. A similar analysis 和 vastly longer encoding times lead me to use the medium preset for the Main profile.

图1. 分析表明，对于基线EVC编解码器，慢速预设是最佳的.

This decision made, I used the following comm和 line for the XEVE encodes, swapping in 慢 和 基线 对于基线编码.

xeve_app.exe -i 足球.yuv -w 1920 -h 1080 -q 29 -z 30 -I 64 -v 1 -帧300 - 0足球main_29.evc -r 足球_main_29_rec.Yuv - v3——预设介质 ——profile main——threads

设置QP级别 -q Switch，在命令字符串中设置为29. 像许多早期的编解码器一样, 你必须将i帧设置为16的倍数, 这意味着像足球剪辑这样的30帧文件需要64帧. 像许多编码器一样, 在编码周期中，XEVE可以从已编码的文件生成YUV输出文件, 这为质量测试节省了一步. 这是您在第二行中看到的YUV文件. 完成这幅图， -z 是帧率，和 -v 设置从“命令”窗口返回的消息的冗长级别.

没有调整参数

When I reviewed the Franhaufer VVC encoder in late 2020, I tuned all encodes for VMAF processing. 这一次, 我之所以没有进行调整，是因为很少有发行商会针对产品编码进行调整，而且VMAF指标的改进应该最小化并最终消除指标与人眼之间的差异. 这是一个值得长时间讨论的复杂问题在这里). 为了本研究的目的, 请注意，这个决定略微降低了VVC的分数, x264, 和x265, 但对其他编解码器几乎没有影响.

Here's the comm和 string I used for the VVenC encoder; check the 前一篇文章我的理由是. 这里唯一的变化是启用“感知驱动的QP适应”,这是默认设置, 以及决定停止对指标进行调优的后果. 这花费了VVC大约 .VMAF平均5分.

vencapp -足球.yuv -s 1920x1080 -c yuv420 -r 30 --preset medium --qp 28 --qpa 1 -ip 64 -t 4 -o 足球_vvc_qp28.266

x264的命令字符串是:

足球.mp4 -c:v libx264 -qp 32 -preset very慢 -threads 4 -g 60 -keyint_min 60 -sc_threshold 0 足球.mp4_x264_cq_32.mp4

x265的命令字符串是:

足球.mp4 -c:v libx265 - qp32 -预设非常慢-线程4 -x265-params keyint=60:min-keyint=60: sceneccut =0:open-gop=0足球x265_qp32.mp4

除了删除了调优机制外，两者都与上次相同.

在 VVC的文章, I encoded with the Alliance for Open Media's st和alone encoder; 这 time I went with libaom-AV1, AV1编解码器在FFmpeg. 下面是命令字符串:

足球.Mp4 -c:v libaom-av1 -b:v 0 -g 60 -keyint_min 60 cpu使用量3 -auto-alt-ref 1 -threads 4 -tile-columns 1 -tile-rows 0 -row-mt 1 -lag-in-frames 25 -crf 41 足球_libaom_41.mkv

可以找到这个命令字符串背后的基本原理这 article.

下面是MainConcept推荐的命令字符串.

-足球.Mp4 -c:v omx_enc_hevc -omx_core.dll -omx_name OMX.MainConcept.enc_hevc.视频-omx_param “force_omx_param = 1:预设=主要:perf_level = 30: [HEVC 设置:fixed_intra_position = 1: max_intra_period = 60: [HEVC层 0000]: bit_rate_mode = 4: rate_factor 足球_mc_hevc_qp41 = 41”.mp4 - y

Finally, 在这里's the comm和 string for the LCEVC codec which uses the x265 codec as the base layer. V-Nova provided these parameters 和 recommended that I also test AV1 as the base layer, 但我没有时间把那个版本整合进去.

ffmpeg是我“足球.Mp4 " -g 60 -c:v lcevc_hevc -base_encoder x265 29.-s 1920x1080 -b:v 0k -eil_params “预设= very慢; 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

与AV1相比，使用x265进行测试非常重要，因为它是一种增强编解码器, LCEVC的性能与基础层编解码器的质量有关. 正如预期的, 除了x264, 在所有测试的编解码器中，X265的质量是最低的, 这必然会降低LCEVC的分数. 在质量分析中会详细介绍这一点.

编码时间

我在一台HP工作站上测试了编码时间.4 GHz Intel i7-3770 CPU with 16GB of RAM 和 4 cores 和 eight threads with HTT enabled. 结果显示在表2 两个10秒测试文件的合并时间是多少, 以及与x265相比的编码时间和实时的百分比.

Ozer EVC编码次数

表2. 测试编解码器的编码时间.

请注意，弗劳恩霍夫VVC编解码器的编码时间大约是x265的2倍, 远低于预期的10倍. LCEVC是关于 .x265和MainConcept HEVC编解码器编码时间的3倍 .83x.

XEVE编码器在不到2倍的时间内生成基线EVC文件.264编码时间，令人印象深刻. 虽然主配置文件编码时间看起来很慢，但请记住AV1是关于实时45000次当我们在2018年第一次测试它时, 看看它已经走了多远, 本质上与使用非常慢的预设的x265编码速度相同.

郑重声明, the EVC reference encoder that I started off using produced the two Baseline files in 2:33:56 (yes, 那是两个小时, 33分钟, 和56秒)和主文件在9:08:39. 有一次我发现开源的EVC编码器可以在很短的时间内提供几乎相同的质量, 转向开源软件的决定变得显而易见.

质量

表3 显示列出的编解码器的BD-Rate结果. 当您按行读取这些表时，它们是最有意义的. So, if you start on the x265 row, the x265 codec can produce the same quality as x264 at a 33.比特率降低86%(绿色表示不错)，但必须将比特率提高24.44%与MainConcept编码器的质量匹配(粉红色表示质量差).

Ozer EVC编码次数

表3. 所有测试编解码器的bd速率比较.

在低端, 正如预期的, EVC基线编解码器产生了与x264相同的质量，比特率降低了30%，但远远落后于HEVC编解码器和AV1. AV1's lead over x264 和x265 increased by about 10 points since the VVC comparison; much of the increase is because I didn't tune for metrics with x264 和x265, 就像上次一样. 在上次复习中, 我没有调整AV1的参数，因为它几乎没有什么不同, 这次我也没调.

The MainConcept codec h和ily outperformed x265 和, as mentioned, comes as an FFmpeg plug-in. 您可以选择插件的一个版本在这里. 虽然它的售价只有99美元，但它有一个很大的“非商业用途”要求, 因此，如果您想为生产部署编解码器, 你必须和MainConcept公司协商费用.

以x265为基础层的LCEVC为22.比x265效率高47%，令人印象深刻. 在近期的某个时候, we'll have to test 和 see if using AV1 as a base layer would improve performance beyond the AV1, EVC主要, 和VVC.

At the high end, all glory goes to VVenC, though the EVC主要 codec was unexpectedly close. 再一次。, VVenC's comparative performance would have been higher had we tuned for metrics as we did last time. 与此同时, EVC主编解码器产生了与x265和MainConcept HEVC编码器相同的质量，比特率降低了41.56%和27%.04%，达到质量目标.

图2 给出了与利率扭曲曲线相同的结果. You see x264, lonely on the bottom, followed by EVC Baseline in green 和x265 in orange. 显然，EVC基线旨在取代H.264，而不是与更高端的编解码器竞争.

图2. 低端编解码器的速率失真曲线.

在最顶端, VVenC略优于EVC主要和AV1, 但这种差别没有意义. 很可能是其他因素, 比如解码性能, 播放兼容性, 甚至是许可成本, 会在这三者中决定你的编解码器吗.

在测试和分析期间, 我不断回到AV1和两个HEVC版本之间的质量差异, 尤其是x265. 我从视觉上检查了几个片段来证实这些发现，并想分享图3 和你在一起. 这是一个分屏视图，Libaom-AV1在左边，x265在右边. 网上总是很艰难，尤其是印刷媒体, 但是希望, 你可以看到Libaom-AV1编码的人造草坪是如何保持其完整性的, 而x265编码的草是高度人工的. This was an extreme case, but all subjective comparisons confirmed the scoring differential.

Libaom-AV1和x265的足球剪辑

图3. Libaom-AV1 preserved the visual integrity of the artificial turf, while x265 destroyed it.

解码

而编码时间决定了编码成本, 和输出质量的带宽节省(或QoE改进)提供了一个新的编解码器, 解码性能决定了您可以在何处实际使用编解码器. 特别是对于移动发行, if a phone or tablet can't play the video at the full frame rate without compromising battery life, 在基于硬件的播放可用之前，制作人不会部署新的编解码器. 这就是解码性能如此重要的原因.

我在与编码器相同的机器上测试了解码性能, 将所述文件存储在RAM磁盘中并解码到所述RAM磁盘在这里. 我使用2分钟版本的harmoneffootball测试片段测试了大多数解码器，但测试了10秒版本的VVC和两个版本的EVC.

我使用标准版本的FFmpeg解码H.264, H.265, 和 AV1 和 custom versions of FFmpeg supplied by V-NOVA 和 MainConcept for their respective codecs. 我使用夫琅和费的VVDeC解码器的VVC，和开源的XEVD解码器的EVC. 表4 显示所有解码器每秒达到的帧数.

为所有编解码器解码FPS

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

你可以看到图4, H.264, H.265, 特别是AV1在利用可用马力方面非常有效，弗劳恩霍夫的VVDeC解码器也是如此, 虽然帧率不是很接近. 即使在解码脚本中指定了8个线程, EVC开源解码器无法充分利用可用的处理能力, 导致相对较低的帧速率.

解码帧率和CPU使用率

图4. 解码帧率和解码器使用的CPU.

I asked V-Nova about their frame rate 和 CPU usage, which on their face looked disappointing. 他们的回答很有启发性. “总的来说, 我们从来没有优化，以最大限度地解码帧率超出实时性要求, 相反，我们对能耗进行优化. 只要解码器FPS在合理的硬件上远远超过实时, 这个数字就变得无关紧要了, 而权力确实很重要."

为了验证这一点，我通过在FFmpeg中使用 -re 使用Windows应用程序Performance Monitor切换和监控CPU使用情况. 你可以看到H的结果.264, HEVC, AV1，和LCEVC中的图5.

LCEVC耗电量

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

结果证实了V-Nova的说法. Overall CPU utilization was certainly less than AV1 和 looks to be lower on average than HEVC as well. 除非你绝对需要300-400帧每秒, LCEVC with HEVC as a base layer appears at least as efficient as HEVC played back in software, 如果不是这样的话.

那么这给我们带来了什么呢?

两个EVC编解码器都达到了它们的质量目标, 基线编解码器显示出惊人的编码速度. 主编解码器提供了更高的质量，但编码速度要慢得多, 和 both will need hardware to achieve full-frame rate playback with reasonable power consumption.

VVenC encoded at roughly half the speed of x265 which was vastly improved from our previous tests, 并提供一流的质量, 哪怕只差一点点. 比如EVC编解码器, it doesn't appear that VVC will play efficiently in software on mobile devices in the near term.

以x265作为基础层的LCEVC在30%的时间内编码为x265, 以大约78%的数据速率提供相同的质量, 并且在解码过程中比直接的HEVC更有效率. 再一次。, 看到LCEVC的性能如何以更高性能的编解码器作为基础层是非常有趣的.

AV1 keeps getting more 和 more competitive from a quality 和 encoding time perspective, 特别是与x265相比. 说到x265, 我不知道MainConcept编解码器的许可费用是多少, 但至少在我们的qp测试中是这样的, 它减少了x265 20%的带宽，编码时间略快. 如果您是x265/FFmpeg用户，购买或试用 MainConcept插件, 比较使用您现有的参数，看看是否有意义切换.

(作者希望感谢三星的Minsoo Park对EVC编解码器编码的大力支持和帮助. 我也感谢弗劳恩霍夫的本杰明·布罗斯(VVC)的帮助, MainConcept的Thomas Kramer (HEVC), 和V-Nova (LCEVC)的Guendalina Cobianchi. The author would also like to thank Andrey Pozdnyakov from Elecard for a high-level tech read. 所有的错误都是我的责任. ]

[编者注:本文已更新，以纠正LCEVC基础层的决议，并澄清LCEVC的质量目标。.)

本文出现在2022年流媒体行业资料手册. 以“检测EVC、VVC和LCEVC”为名."