VP9编码：迄今的尝试

文 / 常谦
原文链接 / https://blog.hotstar.com/vp9-encoding-journey-so-far-e1153ab488db

图片源于Unsplash上Tim Mosholder拍摄

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

探索

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

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

编码

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

码率控制方式

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

libvpx码率控制方法

在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所做的一切一样，这些学习经验成果正在被应用借鉴到我们其他视频编解码器，平台和场景中。

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