2018年8月31日
By 1月时特约编辑
专题文章

AV1:第一眼

ffmpeg4的发布.0给了许多压缩师第一次测试新的AV1编解码器的机会, 实验形式中包含哪些内容. 您第一次拥有了一个可以产生所有相关编解码器的编码器:H.使用x264编解码器, HEVC与x265编解码器, VP9使用谷歌Libvpx-vp9编解码器, 和AV1使用LibAOM编解码器.

因为我在更新我的书， 学习制作视频与FFmpeg在30分钟或更少，用于FFmpeg版本4.0，我决定深入研究AV1编码参数. 在为这本书的一个5秒钟的剪辑上运行一些有竞争力的编码后, 我提议对流媒体进行扩展测试.

我原本想用4个5秒的剪辑来测试. 有一次我得知我的编辑要去度假, 我决定把它增加到四个30秒的片段. 我的测试片段和程序存在一些缺陷，导致第二轮使用了两个30秒的片段.

如果有额外的时间, 我向谷歌征求了AV1和VP9编码和MulticoreWare的意见, x265的开发者, 对于x265编码. 所有输入都包含在如下所示的编码参数中. 提供输入后, 一位来自MulticoreWare的代表补充道, “我认为，不管任何质量指标(PSNR/SSIM/VMAF)，在一个商用编码器和其他参考编码器之间进行比较是不公平的。. 问题是为什么要比较x265和x265. AV1 / VP9，为什么不是HM vs. AV1 / VP9. 在后一种情况下，它将是HEVC和AV1 / VP9之间的真实比较.”

HM是HEVC参考编码器. 根据我的经验, 参考编码器编码与所有参数设置的最高质量, 在不考虑编码速度的情况下，展示了该技术的全部质量. 这并没有准确地描述我的AV1编码参数.

