2023年3月21日
By 1月时特约编辑
专题文章

如何用FFmpeg制作VVC

任何时候你开始使用新的编解码器, 为了实现最佳性能/质量优化，您应该运行一些基本测试. 在本文中, 我将带您完成这些测试，同时使用包含Fraunhofer VVC编解码器的FFmpeg版本编码VVC.

You can learn how to compile a version of FFmpeg with the 弗劳恩霍夫VVC编解码器. 弗劳恩霍夫的VVC编解码器似乎不会被纳入FFmpeg的基线版本，原因在go2sm上讨论过.com/baseline.

第一步:掌握基本知识

在开始尝试影响质量和性能的编码选项之前, 您应该从创建适合自适应比特率(ABR)分发的文件的脚本开始. 这通常意味着可变比特率(VBR)编码、2秒GOP大小和封闭GOP.

通常, I experiment with two 10-second files: one a music video called 免费的dom, the other an American football test clip from Harmonic. 自由更容易被压缩, 动作更低，细节更少, 而足球是一个挑战, 用高动作和很多复杂的细节.

I typically target a VMAF score of around 80–90 in my tests, which should stress the codec and the parameters I’m testing. 如果你的目标是95 +，你不会看到与测试参数的显著差异. 如果你的目标是70年代, 你可能会得到与你通常以93-95 VMAF发布的视频无关的结果. 我在Windows上进行了测试, 但是测试和命令字符串应该在Linux和macOS上进行最小的修改.

第一个命令字符串创建一个适合ABR分发的基本文件:

输入.Mp4 -an -vcodec vvc-b:v 1.4M 期2 -subjopt 0 -vvencparams "decodingrefreshtype=idr" output.mp4

Here’s an explanation of the key switches in this string.

Ffmpeg -调用程序.
-i -是输入文件.
-vcodec vvc -是VVC编解码器.
-b:v 1.4M -是目标比特率.
期2 -是2秒共和党.
-subjopt 0 —disables subjective optimization because we’re testing with metrics.
-vvenc-params -是vc特定的选项.
-decodingrefreshtype =印尼盾 关闭GOP(默认打开).

这些选项中的大多数都是不言自明的，尽管其中有几个值得讨论. 第一个, 关于比特率, 我的初始命令字符串通常将可变性限制为200%受限VBR. I tried adding maxrate and bufsize to the command string to accomplish this. 虽然没有错误消息，但对文件大小或质量也没有影响. It was the same exact file with or without, so I left them out. 我问过弗劳恩霍夫这个问题, 该公司回应说:“这些参数目前不支持VVenC，但我们的RC不应该超过200%。.”

还要注意，我使用-subjopt 0禁用了主观优化，因为我一直在使用VMAF测量质量. 如果你是为了发行而制作, you should include the subjective optimizations; if you’re producing to compare to HECV, AV1, 或其他编解码器, you should leave this in and make sure to use a similar switch, 比如-tune PSNR, 使用其他编解码器.

Encoding using this string provided the baseline quality level; my first experiment is always whether to use single-pass or two-pass encoding.

单通道或双通道编码?

每个初露头角的压缩学家学到的第一课之一是，对于VBR编码，两道编码优于单道编码. 按照逻辑, 第一次通过识别易于编码和难以编码的区域，使编码器能够分配比特率，以获得最佳的整体质量. 在这种情况下是正确的, 这并不是普遍正确的, 特别是对于速率控制机制尚未优化的新编解码器. So, you should always encode using single-pass and two-pass modes, 测量编码时间和质量差异, 然后做出决定.

郑重声明, 我在一台32核64线程的戴尔精密7820处理器上进行了测试，它配备了两个运行速度为2的英特尔至强黄金6226R处理器.9 GHz running Windows 10 Pro for Workstations with 64GB of RAM. Each CPU has 16 cores and 32 threads for a total of 64 threads. 以下是我用于双通道编码的命令字符串，新开关为绿色:

