透过 Top 500 美拍短视频看 AV1 性能

2019-07-01 15:53:37 浏览数 (1)

本文来自美图编解码技术团队的投稿，详细陈述了AV1在美拍短视频热门视频序列上的表现，AV1 与x265 main profile相比在同质量下大约可以节省 27% 的码率；编码耗时方面AV1 是x265 main profile 的 36.5 倍。

文 / 美图编解码技术团队

导语

AV1 以其出色的压缩性能，无疑是自 2017 年以来备受关注的新生代视频编码标准。业界也相继对 AV1 进行了一些评测工作，如 Facebook、Netflix 对它的编码复杂度也从早期的 VP9 的近千倍降到了百倍。为了验证 AV1 在短视频上的性能，美图音视频团队自 2018 年 11 月，基于 Top 500 美拍短视频进行了一次全面的 AV1 性能评估，对标编码器采用在实际生成环境中使用的主流视频编码器 x264、x265、VP9。

本文将详细介绍整个评估过程，结合实验数据，综合评价 AV1 在短视频上的性能表现。

AV1 在实验中的表现

在对本文进行阐述前，我们先来看看 AV1 的综合表现，评估结果表明，AV1 的压缩效率优势明显，但是编码耗时仍相对较长：

  • 相比于 x264 high profile、x265 main profile 及 VP9 ，AV1 在相同质量下分别能获得 36.0%、26.9%、31.8% 的码率增益。并且，随着视频分辨率的增加，AV1 的码率增益优势更加明显；
  • 在编码耗时上，AV1 分别是 x264 high profile 的 395 倍、x265 main profile 的 36 倍、VP9 的 156 倍。

研究背景

AV1（全称，AOMedia Video 1）无疑是自 2017 年以来备受关注的新生代视频编码标准，原因在于它的高压缩性能。经业界测试数据表明，如莫斯科国立大学（MSU）、Facebook、Netflix 均进行了相关实验，都证实了 AV1 已超越 H.265 和 VP9，成为目前压缩率最高的视频编码标准。然而，它的高复杂度也曾令人震惊，数据表明 2018 年初，相比于 VP9 编码器点播速度档，AOM/libaom[1]的编码时长是 VP9 编码时长近一千倍。近两年来，无论是 AV1 的标准制定团队 AOM，还是其他厂商，如 Intel，都致力于优化 AV1 的速度性能，近日，有相关数据表明 AV1 已接近使用水平[2]。

在软硬件的支持性方面，越来越多的软件或平台开始支持 AV1 视频播放，如 Mozilla 的 Firefox 浏览器，Chromium 浏览器内核，微软Windows 10 平台，以及 Android Q 系统；谷歌、英特尔、ARM、高通、三星、索尼等头部硬件厂商也纷纷加入到硬件解码器的研发队列中，可以预见移动端 AV1 硬解支持将在 2020 年迅速普及[3]。

针对 AV1 进行全面的编码性能评估实验

在 AV1 的浪潮来临之际，我们针对美拍 Top 500 及头部达人的视频，采用 2018 年 v1.0.0 版本 libaom 对 AV1 的压缩效率及编码复杂度进行了一次全面的编码性能评估实验。实验对标的编码器选用在实际生成环境中使用的主流视频编码器 x264、x265、VP9，质量评价指标采用 PSNR、SSIM 及 VMAF-Phone 模型。

视频测试序列的选择

测试序列取自美拍 Top 500 及来自头部达人的热门、优质视频，实际参与评估实验的视频有 523 个，这些视频具有以下特点：

  • 大部分是手机拍摄的视频，包括照片视频、手机录屏的视频、官方制作发布的视频；
  • 压缩后的视频；
  • 大部分是 SD/HD(480p/540p/720p)，而不是官方测试机构常用的 UHD/4K、8K；
  • 大部分视频帧率都是 30 fps；
  • 大部分视频宽幅比都是 16:9；
  • 大部分视频处于 10s～60s 之间。

视频测试序列的复杂度分析

