文 / 常谦浏览器

原文连接 / https://blog.hotstar.com/vp9-...网络

图片源于Unsplash上Tim Mosholder拍摄多线程

两年前，咱们开始在点播内容中使用VP9编码，而且观察到它在视频质量和码率这两方面比H264有明显的提高。但与此同时，咱们也遇到了一些挑战，今天在这里跟你们讨论一下。性能

探索

咱们使用的VP9编码器是libvpx。在新的编码服务上线一段时间后，咱们发现经过添加一些特征保留过滤器，视频主观质量变化不大却能编压缩得更小一些，。让咱们在分发一些流行节目分发中时明显地节省带宽成本。学习

咱们还发现，一些VP9编码的内容在某些具备高动态场景和黑暗场景的内容上效果不尽如人意，所以咱们决定暂停这类内容的VP9编码。而后咱们发如今某些内容的mpd文件中，240p分辨率的峰值码率高于360p分辨率。因为上述问题，咱们暂停了VP9编码，并更深刻地进行了分析和调查。最后，咱们提出了VP9编码的改善方案。编码

编码

在这一部分中，咱们将讨论两个在网络论坛上不常讨论的问题：2pass码率控制和多线程编码速度瓶颈。spa

码率控制方式线程

与x264相似，libvpx有1pass ABR，稳定质量，2pass ABR和带码率限制的稳定质量码控方法。视频

libvpx码率控制方法blog

在x264编码中，常常会使用带峰值码率限制的CRF。而在libvpx CRF模式下，编码器会尝试达到稳定图像质量，同时将平均比特率保持在比特率限制限制在目标值如下。

这与x264 CRF的速率码率控制方法不一样。在x264中，咱们可使用VBV buffer和VBV maxrate实现编码输出码率峰值码率的控制，从而能够直观地调节设置DASH mpd文件中各分辨率的峰值码率高低。可是在libvpx CRF模式下没有这些选项，仅能够限制输出的平均码率，因此这意味着DashDASH mpd文件中各分辨率峰值码率是不肯定的。在HLS/DashDASH自适应码率切换中，峰值码率是重要的参考依据。高分辨率视频峰值码率越高，其播放的频率越低少。

另外一件不多被说起的事情是，咱们能够在CRF编码中使用2pass。因为1pass CRF在x264中获得了普遍使用，所以一开始咱们并无尝试在libvpx中使用2pass CRF。然而，2pass CRF在libvpx中的性能比1pass CRF好得多。它能够提升某些复杂场景的质量。咱们将在稍后讨论细节。

多线程编码速度

对于VOD编码来讲，咱们倾向于使用慢速设置的方式slow preset以得到更好的质量和更小的体积。在x264 / x265中，咱们可使用10个或更多线程来加速1080p视频的编码。可是，咱们不能没法在libvpx中使用那么多线程，并且在slowpreset预设下，1080p VP9编码时间比x264长得多。

通过一些了解后，咱们发现libvpx可使用的最大线程数与tile数量有关。最大tile数又取决于分辨率。下表显示了各分辨率的最大tile。

VP9各分辨率的最大tile

对于1080p内容，图像视频宽度为1920像素，最大tile仅为4。所以libvpx1080p的编码速度成为了咱们VOD服务的瓶颈。幸运的是，libvpx v1.7中引入了-row-mt选项，较以前版本有较大提高。可是对于须要快速上线的视频内容来讲，libvpx仍然不能知足咱们的要求，所以咱们须要GOP级别并行化来进一步加速。

Packaging HLS/DashDASH打包

选择Bento4仍是Shaka打包？

Bento4用做H264 / H265 的HLS / DASH打包中很是流行。但对于VP9来讲，咱们还有一个选择：Shaka Packager。在选择之初咱们进行了一些调研，在Bento4官方讨论中，其开发人员提到Bento4专一于基于ISO标准的各种流格式，而Webm不属于这一类。此外，咱们尝试Bento4生成一些VP9 + AAC流，却没法在咱们的Chrome浏览器中正常播放和运行。相反，Shaka Packager能够涵盖咱们全部的使用场景。所以，咱们决定在VP9打包封装中使用Shaka Packager。