输入.Mp4 -an -vcodec VVC -b:v 1.4 . 期2 -subjopt 0 - vencs -params " 通过= 2:通过= 1:rcstats文件=stats _ free _ VVC _ 2pass.Json: decodingrefreshtype=idr "输出.Mp4 ffmpeg -i输入.Mp4 -an -vcodec VVC -b:v 1.* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *.Json: decodingrefreshtype=idr"输出.mp4

再一次。, the new switches are straightforward: The first calls for two-pass encoding; the second identifies the pass. You can name a JSON file to store the first-pass 信息. Rather than the Nul - that you typically see with two-pass encoding, 您必须在两次传递中都为文件命名.

通过= 2 两遍编码
通过= 1 这/秒通过
rcstatsfile=stats _ free _ VVC _ 2pass.json数据文件
需要在两次传递中命名输出文件

表1(下) shows the basic analysis, again with the two 10-second files. 与通常情况一样，这个实例中的编码时间差很小. 第一关几乎总是很快, 在这种情况下, 平均增加的编码时间少于3%. 在表格中，绿色背景表示表现最好，黄色背景表示表现最差. A quick glance reveals that two-pass delivers better overall quality, 低帧质量, 标准偏差.

VVC表1

Average VMAF is computed using the harmonic mean method, which incorporates 质量变化进入总分. Low frame is the lowest score for any single frame in the video, 哪个是暂时质量问题的预测因子. Standard deviation measures the variability of the quality score. Whereas higher scores are better for the first two quality metrics, 标准差越低越好.

我计算了所有的质量分数莫斯科国立大学视频质量测量工具. 在“一张图片胜过千言万语”类别中，它也产生了如图所示的图表 图1(下面)，它绘制了单帧VMAF分数(红色)和两帧VMAF分数(绿色). 这是足球片段, 你可以看到，在多个区域，单遍编码的质量明显低于两遍编码.

VVC每帧VMAF分数

请注意，这个结果图包括一个显示帧按钮，可以让您查看视频中的任何帧，并在源文件和所有编码版本之间切换. 我在这里做过, 单遍文件中质量较低的区域表现为数字模糊和细节丢失. 这是两次编码，然后进行下一个测试.

线程计数和波前同步

拥有32核/64线程的机器, 我急切地想知道有多少我可以有效地应用于VVC编码. 弗劳恩霍夫提供的一个建议是, “如果你有超过8个内核可用, you get more speed when defining more than 8 threads and using:

-vvenc-params“wavefrontsynchro = 1:瓷砖= 2 x2”

同时测试两个参数(线程和波前同步)通常不是一个好主意。, 这证明了这里的情况. Here’s the string I used, with the new switches in green:

输入.mp4 -an -vcodec vvc 期2 -threads 16 -preset fast -subjopt 0 - vencs -params " 通过= 2:通过= 1:rcstatsfile=stats _ F1 _ 4M _ fast.json: decodingrefreshtype=idr:wavefrontsynchro=1:tiles=2x2" -b:v 1.4 m输出.Mp4 ffmpeg -i输入.mp4 -an -vcodec vvc 期2 -threads 16 -preset fast -subjopt 0 - vencs -params " 通过= 2:pass=2:rcstatsfile=stats _ F1 _ 4M _ fast.json: decodingrefreshtype=idr:wavefrontsynchro=1:tiles=2x2” -b:v 1.4 m输出.mp4

Threads设置线程数，而wave front应用推荐的附加开关. Seeking to flex all of the cores on the Dell workstation, I first tested up to 64 threads with 波阵面同步 enabled. But I also tested eight threads with and without 波阵面同步. 图2(下面) 这是我的初步发现, 编码时间用绿色表示, 整体质量为红色, 蓝色的低画框质量. All scores show each setting’s results as a percentage of 100%; for encoding time, 100%是最长的编码时间, 还有质量分数, 100%是最高质量分数.

