2-6.为什么要使用WebRTC

那今天呢？我们来详细聊一聊，为什么实时互动直播中要使用webrtc，那在网上你经常会看到有人在说在线教育使用的是webrtc。那音视频会议呢，也使用了webrtc，声网，腾讯，阿里等等这些大厂呢，都在使用webrtc。那webrtc到底好在哪里呢？

那如果我们是做音视频实时互动直播的老手来说，那这个问题呢？就不言而喻了。而对于新手来说，就很难回答这个问题，而且呢，这个问题也是他们特别想知道的。

那今天呢，我们就来具体聊一聊，那要说webrtc好在哪里？我们就要做一些对比。比如说它在性能上是怎么样的？架构上是怎么样的？可维护性上，流行性上，代码风格等等，这些呢，都可以是我们对比的一些角度。

那你对比的越全面，得出的这个答案呢，也就更准确，但是难点是什么呢？就是我们目前市面上没有一款是与webrtc类似的开源库。也就是说，我们想对多个开源库进行对比，这种选择呢，是不存在的，但是我们又想知道，webrtc它到底好在哪里？

那我们就要想一些办法，那最好的办法呢，还是通过webrtc与我们自研的系统对比。是最好的，就如果你做过一次音视频，实时互动的系统，那么你就很容易的理解webrtc。为什么非常的优秀？

那下面呢？我们就来看看，如果我们自研系统应该怎么实现一个实时互动直播？那这张图呢，就是一个最基本的实时互动直播架构图，那在这张图中啊，我们可以看到它包括了五大模块儿，

那第一个模块儿呢，是音视频采集模块儿。第二个是音视频编码模块儿，网络传输模块儿，音视频解码模块儿以及音视频渲染模块儿，那这几个模块儿的作用也非常简单，通过它名字，我们就能知道。音视频采集模块主要是从设备上采集音视频数据。

那拿到音视频的原始数据之后呢？要对它进行编码。把这个数据量给它压缩下来，这样才更有利于我们在网络上进行传输，否则的话，光一个视频帧就有好几兆的数据，我们在网络传输的时候呢，就非常困难。所以我们必须要经过音视频的编码器，

把这个数据压缩下来，再经过网络传输，才能更好的达到这个实时性。OK那当对端收到这个数据之后呢？要通过音视频的解码器将压缩后的数据。给它解开，那最后拿到原始数据，然后再进行渲染，或者是播放，这就是它的一个最最基本的一个流程，那通过这张图。给人的感觉好像音视频直播也不是特别难，但实际上呢，这只是一个抽象图，那么我们就需要把这个抽象图呢？

具体的细化。那么，我们细化的第一步就是将音频与视频拆开。对于音频来说，有音频的采集模块儿，视频呢？有视频的采集模块儿，而且呢，对于音频和视频来说，他们分别有自己的编码器。那音频编码之后呢？可以是AAC Opus视频编码之后呢，可以是H264 VP8，那再经过网络模块传输到对端同样的解码。

要分为音频解码和视频解码，解码之后的数据变成了pcm和yuv数据，那最后呢？将音频的pcm数据通过扬声器播放出来，然后视频的yuv数据通过渲染模块呢，给它展示到屏幕上。这是我们最简单的一步习法。

实际这个细化还不够，我们还需要进一步的细化。对于每一个不同的终端，实际上都需要开发一套自己的采集模块儿和渲染模块儿。那通过这张图呢，我们就可以看出来，在PC端我们采集使用的是cordial，那mac端呢，也是采用的cordial，这两个cordial啊，虽然名字相同，但它底层使用的SDK。是完全不一样的，一个是在PC端，一个是mac端。

那另外呢，安卓端使用的是audio record iOS端呢，使用的是audio unit，这是音频的采集，那对于视频来说。也是同样的道理，对于不同的终端是有不同的SDK的，那么我们需要调用具体的SDK。