一个编码器的压缩效率与视频内容息息相关，因此在进行编码器评估工作之前，我们先对每个视频进行了复杂度分析。依据 ITU-T 主观质量评价标准《ITU-T P.910》[4]所描述的方法，我们通过对每个视频计算最大空间复杂度信息 (SI) 、最大时间复杂度信息 (TI) 来描述测试序列的复杂度。由于某些视频中存在大量场景切换，因此我们还计算了平均 SI、TI 来综合衡量序列复杂度。

图1、图2 分别展示了 Top 500 美拍视频（前 6s）的 SI-TI 分布情况。结果表明，我们的大部分视频处于40≤SI≤90,TI≤40，对应于 ITU-T 主观质量评价标准《ITU-T P.910》中的 A（One person, mainly head and shoulders, limited detail and motion）、B（One person with graphics and/or more detail）、C类（More than one person），该数据结果与美拍的业务场景也十分契合。

图 1 Top 500 美拍视频 SI-TI(max) 散点分布图

图 2 Top 500 美拍视频 SI-TI (average) 散点分布图

编码器的选择

对于 AV1，我们采用 AOM AV1 提供的参考软件（AOM/libaom）；对于 H.264/AVC、H.265/HEVC、VP9，我们采用 ffmpeg 4.0.2 对应的编码库。表1 列出了实验中使用的编码器版本。

候选编码器

实现版本

x264

ffmpeg 4.0.2-libx264（最新的commit 303c484ec828ed0d8bfe743500e70314d026c3bd）

x265

ffmpeg 4.0.2-libx265（最新版release 2.8）

VP9

ffmpeg 4.0.2-libvpx（tag 1.7.0）

AV1

aom源码（commit d14c5bb4f336ef1842046089849dee4a301fbbf0 v1.0.0）

表 1 实验中采用的编码器版本

编码参数的配置

我们分别基于 CRF、ABR 两种码率控制配置下对编码器性能进行评估。不同编码器的 CRF 配置见表2，我们取 6 个 CRF 值进行多组编码，并将 CRF 编码后得到的码率作为 2-pass ABR 编码的目标码率。

编码器

CRF配置

X264/X265

19,23,27,31,35,39

VP9/AV1

27,33,39,45,51,57

表 2 CRF 配置

具体每个编码器的配置方案如表 3 所示。

编码器

CRF/QP

ABR（pass-1）

ABR(pass-2)

x264-high

ffmpeg -i <INPUT> -c:v libx264 -pix_fmt yuv420p -profile:v high -preset veryslow -crf <CRF> -threads 1 -refs 4 -g 60 -keyint_min 60 -sc_threshold 0 -an -f mp4 <OUTPUT>

ffmpeg -i <INPUT> -c:v libx264 -pix_fmt yuv420p -profile:v high -preset veryslow -b:v <BITRATE> -threads 1 -refs 4 -g 60 -keyint_min 60 -sc_threshold 0 -pass 1 -an -f null -

ffmpeg -i <INPUT> -c:v libx264 -pix_fmt yuv420p -profile:v high -preset veryslow -b:v <BITRATE> -threads 1 -refs 4 -g 60 -keyint_min 60 -sc_threshold 0 -pass 2 -an -f mp4 <OUTPUT>

x265-main

ffmpeg -i <INPUT> -c:v libx265 -pix_fmt yuv420p -profile:v main -preset veryslow -crf <CRF> -x265-params pools=none:frame-threads=1:scenecut=0:keyint=60:min-keyint=60:ref=4 -an -f mp4 <OUTPUT>

ffmpeg -i <INPUT> -c:v libx265 -pix_fmt yuv420p -profile:v main -preset veryslow -b:v <BITRATE> -x265-params pools=none:frame-threads=1:scenecut=0:keyint=60:min-keyint=60:ref=4 -pass 1 -an -f null -

ffmpeg -i <INPUT> -c:v libx265 -pix_fmt yuv420p -profile:v main -preset veryslow -b:v <BITRATE> -x265-params pools=none:frame-threads=1:scenecut=0:keyint=60:min-keyint=60:ref=4 -pass 2 -an -f mp4 <OUTPUT>

VP9