波阵面同步

So, 使用8个线程且没有波前同步的测试产生了最长的编码时间, 但提供了100%的整体和低帧质量. 在八线程编码中加入波前同步可以减少大约8个编码时间.5%，但整体质量下降了1%.低帧质量降低3%.2%. So, it appears that 波阵面同步 negatively impacted quality.

另一个明显的结论是，超过16个线程对性能或质量没有影响. 我和弗劳恩霍夫核对过了, 这证实了1080p视频的优势将在16个线程时达到顶峰，但更高的分辨率将受益于更高的线程数. So, 用于我的1080p测试视频, 我测试了16个禁用波前同步的线程，以及一个和四个线程(没有波前)来产生
图3(下面). 这澄清了波前同步器的影响，并更准确地描述了我们的配置选项.

impact of threads/wavefront on encoding time and quality

Here are a few observations drawn from these results:

A single thread produced the best overall quality by a hair.
使用1到4个线程可以使编码速度提高近4倍, 之后急剧放缓.
A no-threads approach produced a better result than eight threads, delivering the same quality but reducing encoding time by 8.5%. 根据弗劳恩霍夫的说法, this is because not including a threads command triggers auto detection, 如果编码器检测到您的CPU有多个核心，则使用更多线程.
波前同步减少了编码时间，但也降低了两种情况下的质量.
16 threads without 波阵面同步 reduced encoding time by 25.5%，质量损失极小.

这分为两个问题:如何优化质量和生产效率. 我们先看质量.

Let’s assume that you opted for 16 threads with 波阵面同步, which drops encoding time by 33% but also overall quality by 1.低帧质量降低3%.2%. 如果你对你的视频有一个特定的质量目标, 比如93 VMAF, 为了达到这个质量目标，你必须稍微提高视频的比特率.

选择波前同步器, you’re not making a “quality” decision; you’re choosing to reduce encoding costs but increase bandwidth costs to recover the lost quality. 最好的选择直接关系到你的典型视频将被观看多少次. 如果你的视频被观看数百万次, 无论编码成本如何，都要尽可能地生成高质量的文件. If your typical view counts are in the dozens or hundreds, 降低编码成本并提高带宽以弥补这一损失，在经济上更有意义. 现在让我们看看生产效率.

选择线程16没有波前同步提供100%的质量与83.从单个核减少6%的编码时间，转换为约6%的编码时间.性能提升1倍. 这在经济上有意义吗? 你可以从 表2(下).

使用不同线程数的每小时VVC成本

表2显示了使用不同线程数生成VVC的每小时计算成本. 最根本的问题是Amazon Web Services的定价是无情的线性——四个线程的成本是单个线程的4倍, 等等....... 如果你的处理效率不高, moving to higher thread counts decreases your encoding time per hour, 但是增加了每小时的成本. That’s why a single thread produces the lowest cost per hour.

四个线程最接近线性，但是用四个线程编码将编码速度提高3个.在单个线程上使用5x. It also costs 4x more, so overall, it’s more expensive. 超过4个线程，超线程效率就会下降，这就是每小时成本急剧上升的原因. Note that this analysis isn’t unique to VVC; it’s similar for AV1 and other codecs that I’ve tested. 从纯吞吐量的角度来看, 一旦超过4或8个线程，似乎很难有效地利用额外的线程.

So, the best economic decision is to produce with a single thread, 虽然四线很近，可能会显著降低碳排放. 超过4个线程，您的生产成本就会开始显著增长.

当然, 您用于生产的配置不能控制您用于测试的配置. Given that encoding with multiple threads has an irrelevant (.02%)对整体质量的影响，我使用了16个没有波前同步的线程来测试所有预设.

选择一个预设的VVC编码

您可能知道，预设可以控制性能和质量之间的权衡. 您可以像使用大多数其他基于ffmpeg的编解码器一样使用VVC选择预设, 下图中以绿色显示:

输入.mp4 -an -vcodec vvc 期2 -preset slow -subjopt 0 - vencs -params "通过= 2:通过= 1:rcstats文件=stats _ F1 _ 4M _ slow.Json:解码refreshtype=idr" -b:v.4 m输出.Mp4 ffmpeg -i输入.mp4 -an -vcodec vvc 期2 -preset slow -subjopt 0 - vencs -params "通过= 2:pass=2:rcstats文件=stats _ F1 _ 4M _ slow.Json:解码refreshtype=idr" -b:v.4 m输出.mp4

图4(下面) 显示了五种可用的VVC编解码器的预设以及在整体质量方面的权衡(红色), 低帧质量(绿色), 编码时间(蓝色). 和以前一样，这些数字是在从0到100%的范围内，所以慢速预设提供99.总质量的27%和99.低帧质量的3%.慢速预设编码时间的38%.

quality and encoding time trade-offs of the 5 VVC presets

与线程决定一样, this isn’t really a quality decision; it’s a bandwidth cost versus encoding cost decision. Encoding with the Slow preset shaves roughly 73% from encoding time, 如果你在运行自己的编码器, 它将编码成本降低了73%. 然而, 以达到与较慢预设相同的质量, 你需要将比特率提高3.5%. As before, your expected view count will dictate your preset selection. 如果你的浏览量达到七位数以上, prioritize bandwidth costs over encoding charges; if your expected audience is in the 3–5 figures range, 最小化编码费用.

使用这些技术测试新的编解码器或编码器提供了一种结构化的方式来了解不同的选项如何影响质量和吞吐量，以及如何为您的产品选择最佳选项.

免费的

合资格订户

现在就订阅最新一期过去的问题

Will Amazon and Dolby's Latest Acquisitions Accelerate VVC Deployment?

亚马逊和杜比最近的举动可能暗示了对VVC(通用视频编码)日益增长的兴趣。.

2024年6月7日

How to Deploy GPAC for FFmpeg Packaging and ABR Distribution

就像我们喜欢用FFmpeg进行转码操作一样, it can get frustrating when packaging your content for ABR delivery. 由packag-ing, 我的意思是格式化和分割你的媒体文件, 为HLS和DASH创建清单文件, for - matting for CMAF, 并管理多个音频和字幕流. 幸运的是，有一些更容易使用的解决方案，它们同样是开源的，同样是免费的. 在本文中，我将重点介绍GPAC，它是一种很好的包装替代方案.

2024年3月18日

VVC的采用和实施状况

If you're a video publisher who doesn't rank high in the VVC patent list, it's likely that you won't consider VVC until 2026 or later. 如果你想增加H.在此之前，264使用更有效的编解码器进行编码, 你最可能的选择是HEVC和AV1, LCEVC也是一种选择. 然而, if you're a product or service provider in the streaming media ecosystem, 早该开始考虑VVC何时何地适合你和你的目标客户了.

2023年8月1日

1月时谈“VVC:准备行动?“工作坊即将在流媒体东部2023举行

即将到来的流媒体东部会议的主要会前活动之一是探讨多功能视频编解码器(VVC)的部署和实现的准备情况. 周三发表, 5月17日, 2023, from 9:00 AM to 12:00 PM at Boston's Westin Copley Place, 会议包括多位发言人, many from companies already shipping VVC-related products or services.

2023年5月2日

如何使用PowerShell和BASH为FFmpeg编写脚本

FFmpeg被设计为视频和音频录制的跨平台解决方案, 转换, 以及使用简单的静态命令行进行流式传输. 在命令字符串中使用变量和“for循环”简化了现有脚本的重用，并有助于自动化它们的操作. While you can't use these scripts in the Windows Command window, you can use Microsoft PowerShell in Windows and Bash on Linux and the Mac. 在本教程中，您将学习如何使用PowerShell和Bash创建和运行这样的脚本.

2023年3月14日