• AV1的诞生历史

AV1 编码器使用指南

AV1，目前业界最新的开源视频编码格式，用于对标隔壁MPEG小组开发的专利费昂贵的H.265。它由思科、谷歌、网飞、亚马逊、苹果、Facebook、英特尔、微软、Mozilla等组成的开放媒体联盟（Alliance for Open Media，简称AOMedia）开发。尽管最初的目标仅仅是打平HEVC，名称也是VP10，但是随着时间推移，到正式发布时，其效率已经超过了HEVC，名称也变为了AV1

根据Google官方的文件，AV1开发的着重点包括但不限于以下目标：高质量实时视频传输、对各种智能设备的兼容性、友好的计算占用、对硬件解码的优化以及对商业和非商业内容的灵活性。编解码器最初被设计为VP9的增强版，随后AOMedia的编解码、硬件开发和测试被工作组提出。到今天为止，AV1代码库已经发展到了最后的修复和优化阶段，并已经合并了各种新的压缩工具，以及为特定用例设计的高级语法和并行特性。截至这篇文章编写时，博主自己的测试结果是相同画质下（使用VMAF评估），AV1可以比HEVC减少30%以上的码率，比VP9减少50%以上的码率。

• AV1的技术细节

1）更先进的编码分块系统

现在主流的各种编码器的最大编码单位都是一个被称作“块”的东西，每个块的大小由编码器决定（单位为像素），例如H.264（AVC）编码器使用的是16*16的固定大小，HEVC使用的是8*8-64*64的不定大小的块，而AV1的前身VP9使用的是64*64的块，而AV1则直接将块的最大大小加到了128*128，如下图所示。

每个块作为编码的最大单位自然是可以分割的，分割的越细，接下来的运动补偿和帧内搜索的压缩成功率就越高，码率也就能降得越低。VP9允许 1:2 / 2:1 / 2R*2R 三种分割方式，其中 R 是一个中间单位，可以继续分割也可以不被分割。AV1在此基础上增加了 1:4 / 4:1 的分割方式，在编码器中，这被简单粗暴地称作 “14/41 partition”，此外还增加了混合的分割方式，允许将一个块分割为奇数个子块，而除了AV1之外的全部编码器都要求分割后的子块数量必须为偶数，这个分割选项理论上是可选的，但目前的编码器都默认开启，尚未制作该选项的开关。

2）更多和更好的帧内压缩方式

帧内压缩，通俗的来所就是在同一个图像内找出相似的部分，如果有，那么只需编码其中一个区块，剩下的与其相似的区块可以直接复制然后增加一小段内容告诉解码器他们的区别即可。编码器在寻找相似区块时通常由方向模式（在一定方向上寻找）和非方向模式（类似于模糊搜索）两种方式。

VP9支持10种帧内预测模式，其中8种方向模式，角度从45到207度不等；2个非方向预测模式：DC和true motion (TM)模式。而到了AV1这里，帧内编码进一步探索了不同的方法：方向预测的精度和准确性进一步升级，而非方向性的预测则纳入了色彩梯度和相关性，亮度的一致性和色度信号也在搜索中得到了充分利用，并开发出针对人造视频内容（指动漫，卡通等内容）的特殊优化工具。

3）先进的帧间预测运动补偿

帧间预测运动补偿是视频编码中必不可少的模块。在VP9中，最多允许选择3个候选参考帧中的2个作为参考，然后预测器将进行基于块平移的运动补偿，或者如果有两个参考信号则取这两次预测的平均值。AV1具有更强大的帧间编码器，可大大扩展参考帧和运动矢量的预设，它打破了基于块平移预测的局限性，并通过使用高自适应加权算法和源，增强了复合预测。

最重要的是扩展参考帧：AV1将每个帧的最大参考数从3扩展到7。除了VP9中的LAST（最近过去的）帧，GOLDEN（遥远过去的）帧和ALTREF（将来的）帧之外，AV1规范在现在正编码的帧之前添加了两个过去的帧（LAST2和LAST3）以及两个将来的帧（BWDREF和ALTREF2）。下图展示了预测帧组的多层结构，其中自适应数量的帧共享相同的GOLDEN和ALTREF帧。 BWDREF是一种直接编码的超前帧（类似于HEVC中的I帧），更适合用作相对距离较短的后向参考。 ALTREF2用作GOLDEN和ALTREF之间的中间参考值。所有参考帧都可以单个使用或被组合成复合模式使用（人话：可以套娃参考）。 AV1提供了丰富的参考帧集合，既提供了双向复合预测（类似于HEVC中的B帧）又提供了单向复合预测（类似于HEVC中的P帧），适用于对具有动态时域特性的各种视频进行更灵活和更优的方式的编码。