在具体的终端上采集数据好，那反过来对于接收端来说，它在播放音频数据的时候呢？也需要根据不同的终端进行具体的操作，那PC端依然使用的是cordial mac也是。而安卓端呢，就变成了audio track iOS呢，还是audio unit好，视频渲染也分为多种，比如说OpenGL OpenGL es。DirectX metal这些呢，都需要你根据不同的平台去采用不同的SDK。

那这个时候我们就会发现啊，实际音视频直播客户端是与你的平台是有密切关系的，那每一个平台每一个端，都有自己的一套底层驱动硬件儿的SDK。所以我们要实现各个不同的终端，就要调用不同的SDK，那这个代码量其实就蛮多的了，对于不同终端的适配。那可能在每一个端你都要安排一个人去做相应的开发。

那这里边儿呢，有些逻辑啊，是相通的，比如说我们在mac端和iOS端，但是PC端与mac端可能就完全不一样了。它们在处理硬件的步骤上完全不同，所以这个呢，差异还是蛮大的。除了硬件儿之外呢，对于webrtc来说呢，它支持的编解码器特别多，像视频有VP8 VP 9 av1，对于音频来说呢。有icsi lb copers等等这些。

那如果我们要自己做一个自研的直播系统，实际我们也要支持这些编解码器。因为只有你将这些编解码器支持了之后，你才能支持更多的设备连接到你的直播系统来。比如说我们要把电话接入进来，那电话音频使用的编解码器呢？是G711。而如果你要不支持这个编解码器的话，那你就没法与电话互通，那么浏览器里边儿它默认支持的VP8，

如果我们不支持VP8。那你就没法儿与浏览器互动，H264就支持更广泛的了，几乎所有的硬件儿设备都支持H264，那我们如果不支持H264，我们就无法利用硬件儿的编辑码儿器。所以你可以看出，如果是我们自己自研系统的话，它有多少工作量，各个终端采集端播放端多种编辑码器的支持性能的优化等等等这些。那可见啊，webrtc它做了多少工作？那下面呢，我们就来做一下对比，通过自研与webrtc做对比，

我们就可以看出webrtc的优势到底是在哪儿了。首先从性能上。性能呢，我们自研系统要通过自己来控制，而webrtc呢，有google的技术专家和强大的社区支持，所以它的性能呢，是非常优秀的第二个呢浏览器。我们自研系统肯定是不能支持浏览器的，而webrtc呢，就是为浏览器而生的，所以在浏览器中呢，默认的就支持了webrtc。

第三点，跨平台性，我们需要自己实现那每一个平台都涉及到很多底层的内容，那这些呢？其实我们在招人的时候都是非常困难的，而对于webrtc来说呢，已经实现了。插件儿化，那我们自己实验的时候呢，要实现这样一套管理也是费时费力。

而对于webrtc呢，已经实现了。那网络传输我们也需要自己实现，尤其是流控带宽评估这些，那webrtc呢？已经有了。服务质量就要自己实现，webrtc已实现，那稳定性就要看你团队的研发能力到底怎么样。而对于webrtc来说呢，它的稳定性是非常好的，那更新速度一般我们自研系统啊，更新都比较慢。

那实际还是与你的团队的能力有关，如果你的团队比较大，能力比较强，那更新就会快一些，而对于webrtc来说呢google在这方面投入是非常大的。那我们可以看到，现在基本上每个月都会有一版更新，所以这个更新速度呢，是越来越快，

而对于我们自研系统来说呢，据我观察。一般情况下，我们的自研系统更新速度都不是特别快。OK，那以上呢，就是我们这节课所要讲解的内容，那这节课中呢，我主要通过webrtc与我们自研系统的一个比较。来说明webrtc到底好在哪里，那通过这个表格儿呢，我们也可以知道，那无论是在性能上，质量上，对浏览器的支持上。

那webrtc呢？都具有非常明显的优势，所以这也就是为什么各大厂商都会使用webrtc的一个根本原因。那我们今天的课呢，就到这里，谢谢。

如有侵权，请联系我删除