我们很难抉择应该给WebRTC应用选哪一款音视频编解码器。VP8？H.264? VP9？还是使用AV1？HEVC呢？
有关WebRTC视频编解码器的温馨提示
曾几何时WebRTC世界很简单，只有VP8、Opus和G.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驱动音视频编解码器。事情将变得更加有趣（和复杂）。