而, 用AOM编码器, 使用-cpu-used开关设置编码速度/质量权衡, 哪个在-8到+8之间, 用更低的值交付更高的质量(http://trac).ffmpeg.org/wiki/Encode/AV1). 正如您将在下面的编码脚本中看到的那样, 第一关, 我们将其设置为最低质量(+8)，并将其返回到第二阶段的中档(0). 因此，我们实际上使用了编码的中档设置，而不是全质量设置.

我要求谷歌对MulticoreWare的评论发表评论，但尚未得到回复. 在我看来, 使用相同的编码器测试所有编解码器似乎是合理的，但希望分享MulticoreWare的关注点.

博士TL;

对于那些有博士TL;倾向的人，这里是net/net. 尽管AV1的质量令人印象深刻, 除了视频点播金字塔的顶端，编码时间对所有人来说都太长了. 如果你的视频没有被观看数百万次，AV1编码是负担不起的.

回放测试有点令人沮丧, 虽然这可以通过提高AV1解码器利用多核的能力来修复. 如果这不可能, 这可能意味着在硬件播放支持可用之前，部署AV1是不切实际的, 这意味着大多数移动设备将迎来2020年.

我们的测试

I initially tested with four video-only 30-second test clips; one from the movie 厄勒克特拉，另一个来自足球测试剪辑谐波的网站，这是Netflix测试片段的摘录 子午线以及乡村歌手乔赛亚·韦弗(Josiah Weaver)演唱《百家乐软件app最新版下载》(免费的dom)这首歌的音乐会视频.”

编码

我用FFmpeg版本编码了所有测试剪辑FFmpeg -20180728-eb94ec3-win64-static. 我保持了基本的编码脚本. 我把我提出的脚本发送给MulticoreWare，让他们审核, 他们建议“x265的默认AQ模式是1. 在与其他编解码器进行比较时，我们应该启用AQ模式2(启用——tune-ssim). 就PSNR和SSIM而言，aq模式1和模式2之间存在巨大差异.” So, 我调优了SSIM并使用了Veryslow预设, 在我的测试中，它的质量一直比安慰剂好.

输入.Mp4 -c:v libx265 -preset veryslow -tune sim -x265-params比特率= 6000:vbv-maxrate = 12000 -pass 1 -f mp4 NUL & \

输入.Mp4 -c:v libx265 -preset veryslow -tune sim -x265-params比特率= 6000:vbv-maxrate = 12000 -pass 2 output_HEVC.mp4

我对H也是这么想的.264，使用这个脚本:

输入.mp4 -c:v libx264 -preset verslow -tune ssim -b:v 6000K -maxrate 12000K -pass 1 -f mp4 NUL & \

输入.mp4 -c:v libx264 -preset veryslow -tune sim -b:v 6000K -maxrate 12000K -pass 2 output_H264 . mp4.mp4

在Google运行VP9后，我使用了以下脚本.

输入.mp4 -c:v libvpx-vp9 -pass 1 -b:v 6000K -threads 8 -speed 4 - tilecolumns 4 -auto-alt-ref 1 -lag-in-frames 25 -frame-parallel 1 -f webm NUL && \

输入.mp4 -c:v libvpx-vp9 -pass 2 -b:v 6000K -minrate 6000K -maxrate 12000K -thread 8 -speed 0 -tile-columns 4 -auto-alt-ref 1 -lag-in-frames 25 -frame-parallel 1 output_VP9.webm

在Google上运行AV1之后，我又用了这个脚本.

输入.Mp4 -c:v libbaum -av1 -strict -2 -b:v 6000K -maxrate 12000K -cpu-used -pass 1 -f matroska NUL & \

输入.Mp4 -c:v libbaum -av1 -strict -2 -b:v 6000K -maxrate 12000K -cpu-used 0 -pass 2 output_AV1.mkv

我以5种数据速率对每个片段进行编码，包括2Mbps到6Mbps.

正如前面提到的, 当我开始审查的时候, 我打算使用五秒钟的片段，并且已经执行了编码. 当我切换到30秒的剪辑, 我提取了新的源剪辑，并在批处理文件中交换了它们. 我为在单独的Command窗口中运行的所有20个AV1测试文件创建了单独的FFmpeg脚本, 在我的40核HP Z840工作站上，我花了12天零5个小时完成了编码. 所有20个编码都在运行, CPU利用率约为45%, 虽然这下降了较低的数据速率编码完成.

同时对HEVC进行编码和分析, VP9, 和H264夹子, 我突然意识到，虽然在一个5秒的片段中只使用一个i帧是合理的, 也许我应该把30秒的片段切换成2秒的I帧间隔. 我在第二轮中也是这么做的，但这些编码的默认关键帧间隔是250帧.

编码速度

测试编码和解码速度, 我想使用单cpu计算机，而不是40核工作站. 因此，我在一台HP ZBook笔记本电脑上测试了编码/解码性能.8 GHz英特尔至强E3-1505M v5 CPU，配备NVIDIA Quadro M1000M图形芯片组，并在CPU中嵌入HD graphics 530 GPU (图1). 为了进行编码测试，我编码了一段五秒钟的《百家乐软件》节选.

Ozer AV1图1

图1. 以下是用于编码和解码试验的单CPU测试机的规格.

表1 介绍以秒为单位的编码时间，以及编码与实时性能的关系. 对于这些测试, 我使用版本ffmpeg-20180716-8aa6d9a-win64-static进行编码，因为我用于编码的更新版本在笔记本上不起作用.

AV1编码耗时62小时48分钟，比实际时间长45216倍. 相比之下，HEVC和VP9的实时时间分别不到5分钟，为58倍和45倍. 谷歌表示，在后来的版本中，编码速度有所下降, 但很明显，它还有很长的路要走.

表1. 各自技术的编码时间.

我不想赘述这一点，但编码时间转化为编码成本. 例如, 如果你在云端运行你的编码场, 你编码AV1的花费大约是HEVC的800倍. 很明显, 只有当比特率的节省非常可观，并且扩展到数百万次观看时，您才能收回这一成本.

第一轮

我测量了VMAF质量莫斯科大学视频质量测量工具. 四个片段的VMAF总平均分数显示在图2. 如你所见, AV1显然处于领先地位, H264明显的落后者, x265和VP9在中间不分上下. 没什么好奇怪的.

图2. 平均VMAF分数为我们的4个测试剪辑.

从结果来看，分数的范围令人失望. 一般来说，VMAF得分为93分预示着一个没有视觉干扰的剪辑平均而言，除了H.264在2Mbps时的平均值接近这个数字，并且在所有更高的数据速率下很容易超过它. 我希望看到HEVC和VP9在70年代和80年代的分数.

图3 呈现的结果，从足球剪辑，这是最具挑战性的四个. 这里，AV1在2左右越过了93 VMAF阈值.5 mbps, HEVC交叉约为2.7mbps, VP9在3左右.5 Mbps，而H264大约是4.05年Mbps. 这意味着AV1在提供相同质量的同时，将HEVC的数据速率降低了大约24%, 33%来自VP9, 49%来自H264. 我们一会再回到这些数字.

如图3所示