ffmpeg -i <INPUT> -c:v libvpx-vp9 -pix_fmt yuv420p -crf <CRF> -b:v 0 -speed 1 -tile-columns 0 -frame-parallel 0 -auto-alt-ref 1 -lag-in-frames 25 -g 60 -keyint_min 60 -an -f webm <OUTPUT>

ffmpeg -i <INPUT> -c:v libvpx-vp9 -pix_fmt yuv420p -speed 1 -b:v <BITRATE> -tile-columns 0 -frame-parallel 0 -auto-alt-ref 1 -lag-in-frames 25 -g 60 -keyint_min 60 -pass 1 -an -f null -

ffmpeg -i <INPUT> -c:v libvpx-vp9 -pix_fmt yuv420p -speed 1 -b:v <BITRATE> -tile-columns 0 -frame-parallel 0 -auto-alt-ref 1 -lag-in-frames 25 -g 60 -keyint_min 60 -pass 2 -an -f webm <OUTPUT>

AV1

aomenc --i420 --codec=av1 --cpu-used=1 --width=<WIDTH> --height=<HEIGHT> --threads=0 --profile=0 --lag-in-frames=19 --auto-alt-ref=1 --min-q=0 --max-q=63 --kf-max-dist=60 --kf-min-dist=60 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --sharpness=0 --undershoot-pct=100 --overshoot-pct=100 --tile-columns=0 --frame-parallel=0 --test-decode=warn -v --end-usage=q --cq-level=<CRF> --target-bitrate=0 --fps <fps> --webm -o <OUTPUT.webm> <INPUT>

aomenc --i420 --codec=av1 --cpu-used=1 --width=<WIDTH> --height=<HEIGHT> --threads=0 --profile=0 --lag-in-frames=19 --auto-alt-ref=1 --min-q=0 --max-q=63 --kf-max-dist=60 --passes=2 --pass=1 --fpf="av1_pass2.log" --kf-min-dist=60 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --sharpness=0 --undershoot-pct=100 --overshoot-pct=100 --tile-columns=0 --frame-parallel=0 --test-decode=warn -v --end-usage=vbr --target-bitrate=<BITRATE> --fps <fps> --webm -o null <INPUT>

aomenc --i420 --codec=av1 --cpu-used=1 --width=<WIDTH> --height=<HEIGHT> --threads=0 --profile=0 --lag-in-frames=19 --auto-alt-ref=1 --min-q=0 --max-q=63 --kf-max-dist=60 --passes=2 --pass=2 --fpf="av1_pass2.log" --kf-min-dist=60 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --sharpness=0 --undershoot-pct=100 --overshoot-pct=100 --tile-columns=0 --frame-parallel=0 --test-decode=warn -v --end-usage=vbr --target-bitrate=<BITRATE> --fps <fps> --webm -o <OUTPUT.webm> <INPUT>

表 3 编码器详细配置

评估结果

我们采用 BD-Rate 来衡量各个编码器的压缩效率，复杂度性能则采用编码时长之间的倍数关系来描述。BD-Rate 是通过对比率失真曲线，计算相同质量下平均的码率差异来衡量两种编码方案的 RD 性能优劣。在评估结果的描述上，我们将从 AV1 的角度出发，计算 AV1相对于其他编码方案的 BD-Rate 性能。其中，失真的计算维度采用 PSNR、SSIM，另外，针对 1080p 的序列会加入 VMAF-Phone 模型的评价结果。同样，在对比复杂度性能时，我们也会计算 AV1 相对于其他编码方案的编码时间的倍数。以下是具体在 CRF/QP、ABR上的结果。

值得注意的是，短视频由于其 UGC 居多的特性，其视频源和近年来被广泛使用的 VMAF AI 模型使用的 Netflix 视频源训练集差异较大，因此原生 VMAF 模型并不能很好地评价短视频内容的画质。

CRF/QP 的结果

图3、图4 是 CRF/QP 码率控制方式下，分别以 PSNR、SSIM 为质量评价指标展现的 AV1 相比于 x264 high profile、x265 main profile、libvpx-vp9 在相同质量下节省的码率。