Shaka Packager能够输出VP9 + AAC编码的fMP4 DASH流和VP9 + Opus编码的Webm DASH流。它也能够很好地支持AV1 + AAC和AV1 + Opus。

在默认状况下，Shaka Packager还会启用动态MPD。它能够大大提升客户端下载和CDN上传的速度，从而使咱们的文件管理更容易。

Webm仍是fMP4？

如上所述，咱们能够将Webm或fMP4用于VP9视频。不幸的是，根据Shaka Packager官方文档，Opus对ISO-BMFF的支持仍处于试验阶段。因此一开始咱们选择了带有VP9+Opus编解码器的Webm容器。在发布几个月后，咱们分析发现，相对于H264节省的总流量是低于咱们的预期的。

Shaka Packager支持的容器格式和编码

通过实验，咱们发现Webm容器封装后产生了大约20–30kbps的开销。这对于高分辨率视频影响不大。可是对于180p视频，若是音视频的比特流为100kbps，则转换为fMP4 DASH格式后的大小约为102kbps。可是，当咱们将其转换为Webm DASH格式时，它的大小约为120–130kbps。Webm容器中的开销多了约为20kbps，对于低分辨率内容来讲仍是太大。所以，咱们决定在将来使用fMP4容器。

将fMP4容器与VP9 + AAC编解码器一块儿使用的另外一个优势是易于维护多种编码格式的视频。咱们一般会先为每一个内容编一份H264+AAC的流，若是VP9也适用AAC编码，咱们直接能够把已编好流的AAC音轨复制或连接到VP9 MPD文件，而无需从新编码音频。每次咱们收到某个一种内容的新语言音频时，咱们只须要处理一次（AAC，fMP4）并将该音轨复制或连接到多个视频格式的流 (H264/H265/VP9) 中。这样咱们并不须要考虑其余音频编码（Opus）格式的处理。

咱们的改进

回到前面的问题，以前咱们发现某些MPD文件中360p峰值码率值低于240p。这对播放行为形成了流干扰，致使以至当网络变好时候，某些用户反而从360p切回240p。此外，以前的VP9编码在某些一些复杂场景下的图像质量较差不理想。通过一些实验，咱们发如今上述状况下2pass CRF的表现比1pass CRF好得多。

下图是咱们对同一视频进行2pass CRF与1pass CRFVP9编码的比较。它们使用相同的CRF值和码率限值。咱们能够看到1pass CRF的MPD峰值码率依次为350kbps、500kbps、450kbps、650kbps，在240p附近出现了一个异常点。相反，2pass CRF MPD峰值码率随着分辨率单调增长，是合理的。

DASH文件中各分辨率峰值码率(kbps)

咱们还计算了2pass CRF和1pass CRF输出的VMAF值。对比结果以下:

从以上数据能够看出，2pass CRF在输出质量上更稳定，在复杂场景下表现更好。

VP9真的过期了吗?

人们可能会说，咱们已经有了HEVC和AV1编解码器，为何咱们还须要VP9，是否是已通过时了？除了节省成本外，VP9目前至少还具备如下优势。

首先，Chrome类浏览器不支持HEVC解码，而VP9内容视频能够经过使用硬件加速在一些主流设备上播放。

其次，HEVC和AV1内容在一些低端Android设备上没法很好地播放。对于1080p+或胶片噪声视频，VP9的性能接近HEVC，。在某些状况下，VP9的性能有时甚至优于HEVC。

最后，VP9的当前编码成本比AV1低得多。与AV1相比，VP9能够节省不少编码时间和计算成本。对于观看时间不长的视频，AV1多码率编码带来的成本增长可能会比AV1其节省的流量费用还要多。在这种状况下，VP9多是更好的选择。

总结

在此博客中，咱们带领您体会分享了咱们从VP9入门到如今的过程，介绍了咱们遇到的挑战以及为改善最终用户体验而开发的解决方案。就像咱们在Hotstar所作的一切同样，这些学习经验成果正在被应用借鉴到咱们其余视频编解码器，平台和场景中。

咱们的团队一直在探索新的创新方式，以不断提升咱们在音频、视频处理和交付各个方面的性能和效率。