其次是扭曲运动补偿：对于其他编码器，如果前一帧的内容在这一帧中发生了扭曲，则传统的相似度的计算方式会使得编码器放弃使用参考帧，但AV1引入了扭曲运动补偿 ，使得预测器可以识别扭曲的目标，引导编码器正确的引用参考帧并作出变幻。（如下图所示）

• AV1的编解码器

AV1目前有三个主要的编码器分支：

1. AOM-AV1：由Google领衔的一个小组开发的官方编解码器，官方仓库地址是：aomedia.googlesource.com/aom
2. SVT-AV1：由Intel和Netflix开发的AV1编解码器，以速度快著称，官方地址：gitlab.com/AOMediaCodec/SVT-AV1
3. RAV1：由民间基于AOM修改而来的编解码器，目前尚不成熟，地址：github.com/xiph/rav1e

其中AOM-AV1的压缩表现最好，甚至可以用遥遥领先来形容，而SVT-AV1的优势则在于其极高的编码速度和CPU利用率，Rav1则不太成熟，仍在调校，表现中规中距。

目前 SVT-AV1 已经成为综合性能最好且简单易用的编码器，AOM-AV1 则因为过于注重编码效率而导致编码速度和 CPU 利用率不佳（但其实也没有落后多少），并且由于高级选项太多，调校起来比较复杂。

• AV1的性能测试

AV1相较于HEVC来说其压缩率的提高是显著的，但是随之而来的就是数倍于HEVC的编码复杂度和让人诟病的编码速度，为了有一个更直观的表现，接下来我将提供一些我自己测试的数据。

编码环境：
CPU：Intel Core i7-10700KF （Overclocked）
主频：4.8GHz
系统：Windows 11 DEV 22471.1000
AOM-AV1版本：3.1.2
SVT-AV1版本：0.8.7

首先来看AOM-AV1在一个基础的配置下的表现：

编码参数：
aomenc.exe --limit=53996 --passes=1 --quant-b-adapt=1 --cq-level=27 --good --verbose --psnr=0 --bit-depth=10 --ivf --threads=16 --lag-in-frames=35 --end-usage=q --enable-fwd-kf=1 --kf-min-dist=60 --kf-max-dist=600 --cpu-used=4 --auto-alt-ref=1 --static-thresh=0 --tile-columns=2 --tile-rows=1 --enable-tpl-model=1 --arnr-maxframes=8 --arnr-strength=4 --enable-restoration=1 --enable-ab-partitions=0 --enable-chroma-deltaq=1 --enable-qm=1 --coeff-cost-upd-freq=2 --mode-cost-upd-freq=2 --mv-cost-upd-freq=2 --aq-mode=2 --deltaq-mode=2 --frame-boost=1 --disable-warning-prompt -o videoplayback_temp\videoplayback_out.ivf -

从图中我们可以看出当前AOM-AV1最大的问题就是CPU的使用率和线程分配。可以发现，编码时CPU的使用率一直在40%上下波动，很少高负载更别说吃满了，如果进一步仔细观察我们可以发现：3号内核的占用率显著高于其他内核，这意味这AOM-AV1的负载分配不合理，出现了在一个处理步骤上（极有可能在是帧预测上）落后拖累整体编码速度。

当然，这种追求细致的编码方式让AOM的压缩率从诞生以来就一直是三个编码器中的No.1 目前与SVT-AV1打平。

接下来来看SVT-AV1的表现：

编码参数：
SvtAv1EncApp.exe --lp 16 --lookahead 300 --keyint 300 --enable-tpl-la 1 --preset 3 --scm 2 --qp 30 --tile-rows 0 --tile-columns 1 -n 53996 -i stdin -b C:\Users\HenryWu\Downloads\videoplayback_temp\videoplayback_out.ivf

