文/red5pro

VP9

受多项专利保护，并得到了MPEG-LA组织的授权。然而，CiscoSystem在2013年向公众提供了一种广泛使用的免费开源编码器和openH264解码器。换句话说，Cisco为我们所有人使用的专利许可证付费。这反过来创造了编解码器的广泛采用。OpenH264在所有的网络浏览器中出现了。

上文我们已经介绍了编解码器，让我们来比较一下它们之间的不同。我们列出了6个关键因素来评估每个编解码器。

编码质量

为了判断图像质量，我们可以使用SSIM（结构标准指数测量），如下图所示。当在因特网上广播一个流（broadcastingastream）时，压缩和扩展（编码和解码）流中包含的可视数据的过程可能会导致轻微失真（slightdistortions），因为解码器会外推数据（decoderextrapolatesthedata）以显示它。因此，SSIM本质上是编码和解码后衡量传输的图像在编码和解码后的精确度。

‌‌

然而，与相比，有一点不同。

会产生较差的图像，特别是在较低的比特率下。当比较以相同比特率运行的图像时，VP9和都比用生成的图像更详细和更清晰。换句话说，为了产生相同质量的VP9或图像，需要以更高的比特率运行。然而，质量上的差异虽然可以察觉，但并不一定是一个直接的问题。为了更客观地衡量这一点，我们可以看看SSIM，它显示的结果非常接近VP9和。因此，虽然在图像质量方面可能不如，但这种差异不足以克服下一节中详细介绍的大的权衡（bigtradeoff）。

我们还应该指出其他因素，如改进的亚像素插值（sub-pixelinterpolation）和运动矢量参考选择（motionvectorreferenceselection）（运动估计motionestimation）也提高了图像质量。这是因为它们有助于预测电影中下一帧会是什么样子。这些都是相当复杂的概念，值得他们在自己的文章中讨论，所以我们到此为止。

优胜者：平局

EncodingTime

那么，上面的图表到底是什么意思呢？

此图在水平轴上显示了编码时间（以秒为单位）。纵轴显示了比特率的改进，它将SSIM和比特率的组合与设置为x265@veryslow的参考点进行比较。参考点是为什么x264没有超过0%的原因。

这张图告诉了我们什么？

VP9和（如广告宣传的那样）比好50％。但它们的速度也慢10到20倍。如果你追循x264（AVC）的蓝线，你将看到对于大多数比特率基准点，它始终低于其他两条线。不仅如此，绿色（）和橙色（VP9）线在它们的曲线中很早就与相交。这意味着每帧速率的秒数将开始急剧增加，并真正降低你的流性能（streamperformance.）。因此，虽然VP9和显示出更好的压缩率，但它以非常高的编码时间为代价，这将大大增加延迟。WaterlooUniversity的这项研究对编码时间和编解码器的比较进行了更深入的分析。（参考资料：）

优胜者：

中央处理器消耗

正如上一节所述，VP9和都必须比运行更多的压缩算法（compressionalgorithms)，这将增加它们的CPU使用率。即使在完全优化的情况下，实时流媒体也是一个CPU密集型的过程，因此提高已经很高的使用率将是一个问题。然而，有一些东西可以缓解这一点：硬件支持。专用芯片组将降低CPU消耗。

目前享受更多的硬件支撑，包括Windows10（可下载或通过InterKabyLake或更新的处理器）、Apple（iOS11）和Android（）设备。虽然大多数移动设备支持VP9，但大多数其他系统不支持。如果没有直接的硬件支持，VP9编码过程将会限制CPU，消耗大量资源，缩短电池寿命，并可能增加延迟。

我们将在下一节中介绍享有广泛的支持，而且不会像VP9或那样消耗CPU。

优胜者：，紧跟其后。

AdoptionandBrowserImplementation

