我们很难抉择应该给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上市比较迟。
1、你的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上是否有硬件加速。这个问题值得我们深入讨论。
那么你应该使用哪一个呢?
2、WebRTC中该使用VP8、H.264还是VP9
真正要使用的话,首先要考虑一个问题——要选择VP9吗?去年我确实推荐使用VP9。但也没看到什么变化——反正我是没看到有人真正采用VP9。
除了谷歌,没有人在用VP9。
在我们的测试中,它的CPU占用率接近于VP8。这很令人惊讶,也可能是谷歌在谷歌会议中使用它的原因。
VP9最棒的一点是什么呢?那就是它还支持SVC。
那么现存问题是什么呢?那就是苹果公司还没有接受VP9格式。以后应该会接受的的,问题是什么时候接受罢了。
【学习地址】:FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发
【文章福利】:免费领取更多音视频学习资料包、大厂面试题、技术视频和学习路线图,资料包括(C/C++,Linux,FFmpeg webRTC rtmp hls rtsp ffplay srs 等等)有需要的可以点击1079654574加群领取哦~
3、什么时候在WebRTC中应该使用HEVC?
这个问题的答案很简单——永远不要使用它。
换句话说,如果只在苹果设备之间进行通话,那么HEVC可能是一个不错的选择。
现在AV1**是否能派上用场呢?**
并不确定。
根据我们自己的测试,AV1在性能方面比所有其他编解码器要差很多。它编解码所占用的CPU是其他音视频编解码器所需的两倍或更多。
AV1的质量本应比其他编解码器更好的,这样你才可能真的愿意负担它额外占用的CPU。据我所知,如今使用AV1不外乎两个原因:
\1. 处理特殊情况,如特低比特率,此时CPU不是问题,带宽才是;
\2. 只进行解码,而编码器在云端,在此处你能控制硬件时。但你要支付其计算成本;
\3. 据传闻,AV1擅长解码缩略图。
4、欢迎来到多编解码器的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驱动音视频编解码器。事情将变得更加有趣(和复杂)。
文章地址:🎲 Which video codec to use in your WebRTC application? 🎲 • BlogGeek.me