SVT-AV1这边展现出了极强的多线程优化，CPU占用率一直保持在75%以上，甚至可以吃满，这大概率是因为SVT-AV1使用了一个叫做 Tile 的技术，也就是是将一帧分为多份并行处理，使得CPU不被浪费，但是这也导致了其无法使用某些帧内和帧间压缩方式，导致其在某些情况下的压缩率可能不如AOM好，在最新版本中已经打平甚至已经超越AOM，但是频繁的在多个线程间传递数据导致其内存占用十分夸张，在相同的Lookahead和GOP-Size设置下SVT要比AOM平均多用3-4倍的内存。

• 与HEVC的对比

在 AreWeCompressedYet 网站上，我找到了AOM-AV1 Preset4 、SVT-AV1 Preset 4 、HEVC Preset Slow 这三个常用的编码预设的VMAF评分数据，将他们绘制成表格后得到了如下的结果

图片中的红线为HEVC，蓝线为AOM-AV1，绿线为SVT-AV1，横轴为视频码率。可以看到两个AV1编码在码率极高时与HEVC差距不大，但随着码率降低，二差距越拉越大。AOM-AV1与SVT-AV1的差距几乎没有。

由于AV1与HEVC不是一个时代的编码器，所以我在此不过多的作比较，下面来比较两款主流编码器的性能。

• SVT-AV1与AOM-AV1的性能测试：

评估时使用的工具叫做VMAF，是一个由 Netflix 开发的基于机器视觉的画质评判工具，其目的是尽可能模拟人眼对画面的评价模式从而优化编码设计。

VMAF将给定的两个文件（一个源文件，另一个是压缩后的文件）进行分析，取得一个相对分数（0-100）用以表示两者的相似程度，得分越高失真越小。

需要注意的是，由于SVT-AV1和VMAF的开发均有 Netflix 的参与，故此不能确定SVT-AV1是否专门对VMAF有优化，而且VMAF是偏向主观的画质评判，不同于传统的客观绝对评分，对于部分视频可能分数不合理，因此仅供参考，编码生成的文件和源文件都提供了下载链接，您可以下载后自行运行其他测试。

这里我使用了三个不同的视频进行测试。编码使用的Preset均为3（个人能够接受的最慢速度），lookahead=帧率*5

• 视频1

这个视频的画面中包含大量的细节且过场动画较多。

原视频：

下载地址：点这里

#视频下载自YouTube

编码格式：VP09
平均码率：22786Kbps
分辨率：3840*2160P
颜色格式：YUV420-8bit

SVT-AV1编码参数：

SvtAv1EncApp.exe --lp 16 --lookahead 300 --keyint 300 --enable-tpl-la 1 --preset 3 --scm 2 --qp 32 --aq-mode 2 -n 2400 -i stdin -b C:\Users\videoplayback_temp\SVT-Q32.ivf

AOM-AV1编码参数：

aomenc.exe --limit=2400 --passes=1 --quant-b-adapt=1 --cq-level=26 --good --verbose --psnr=0 --bit-depth=8 --ivf --threads=16 --lag-in-frames=35 --end-usage=q --enable-fwd-kf=1 --kf-min-dist=60 --kf-max-dist=600 --cpu-used=4 --auto-alt-ref=1 --static-thresh=0 --tile-columns=2 --tile-rows=1 --enable-tpl-model=1 --enable-restoration=1 --enable-ab-partitions=0 --enable-chroma-deltaq=1 --enable-qm=1 --coeff-cost-upd-freq=2 --mode-cost-upd-freq=2 --mv-cost-upd-freq=2 --aq-mode=2 --deltaq-mode=2 --frame-boost=1 --disable-warning-prompt -o AOM-Q26.ivf -

SVT-AV1编码结果：

下载地址：点这里

VMAF="97.6737"
编码速度：0.68FPS
编码时平均内存占用：5461MB

AOM-AV1编码结果：

下载地址：点这里

VMAF="97.3479"
编码速度：42FPM（0.71FPS）
编码时平均内存占用：2355MB

• 视频2

这个视频的画面动作较为平缓但是一直在移动中，细节量中等。

原视频：

下载地址：点这里

#本视频下载自YouTube

视频编码；VP09
平均码率：25750Kbps
分辨率：3840*2160P
颜色格式：YUV420-8bit

SVT-AV1编码参数