为了使用编解码器，需要有硬件的支持或软件编码器。的采用率很低，这在很大程度上是由于专利许可。有四个相关的专利池：HEVEAdvance、MPEGLA、VelosMedia和Technicolor。这使得它更加昂贵，也阻碍了它的广泛应用，从而限制了它仅限于特定的硬件编码器和移动芯片组（mobilechipsets）。只有Edge、InternetExplorer和Safari支持硬件编码。即使到那时运行浏览器的设备仍然需要支持硬件编码。即使在正确实现的浏览器中支持，WebRTC也往往无法正常工作。没有WebRTC的支持，实现实时延迟会是困难的。

VP9是免税版和开源的，这为其更广泛的采用扫清了道路。主要浏览器Chrome、Firefox、Edge以及操作系统Windows10、、iOS14和macOSBigSur都支持该功能。由于WebRTC支持VP9，它也可以直接在浏览器中工作。也有传言说Safari浏览器的支持也即将到来。

尽管有一项与之相关的专利，正如我们前面提到的，2013年思科对实现进行了开源，并以freebinarydownload的形式发布了它。这对的广泛应用是一个巨大的推动。因此，得到了所有浏览器、笔记本电脑和移动设备的支持。

优胜者：与VP9之间缩小了差距。

带宽节省

根据Nettfix的一项测试，的表现比VP9高出约20%。尽管其他的测试产生了不同的结果，但他们都得出结论，创建了更小的文件大小。根据所使用的客观度量标准（objectivemetric），比VP9节省了0.6%至38.2%的比特率。

然而，虽然消耗更少的带宽是有用的，但还有其他一些因素需要考虑。全球固定宽带连接的平均上传速度为42.63Mbps，这意味着尽管要求更高的连接速度，大多数地方也能支持4K流媒体。尽管移动设备的平均上传速度低得多，为10.93Mbps，但它们仍然可以支持1080p流。

这张来自Boxcast的图表显示，全球平均连接速度肯定能够满足所有分辨率级别的上传速度要求。注意:我们无法找到一个比较所有三种编解码器的图表，但是VP9应该介于和之间。

此外，还有一些方法可以配置你的流媒体应用程序，以满足网速较慢国家的用户。您可以通过添加ABR和代码转换支持来实现这一点。ABR(自适应比特率)将修改比特率，以提供最佳的体验。代码转换将广播分成多个质量，这样客户端可以根据可用带宽请求最佳质量。

你可能会想“如果移动设备卡在2或3G连接上怎么办?”幸运的是，手掌大小的设备不需要传输最高分辨率就能看起来很好。720甚至480依然会显示出不错的质量。

Whilebandwidthconsumptionmaynotmatterasmuchtoaconsumer,itmustbeacknowledgedthatcompan,itisonlyatreallyhigh-resolutionsettingssuchas4Kthathalvingthedataconsumptionmakesasubstantialdifference.

虽然带宽消耗对消费者来说可能不是那么重要，但必须承认的是，如果公司使用VP9或进行传输,就会节省带宽成本。这些节省的费用来自于较小的文件，这意味着他们不用为通过CDN或云网络传输上的更多数据流支付那么多的费用。这当然很好，但只有在像4K这样的高分辨率环境下，数据消耗减半才会产生实质性的影响。

当然，无论什么规模，省钱当然是重要的。这就引出了我们的下一个观点，它将呈现两个世界的最佳状态：相同的性能下更好的压缩。

优胜者:

LCEVC回避了整个争论

LCEVC被广泛采用背后的驱动力是：几乎任何设备都可以支持thinLCEVC客户端，这些客户端可以独立下载到观众的设备上，或者嵌入到服务提供商的appplayer中。通过它的HTML5JavaScript实现，LCEVC也支持插件式免费浏览器支持。这意味着广泛的实现应该是相当简单的。

什么是实用？

也就是说，考虑到VP9是免费的，而且还享有广泛的设备支持，一旦更快的软件或硬件编码器被创建出来，在不久的将来它将是一个可行的选择。在遥远的将来，AV1最终将会取代VP9，但考虑到它目前所面临的超高编码时间，在它准备好广泛使用之前，还需要进行大量的简化工作。当然，LCEVC可能会绕过更改编解码器以获得更好压缩的整个问题。也许它只是和AV1之间的一座长存的桥梁。