从 PSNR 的维度来看，AV1 的 BD-Rate 相比于前述的三种编码器分别平均节省了 35.88%，26.17%，36%。并且，从分辨率维度来看，随着分辨率的增加，AV1 的码率增益越大。对比 x264 high profile、x265 main profile 和 VP9，我们可以发现 x265 main 的压缩效率在各分辨率下都要优于 x264 high profile 和 VP9，在低分辨率下x264 high profile 的压缩效率略优于 VP9，在大分辨率下 VP9 的压缩效率逐渐逼近 x265 main profile。

从 SSIM 的维度来看，AV1 的 BD-Rate 分别节省了 35.33%，22.24%，68.52%。需要说明的是，其中 libvpx-vp9 以 SSIM 维度计算的 BD-Rate 并不具有准确的物理意义，因为相比于 AV1，两条 RD 曲线近乎平行（如图6～图9所示），所以无法准确找到同一质量的两个码率点进行比较。可以说 BD-Rate 不适用于展现以 SSIM 维度来衡量的 RD 性能，应该加上 BD-PSNR 的统计指标加以验证。图6～图9 是各个分辨率下随机抽取的一个序列的 RD 曲线。RD 曲线越高，说明率失真性能越好。可以发现在 SSIM 衡量指标下，RD 性能的变化趋势与 BD-Rate 结果一致，有：AV1 > x265 main profile > x264 high profile > VP9。

同理，BD-Rate 也不适用于展现以 VMAF-Phone 模型来衡量的 RD 性能，图10 是取自 1080p 下某个视频序列的 RD 曲线。不难发现，在 VMAF-Phone 画质损伤衡量指标下，难以很好地区分 x264 high profile、x265 main profile 与 AV1 的孰优孰劣, 而 VP9 的 RD 性能明显差于其他编码器。

从编码复杂度上，如 图5 所示，AV1 相比于 x264 high profile、x265 main profile、libvpx-vp9 的编码时间分别为 370.89 倍、44.34 倍、168.88 倍。同时，我们发现在大分辨率视频上， VP9 在 RD 性能接近 x265 main profile 的情况下，编码时长降到 x265 main profile 约五分之一。

图 3 AV1 相对于 x264 high profile、x265 main profile、libvpx-vp9 的 BD-Rate 节省比例（质量标准：PSNR 码控方式：CRF/QP）

图 4 AV1 相对于 x264 high profile、x265 main profile、libvpx-vp9 的 BD-Rate 节省比例（质量标准：SSIM 码控方式：CRF/QP）

图 5 AV1 相对于 x264 high profile、x265 main profile、libvpx-vp9 增加的编码耗时倍数（码控方式：CRF/QP）

图 6 360p 示例视频 RD 曲线（质量标准：SSIM 码控方式：CRF/QP）

图 7 540p 示例视频 RD 曲线（质量标准：SSIM 码控方式：CRF/QP）

图 8 720p 示例视频 RD 曲线（质量标准：SSIM 码控方式：CRF/QP）

图 9 1080p 示例视频 RD 曲线（质量标准：SSIM 码控方式：CRF/QP）

图 10 1080p 示例视频 RD 曲线（质量标准：VMAF-Phone model 码控方式：CRF/QP）

ABR 的结果

图11、图12 是 ABR 码率控制方式下，分别以 PSNR、SSIM 为质量评价指标展现的 AV1 相比于 x264 high profile、x265 main profile、libvpx-vp9 在相同质量下节省的码率。

从 PSNR 的维度来看，AV1 的性能与 CRF/QP 的结果类似，BD-Rate 相比于前述的三种编码器分别平均节省了 36.21%，27.64%，27.69%，且 RD 性能的增益优势也随分辨率增加而增加。与在 CRF/QP 下不同的是，VP9 的压缩性能在 ABR 下远优于 x264 high profile，与 x265 main profile 不相上下，在高分辨率下甚至超越了x265 main profile。

从 SSIM 的维度来看，AV1 的 BD-Rate 分别节省了 32.96%，21.59%，62.35%。同样地，图14 ~ 图17 给出了四个分辨率下示例视频序列的 RD 曲线来直观比较各个编码器的 RD 性能。类似于 CRF/QP 的结果，RD 曲线的排序结果与 BD-Rate 排序结果一致，有：AV1 > x265 main profile > x264 high profile > VP9。

