2016年6月6日
By 1月时特约编辑
专题文章

VP9终于成熟了，但它适合每个人吗?

VP9的价值主张是明确的，如图1:“自适应高清流媒体，只有H的一半数据.264!“一半的数据速率降低了你的带宽和存储成本，并允许你在较慢的连接上以更高质量的视频吸引更多的观众. 它还可以减少客户每月的数据费用, 现在许多互联网服务提供商正在制定每月带宽上限，这是一个主要问题.

许多制作人开始探索将vp9编码的视频分发到桌面/笔记本浏览器和一些移动平台而不是H.264. 虽然你不能戒掉H.264已经存在多年了，VP9传输绝对是一个时代到来的概念. 在本文中，我将比较它们的多个方面，从编码到传递再到玩家创建. 除此之外, 我将简要介绍一下IP的情况，并以简要提及AV1作为结束, 即将取代VP9的编解码器.

VP9, WebM和DASH

让我们从VP9的简要概述开始, 这是一个来自谷歌的开源编解码器, 得益于2010年收购On2技术公司. Google开源的第一个编解码器是VP8, 在WebM文件结构中与Vorbis音频编解码器配对, 是基于Matroska媒体容器设计的吗.

VP9, 编解码器的下一个迭代, 于2013年年中首次推出，并于几个月后的9月由YouTube首次部署. 也是在2013年, WebM格式被扩展为包含Opus音频编解码器, 哪个最常与VP9配对. 您可以在WebM文件中提供包含VP9和Opus的单个文件，也可以在DASH封装中生成多个VP9/Opus流，用于自适应流.

图1. JW Player在其同名播放器和在线视频平台服务中支持VP9.

VP9是VPx的最后一次迭代, 因为谷歌在2015年9月成立了开放媒体联盟，以巩固与Mozilla的开源编解码器开发, 思科, 微软, 英特尔, 和其他人. 第一个联盟编解码器, 叫AV1, 会在2016年12月到2017年3月之间上映吗, 我将在本文后面讨论这个问题.

有了这些，让我们通过检查文件质量来开始了解VP9.

以一半的数据速率获得相同的质量? 关闭!

检验质量, 我以三种不同的分辨率和五种不同的数据速率编码了三个视频片段. 第一个片段是Blender基金会的一小段 《百家乐软件app最新版下载》(TOS) 电影，主要代表传统的电影内容. 第二个是Blender的一小段视频 Sintel 电影, 表示动画内容, 第三个是, 我称之为新剪辑, 是由多个剪辑来模拟真实世界的视频. 在Adobe Premiere Pro CC中工作，我产生了非常高的数据速率H.264夹层剪辑在三个分辨率具有相同的水平像素计数, 但垂直计数会因剪辑而异. 例如，最小的New剪辑是1280x720，而 Sintel /服务条款 夹子尺寸为1280x576. 这些夹层片段是所有编码的起点.

我对所有测试编码使用FFmpeg. 对于VP9编码，我使用了VOD 从WebM Wiki推荐的设置，在谷歌的建议下，将速度和帧并行都改为0. 对x264, 我使用了两道编码和非常慢的预设, maxrate和buffer设置为目标数据速率的150%, 本质上是150%的受限VBR，在缓冲中有一点摆动空间. 所有测试的关键帧间隔设置为3秒.

我用五种不同的数据速率对每个片段进行编码，每个片段的数据速率都不同. 作为一个例子，我对1920x856进行了编码 Sintel /服务条款 在1000Kbps, 1500Kbps, 2000Kbps, 2500Kbps和3000Kbps剪辑. 在所有测试中, 这为VP9以50% H的数据速率编码的每个片段留下了两个比较点.264. 例如，对于1920x856的TOS剪辑，我可以比较VP9在1000和H.2000时的264和1500时的VP9.264 at 3000 (图2). 因为9个测试片段中的每一个都有两个比较点, 这意味着总共有18个比较点来测试“50%数据速率下的相同质量”的前提.

图2. VP9的质量持续并大幅超过H.264是所有测试过的数据速率.

检验质量, 我使用了峰值信噪比(PSNR)指标, 使用莫斯科国立大学视频质量测量工具计算. 18例中有4例VP9视频的PSNR评分高于H.264视频，两倍的数据速率. 如果我通过乘以H加上5%的容差.264分0分.95、VP9在18个测试案例中赢了14个. 在10%的容差下，所有VP9文件的质量都超过了它们的H.264年同行. 如图2所示, 在整个数据连续体中，质量差异是相当一致的.

编解码器基准测试是一门不精确的科学, 所有的比较通常会导致更多的问题而不是答案. 来补充我的试验, 我与JW Player的首席压缩工程师进行了交谈, Pooja马丹, 谁设计并实现了JW的VP9编码工具. 她建议说，该公司在编码阶梯上总体节省了大约50%, 因此如图1所示. 在撰写本文时，我采访的大多数其他公司都报告了类似的结果.

但是你需要很多时间

基于vpx的编解码器的致命弱点一直是编码时间，VP9也不例外. 我在HP Z840双3工作站上生成了后面讨论的所有性能数据.1 GHz E5-2687W处理器，每颗10核, 和超线程技术(HTT), 总共40个核心. 所有源文件存储和编码文件交付到Turbo SSD G2驱动器. 这是一个非常快速和功能强大的系统，你可以在一系列基准审查 in 百家乐软件app最新版下载.

