你的WebRTC应用该使用哪种音视频编解码器

我们很难抉择应该给WebRTC应用选哪一款音视频编解码器。VP8?H.264? VP9?还是使用AV1?HEVC呢?

有关WebRTC 视频编解码器的温馨提示

曾几何时WebRTC世界很简单,只有VP8OpusG.711 。G.711被划掉是因为我不推荐使用它。真的没有理由这样做。后来,H.264作为必须实现的视频编解码器加入。WebRTC进展顺利。

之后,谷歌决定在Chrome中引入VP9,将其作为备选编解码器。Mozilla也在Firefox中加入了VP9。微软呢?他们从Edge切换到Chromium就能“免费”使用它了。苹果的话,VP9应该会出现在他们的Safari 开发预览版中,这么做主要是因为谷歌Standia使用了VP9。这听起来可能有点奇怪。

另外,苹果公司决定把HEVC作为自己的可选编解码器添加到WebRTC中。可能是为了进一步迷惑我们。

最后是AV1。就目前而言下一代最好的视频编解码器。一旦它被添加到Chrome中(即90版本),并且被开发者使用,大家就会发现这一点了。

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

上图显示了目前web浏览器中对于视频编解码器的支持状况。

总结如下:

  • VP8和H.264在浏览器中很常见,但它们都存在一些问题;
  • VP9开源多年,仍没有被广泛采用。它可能“很快”出现在Safari中;
  • HEVC是苹果公司的产品;
  • AV1上市比较迟。

你的WebRTC应用该选择VP8还是H.264

如今,你可能正在使用,或者应该使用VP8或H.264。

这两者之间有什么真正的差别吗?不,并没有。在给定的比特率下,它们产出的音视频质量都差不多。

但VP8和H.264之间还是有一些细微差别的。比如:

  • 谷歌并没有真正在WebRTC中使用H.264。所以其实这两者中还是VP8应用更广。比如之前H.264一直不支持在Chrome中联播(现在支持了);
  • VP8几乎没有硬件加速,所以它在某些情况下会占用更多的CPU;
  • H.264在苹果设备、PC、安卓上有硬件加速。但有时你在WebRTC中不会有H.264的实现,因为无法获得硬件,软件实现也不存在(由于版权费等问题)。
  • Temporal scalability仅在VP8中可用,H.264中不可用。

我们自己进行的快速测试表明,H.264解码器比VP8解码器性能更好,无论H.264上是否有硬件加速。这个问题值得我们深入讨论。

那么你应该使用哪一个呢?

WebRTC中该使用VP8、H.264还是VP9

真正要使用的话,首先要考虑一个问题——要选择VP9吗?去年我确实推荐使用VP9。但也没看到什么变化——反正我是没看到有人真正采用VP9。

除了谷歌,没有人在用VP9。

在我们的测试中,它的CPU占用率接近于VP8。这很令人惊讶,也可能是谷歌在谷歌会议中使用它的原因。

VP9最棒的一点是什么呢?那就是它还支持SVC

那么现存问题是什么呢?那就是苹果公司还没有接受VP9格式。以后应该会接受的的,问题是什么时候接受罢了。

什么时候在WebRTC 中应该使用HEVC

这个问题的答案很简单——永远不要使用它。

换句话说,如果只在苹果设备之间进行通话,那么HEVC可能是一个不错的选择。

现在AV1 是否能派上用场呢?

并不确定。

根据我们自己的测试,AV1在性能方面比所有其他编解码器要差很多。它编解码所占用的CPU是其他音视频编解码器所需的两倍或更多。

AV1的质量本应比其他编解码器更好的,这样你才可能真的愿意负担它额外占用的CPU。据我所知,如今使用AV1不外乎两个原因:

  1. 处理特殊情况,如特低比特率,此时CPU不是问题,带宽才是;

  2. 只进行解码,而编码器在云端,在此处你能控制硬件时。但你要支付其计算成本;

  3. 据传闻,AV1擅长解码缩略图。

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

WebRTC初创时选择不多,只有VP8和H.264。这就是全部了。而现在?市面上有4-5种视频编解码器可供选择。

我们中的大多数人最终都选择使用VP8。也有些人选择H.264,主要是因为性能方面的考虑。其余的编解码器常被谈论,但几乎从未使用。

面世较晚的视频编解码器看来确实前景无量,比如VP9、AV1甚至HEVC在WebRTC应用中都潜力无限。但它们仍有一些难题亟待解决,主要是CPU和浏览器间的可用性问题。

为了使用这些编解码器,我们需要一种新的方法。即一个应用程序可以使用不止一个视频编解码器,有时甚至在同一会话中也这样做的方法。

以下是几个建议供大家探讨:

  • 只在1对1通话中支持较高复杂度的编解码器。当通话超过两个参与者时,就动态切换到其他视频编解码器;
  • 在低比特率情况下,动态切换到更复杂的编解码器;
  • 在设备上启用尽可能多的编解码器并行解码,然后根据编码器的CPU能力决定其应该发送的内容;
  • 在联播中使用多种视频编解码器。例如使用比特率很低的AV1,然后在它旁边使用比特率更高的VP8或VP9。联播不支持这一点(目前),但你可以用不同的编解码器和比特率打开两个独立的端对端连接,以达到类似的效果。

这样做是否值得?也许吧。我觉得在应用中提高视频质量还是很重要的。推进WebRTC多视频编解码器领域,8分的努力才能收获 2 分的优化。如果你完成了所有其他较为简单的优化,可以试试这个领域。

更头疼的是,谷歌和微软正在研发Lyra和Satin,全新的AI驱动音视频编解码器。事情将变得更加有趣(和复杂)。

文章地址:https://bloggeek.me/webrtc-video-codec/

推荐阅读
相关专栏
开源技术
106 文章
本专栏仅用于分享音视频相关的技术文章,与其他开发者和声网 研发团队交流、分享行业前沿技术、资讯。发帖前,请参考「社区发帖指南」,方便您更好的展示所发表的文章和内容。