同样，在以 VMAF-Phone 来衡量画质时，AV1 与 x264 high profile、x265 main profile 的 RD 性能非常接近，VP9 依然处于劣势，如图18 所示。

从编码复杂度上（如图13 ），AV1 相比于 x264 high profile、x265 main profile、libvpx-vp9 的编码时间分别为 420.50 倍，28.69 倍，143.53 倍。

图 11 AV1 相对于 x264 high profile、x265 main profile、libvpx-vp9 的 BD-Rate 节省比例（质量标准：PSNR 码控方式：ABR）

图 12 AV1 相对于 x264 high profile、x265 main profile、libvpx-vp9 的 BD-Rate 节省比例（质量标准：SSIM 码控方式：ABR）

图 13 AV1 相对于 x264 high profile、x265 main profile、libvpx-vp9 增加的编码耗时倍数（码控方式：ABR）

图 14 360p 示例视频 RD 曲线（质量标准：SSIM 码控方式：ABR）

图 15 540p 示例视频 RD 曲线（质量标准：SSIM 码控方式：ABR）

图 16 720p 示例视频 RD 曲线（质量标准：SSIM 码控方式：ABR）

图 17 1080p 示例视频 RD 曲线（质量标准：SSIM 码控方式：ABR）

图 18 1080p 示例视频 RD 曲线（质量标准：VMAF-Phone model 码控方式：ABR）

结论

从 AV1 在短视频上的评估结果来看，我们可以得到与 Facebook[5]类似的一些结论，比如 AV1 相比于 VP9、x264 high profile 在相同质量下可以节省 30% ～ 40% 的码率。同时我们还得到了 AV1 相对于 x265 main profile 的表现：在相同质量下大约可以节省 27% 的码率。而在编码耗时上，AV1 的速度进步明显，相比于 Facebook 在 v0.1.0 AV1 上的结果：5869.9x（ AV1 vs x264 high profile ）、658.5x（ AV1 vs VP9），v1.0.0 版本的 AV1 是 x264 high profile 的 395.7 倍、VP9 的 156.2 倍、x265 main profile 的 36.5 倍。

除此之外，我们还发现了 VP9 在短视频上的一些特性。首先，VP9 在通过 SSIM 及 VMAF 评价时表现较差。其次，VP9 在 ABR 下相对于 CRF 有更好的表现，其压缩性能与 x265 main profile 接近，但编码速度却比后者快了 5 倍。

另外，对编码器评估工作有如下几点启示：

  • 在质量评价工具的选择上，原生 VMAF-Phone 模型并不能很好地区分各个编码器在短视频场景下的画质。
  • RD 性能统计指标的选择上，一种更为准确的方式是结合 BD-Rate、BD-PSNR 共同来衡量。

相信以上结论会引发音视频领域工程师的一些思考，并推进 AV1 在各自生产线中的使用。

未来规划

美图会持续跟进 AV1 在移动端和主流浏览器上的解码支持的成熟度，针对核心用户的视频内容率先应用 AV1 编码，降低用户观看高分辨率视频内容的时间成本，并给用户带来更好的画质体验。毕竟用户在观看 AV1 视频时，在相同码率下，将获得相比 x264、x265 及 VP9 更高的画质，或者相同质量下降低 30%～40% 的下载时长。另外，我们的编码器评估工作尚未停止，结合 Intel 近年来相继开源的 SVT-HEVC、SVT-AV1 编码器，我们会在后续的工作中加入对 SVT 系列编码器的评估。

参考内容

  • AOM/libaom：由以谷歌为主要贡献者的 AOM 会员联合打造，是目前 AV1 工具实现最完整的一款开源软件编解码器，包括编码器 aomenc 和解码器 aomdec。
  • https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Good-News-AV1-Encoding-Times-Drop-to-Near-Reasonable-Levels-130284.aspx
  • http://m.danbo-tech.com/6177789/20190322A07OMR00.html
  • https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-P.910-200804-I!!PDF-E&type=items
  • https://code.fb.com/video-engineering/av1-beats-x264-and-libvpx-vp9-in-practical-use-case/
视频处理 视频分析

0 人点赞