你会在你的WebRTC 应用程序中使用哪种视频编解码器呢？

Posted 2021-06-16 LiveVideoStack

当为WebRTC应用程序来选择正确的视频编解码器已经成为了一件非常棘手的事儿时...你是应该使用VP8? H.264? VP9? 还是 AV1? 或者 HEVC呢？

 

文 / Tsahi Levent-Levi

原文链接 / https://bloggeek.me/webrtc-video-codec/

 

 WebRTC视频编解码器–小提示 

WebRTC曾经是一个非常简单的编解码器。您可以有VP8，Opus和G.711。至于为什么G.711被删除，主要是因为我不希望您使用它，尽管确实也没有这样做的理由。而后来，H.264被添加为实施视频编解码器的必需项。WebRTC领域中的一切都在正轨之中。

 

紧接着，谷歌决定在Chrome中引入VP9，作为可选编解码器。Mozilla也将VP9添加到了Firefox。那么微软呢？当他们将Edge切换为Chromium时，他们“免费”获得了它。还有苹果公司……对的……是苹果公司。VP9应该在他们的Safari技术预览版中出现，但主要是因为Google Standia使用了VP9这一事实，听起来可能令人惊讶。

 

哦，苹果公司决定将HEVC作为自己的可选编解码器添加到WebRTC中——只是为了更好的考虑（层组）。并使我们所有人更加困惑。

 

然后就是AV1。下一代最佳视频编解码器。暂且来说是这样的。至少当它被添加到Chrome中（即90版），以供开发人员使用。

 

 支持跨WebRTC浏览器的视频编解码器 

 

上图摘自我最近举办的2021年WebRTC趋势研讨会。它显示了web浏览器中对于支持视频编解码器当前的状态。

 

简略总结一下：

 

- VP8和H.264在浏览器中无处不在，但是正如事实那样，它们两者之间都存在一些问题

 

- VP9在开发多年后并没有被广泛采用，但是“很快”就要出现在Safari中了

 

- HEVC是苹果公司“专有”的

 

- 对比起来AV1是十分崭新的

 

 在WebRTC中视频编解码器的性能 

 

上周，我与Philipp Hancke一起参加了本月的WebRTC每月“演奏”。在本月“演奏”中，Philipp建议我们研究视频编解码器的性能，因此他也撰写了一个……“演奏”。

 

您可以观看整个演奏：测量视频编解码器的性能 （点击查看：
https://webrtccourse.com/course/webrtc-codelab/module/fiddle-of-the-month/lesson/measuring-video-codecs-performance/）

 

结果非常有趣，并且有时还会令人感到十分惊讶。但这样做的好处是，您无需固守我们所提供的信息——您可以自己使用代码并使用它。另外，请确保在您的场景中正确使用它，而不要在我们共享的简单场景中使用它，因为每个人的情况可能有所不同。

 

在WebRTC应用程序中使用VP8还是H.264呢？

 

今天？您可能正在使用VP8或H.264 ——或者应该正在使用VP8或H.264。

 

那么两者之间有什么真正的区别？不，也不能这样说。而是在对于给定的比特率上，它们产生相似的视频质量。

 

但是它们之间存在一些细微差别：

 

- Google在WebRTC中并没有真正地去用到H.264。因此，VP8成为了两者中维护程度更高的视频编解码器。例如，H.264多年来一直不支持Chrome中的同步播放（尽管现在已经支持）

 

- VP8几乎没有硬件加速，因此在某些情况下它将消耗更多的CPU。

 

- H.264具有硬件加速功能。在Apple设备上。有时在PC上。有时在android上。不过有时，您将无法在WebRTC中安装启用H.264，因为硬件不可访问，软件实现也不存在（版税之类的）

 

- 时域分级（时间可伸缩性）仅在VP8中可用。H.264并没有。

 

在我们自己的快速测试结果中表明，H.264解码器优于VP8解码器——无论在H.264上是否有硬件加速。这都是一件绝对要考虑其中的事情。

 

您到底应该使用哪一个？扔骰子来决定…

 

WebRTC中的VP8/H.264或VP9？

 

这是一个真正需要思考的问题。您应该使用VP9吗？去年，我曾建议这可能是一个使用VP9的好时机。但是这几乎没有什么发生变化的是——我看不到有什么人真正的在使用它。

 

除了Google之外，没有人使用它。

 

在我们的测试中，它的CPU使用率接近VP8。这真是令人惊讶。这可能就是Google在Google Meet中使用它的原因。

 

VP9最大的优点是什么呢？就是它还支持SVC（以一种未记录的调整方式）

 

那挑战又是什么呢？苹果公司。现在仍然还没有。但是差不多应该到时候了。但问题是具体什么时候。

 

何时在WebRTC中使用HEVC？

 

这个答案很简单-永远不会。

 

也就是说，如果您仅仅是在Apple设备之间进行通话，那么HEVC可能是一个不错的选择。

 

对AV1来说，这个时机合适吗？

 

是，也不是。

 

根据我们自己的测试结果来说，就性能而言，AV1比所有其他编解码器都差很多。在编码和解码的过程中AV1所需的CPU是我们尝试过的所有其他视频编解码器的两倍或更多。

 

但是AV1应该比其他编解码器提供更好的质量，因此您实际上可能需要支付额外的CPU。据我所知，今天使用AV1的原因有两个：

 

1.要处理某些特定情况，例如非常低的比特率（CPU不是瓶颈，但带宽是瓶颈）

 

2.当您仅需要解码，而编码器在云端时——一个您控制硬件的地方。不过，您将在计算成本中为此支付

 

3.据传它还擅长解码缩略图

 

欢迎来到多编解码器WebRTC世界 

 

WebRTC开始发展时并没有很多选择。只有VP8和H.264。就是这样的情况。但是现在呢？我们可以随时提供4-5个视频编解码器供您选择。

 

我们大多数人最终使用VP8并没有什么原因。而也有些人选择了H.264，主要是出于对性能方面的考虑。其余的大多数的编解码器虽然经常被谈论，但几乎从未被使用过。

 

新型视频编解码器确实很有前途——比如VP9，AV1甚至HEVC在WebRTC应用程序中，都具有真正的潜力。尽管如此，它们也面临着一些巨大的挑战——主要是CPU和跨浏览器的可用性。

 

要使用它们，需要一种新的方法。那就是通过一个应用程序有时可以进行完全相同的会话中使用多个视频编解码器。

 

这里有一些建议供您探索：

 

- 仅在1：1的呼叫上支持更高复杂度的编解码器，并且当呼叫数量超过两个参与者时，可以动态切换到其他视频编解码器

 

- 在低比特率下动态切换到更高复杂度的编解码器

 

- 在一台设备上并行启用尽可能多的编解码器解码，然后根据其CPU能力决定编码器应发送的内容

 

- 在同播中使用多个视频编解码器——例如，使用极低比特率的AV1，然后再使用较高比特率的VP8或VP9。虽然目前还不支持此功能，但是您可以使用不同的编解码器和比特率打开两个独立的对等连接，以实现相似的结果。

 

这值得一试的吗？答案是也许吧。您可以告诉我提高应用程序中的视频质量是否重要。在WebRTC中，投机进入多视频编解码器领域大约需要80%的努力才能产生最后20%的改进。完成所有其他更简单的优化后，请转到此处。

 

2021年WebRTC趋势 

 

上个月，我主持了一个关于2021年WebRTC趋势的研讨会。

 

我介绍了单一视频通话，语音压缩，背景模糊，E2EE和视频编码方面的优化。 还介绍了选择哪种视频编解码器的挑战。