在Z840上，将96秒的720p New文件编码为H.2Mbps的264格式需要98秒. 使用google推荐的参数编码，在19:10以VP9格式发送相同的文件, 大约长12倍. 当我为这篇文章采访JW Player时, Madan报告说，该公司投入了大量时间来实现编码时间和质量之间的最佳平衡.

我问她是否愿意分享她的FFmpeg脚本，以便在我的测试中使用，她(和公司)同意了. 结果令人印象深刻. 具体地说, JW Player命令行脚本在4分59秒内以2Mbps生成了720p的新文件, 大约是Google脚本的22%. 我检查了JW player编码文件的PSNR值与使用Google推荐参数创建的文件, JW得分高出约5%.

在编码, 我跟踪了CPU利用率，并注意到在渲染单个文件时, VP9几乎没有改变针头. 我决定检查性能与多个编码器运行. 要做到这一点, 我在两个SSD驱动器上创建了多个文件夹，并同时运行每个命令行脚本8次，然后是12次. 你可以看到表1，多重编码降低H.当同时编码12个文件时，将JW Player脚本与264到VP9的编码差异降低到每个文件不到4秒.

表1. H的编码次数.264和两个VP9测试脚本.

这些结果提出了两个问题. 第一个问题是为什么Google会生产一个在多核工作站上表现如此糟糕的编解码器. 答案是，这个性能模型非常适合它当前的编码模式. 这是, Google doesn’t encode each input file from start to finish in a single encoding instance; it encodes all files in parallel, 将每个源分割成块，然后将它们发送到不同的编码实例.

在谷歌的编码系统中，VP9一点也不慢. 见鬼，40岁了.每个文件5秒，只比H慢10%.264. 然而, 这种性能模式给开发人员增加了创建高效编码程序或平台的负担. 当然, VP9并不是第一个无法有效利用多核系统的编解码器, 和编码程序，如Telestream Episode，长期以来一直使用一种称为分割和缝合的技术来提高多核系统的性能. 很像YouTube的并行编码模式, 分割和缝合将单个输入文件分成并行编码的多个部分, 然后拼接在一起，最后输出. 本质上, 表1中显示的12并发编码测试模拟了这种并行编码操作, 这使得Z840的使用率达到98%以上。图3).

图3. 12个同步VP9编码将Z840推向了最大值.

VP9 isn’t slow; it’s just highly inefficient in a multiple-core environment, 这使得开发人员更难设计高效运行的编码系统. 出于这个原因, 期望在支持VP9的程序中看到编码时间(和质量)的实质性差异. 创建自己的编码器的开发人员应该从一开始就设计他们的架构，知道他们将不得不部署像Google这样的系统来最大化VP9编码时间和效率. 在云计算中尤其如此, 按小时收费的地方, 将编码工作分散到尽可能少的cpu和cpu小时的能力直接转化为底线.

你必须进行实验

第二个问题是:JW Player的脚本是否比Google推荐的脚本质量更好，编码速度更快, 为什么我没有用它来做质量测试? JW Player的脚本使用了一种称为上限公共速率因子(CRF)的技术, 它告诉FFmpeg以一定的质量水平交付文件，但以一定的比特率为上限. 例如，JW脚本使用的CRF值为30，数据速率为2Mbps. 这告诉FFmpeg将文件编码为30的质量级别，但将数据速率限制在2Mbps.

如果文件易于压缩, 比如一个会说话的头夹, 整个视频可能远低于2Mbps. 如果剪辑很难压缩，整个剪辑可能会被限制在2Mbps. 因此，当使用capped CRF编码时, 比特率, 以及生成的文件大小, 会因内容的不同而不同吗.

这在比较编解码器时提出了一个挑战, 因为总是需要检查输出文件大小，以确保编码器满足目标数据速率. 显然，这不能用于带上限的crf编码文件. 我认为使用有上限的CRF方法进行基准测试是不合适的, 不过我当然会考虑生产. 如果你在设计自己的系统, 一定要包含这个功能, 如果你要买一个编码器, 在购买前确认有上限的CRF可用.

最后, 为那些编码自己的VP9文件, Madan很好地分享了她对VP9编码的四大收获:

Use two-pass encoding; one pass does not perform well.
采用双通道编码, 为最大的分辨率生成第一次传递日志，然后为其他分辨率重用它. VP9优雅地处理了这个问题.
而VP9允许更大的CRF值, we noticed that CRF < 33 speeds up the encoding process considerably without significant losses in file size savings.
您必须在第二次传递中使用“tile-columns”参数. 这提供了多线程编码和解码，但对质量的影响很小.

我还要补充一点，您不应该认为Google的推荐就是满足您需求的最佳实践. 底线是，您可能必须投入大量时间来创建编码时间和输出质量的最佳组合.

您将拥有一个不断增长的编码选项列表

截至2016年NAB, 在选择编码器时，您应该有更多的选择, 无论是在本地还是在云端. 在企业编码方面, Telestream宣布，将在2016年中期将VP9编码整合到Vantage转码多屏幕程序中. 探索是什么促使Telestream在编解码器可用3年后将VP9集成到Vantage中, 我问保罗·特纳, 企业产品管理副总裁, “为什么VP9, 为什么是现在?他说, “New codecs show up all the time; as an encoding supplier, 我们会查看所有这些，但不会立即将它们添加到我们的产品中. 此时此刻, 我们相信VP9是有前途的，对于一直使用H编码的客户来说，它是一个可行的选择.264和其他UHD编解码器.”

下一个页面