SvtAv1EncApp.exe --lp 16 --lookahead 180 --keyint 180 --enable-tpl-la 1 --preset 3 --scm 2 --qp 32 --aq-mode 2 -n 4800 -i stdin -b C:\Users\videoplayback_temp\SVT-Q32.ivf

AOM-AV1编码参数

aomenc.exe --limit=4800 --passes=2 --quant-b-adapt=1 --cq-level=26 --good --verbose --psnr=0 --bit-depth=8 --ivf --threads=16 --lag-in-frames=35 --end-usage=q --enable-fwd-kf=1 --kf-min-dist=60 --kf-max-dist=600 --cpu-used=3 --auto-alt-ref=1 --static-thresh=0 --tile-columns=2 --tile-rows=1 --enable-tpl-model=1 --enable-restoration=1 --enable-ab-partitions=0 --enable-chroma-deltaq=1 --enable-qm=1 --coeff-cost-upd-freq=2 --mode-cost-upd-freq=2 --mv-cost-upd-freq=2 --aq-mode=2 --deltaq-mode=2 --frame-boost=1 --disable-warning-prompt -o AOM-Q26.ivf -

SVT-AV1编码结果：

下载地址：点这里

VMAF="99.1005"
平均帧率：0.61Fps
平均码率：14662Kbps
编码时内存占用：4976MB

AOM-AV1编码结果

下载地址：点这里

VMAF="98.9973"
平均帧率：37fpm（0.64fps）
平均码率：15865Kbps
编码时平均内存占用：2161MB

• 视频3

这段视频来自电视剧《奥威尔号》第二季第九集，画面动作较为激烈但细节较少（大部分画面为特效）

原视频：

下载地址：点这里

视频编码：AVC(X264)
平均码率：11440Kbps
分辨率：1920*1080P
颜色格式：YUV420-8bit

SVT-AV1编码参数

SvtAv1EncApp.exe --lp 16 --lookahead 120 --keyint 120 --enable-tpl-la 1 --preset 3 --scm 2 --qp 32 --aq-mode 2 -n 4800 -i stdin -b C:\Users\videoplayback_temp\SVT-Q32.ivf

AOM-AV1编码参数

aomenc.exe --limit=4800 --passes=2 --quant-b-adapt=1 --cq-level=26 --good --verbose --psnr=0 --bit-depth=8 --ivf --threads=16 --lag-in-frames=35 --end-usage=q --enable-fwd-kf=1 --kf-min-dist=24 --kf-max-dist=120 --cpu-used=3 --auto-alt-ref=1 --static-thresh=0 --tile-columns=2 --tile-rows=1 --enable-tpl-model=1 --enable-restoration=1 --enable-ab-partitions=0 --enable-chroma-deltaq=1 --enable-qm=1 --coeff-cost-upd-freq=2 --mode-cost-upd-freq=2 --mv-cost-upd-freq=2 --aq-mode=2 --deltaq-mode=2 --frame-boost=1 --disable-warning-prompt -o AOM-Q26.ivf -

SVT-AV1编码结果

下载地址：点这里

VMAF="97.9556"
编码速度：1.60Fps
平均输出码率：2997Kbps
编码时平均内存占用：3217MB

AOM-AV1编码结果

下载地址：点这里

VMAF="97.9524"
编码速度：1.08Fps
平均输出码率：3214Kbps
编码时平均内存占用：1204MB

• AV1编码器的发展展望

AV1可以说是一个很不错的编码规范，许多厂商也都开始了对AV1的探索和支持，Youtube已经把720P一下和部分1080P视频切换至AV1编码，Netflix似乎也展现出了对AV1的很大兴趣。在硬件上，N厂最新的显卡已经支持了最高8K的AV1硬解，手机上的天玑1000系列处理器也支持了最高4K/30Fps的AV1硬解，厂商的支持也从侧面体现了AV1编码的成功，虽然现在AV1的高压缩率下编码速度依旧不尽人意，但是这个问题在越来越强的处理器算力下也不会持续很久，可以说AV1以其优秀的设计和免专利费的使用很有可能接替AVC成为下一个编码器霸主。

不过未来究竟会是什么样，谁也不好说，还是让我们拭目以待吧。

在这个系列的下一篇文章中，我会根据我使用AV1编码的经验给出一些使用建议~

未完待续……