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

本文来自美图编解码技术团队的投稿,详细陈述了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/

原文发布于微信公众号 - LiveVideoStack(livevideostack)

原文发表时间:2019-04-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券