音视频通信为什么要选择WebRTC？

在网上经常看到有人说：“在线教育直播是用WebRTC做的”，“音视频会议是用WebRTC做的”......；“声网、腾讯、阿里......都使用的WebRTC”。但你有没有好奇，这些一线大厂为什么都要使用WebRTC呢？换句话说，WebRTC到底好在哪里呢？

这个问题，对于长期做音视频实时通信的老手来说是不言而喻的；但对于新手，则是急切想知道，而又很难得到答案的问题。那么本文我将采用对比法，向你详细阐述一下WebRTC到底好在哪里。

这次我们对比的指标包括：性能、易用性、可维护性、流行性、代码风格等多个方面。不过，要做这样的对比并非易事儿，首先要解决的难点是，目前市面上没有一款与WebRTC接近或有相似功能的开源库。这真成了无米之炊了！

好在这点困难并难不倒我们，既然没有与之可比较的开源库，那我们就自己“造”一个，用自研系统与WebRTC作比较。评估一下自研系统与基于WebRTC开发的音视频客户端，哪个成本更低、质量更好。通过这样的对比，相信能让你更加了解WebRTC，知道其到底有多优秀了。

1.自研系统直播客户端架构

首先我们先来了解一下自研直播客户端的架构，其如（图1）所示。这是一个最简单的音视频直播客户端架构，通过这张架构图，你大体可以知道自研系统都要实现那些模块了。

（图1）

由（图1）你可以知道，一个最简单的直播客户端至少应该包括：音视频采集模块、音视频编码模块、网络传输模块、音视频解码模块和音视频渲染模块五大部分。

• 音视频采集模块：该模块调用系统的API，从麦克风和摄像读取设备采集到的音视频数据。音频采集的是PCM数据，视频采集的是YUV数据。

• 音视频编码模块：它负责将音视频设备上采集的原始数据（PCM、YUV)进行压缩编码。网

• 络传输模块：该模块负责将编码后的数据生成RTP包，并通过网络传输给对端；同时，接收对端的RTP数据。

• 音视频解码模块：它将网络模块接收到的压缩数据进行解码，还原回原始数据（PCM、YUV）。

• 音视频渲染渲染：拿到解码后的数据后，该模块将音频输出到扬声器，将视频渲染到显示器。

通过前面的介绍，相信你一定觉得，自研一个直播客户端好像也不是特别难的事儿。但实际上，上面介绍的音视频直播客户端架构是极简化的，甚至都不能称之为直播客户端架构，而只能称它为示意图。因为要将它变为真实的、可商用的架构还需要做不少的细化工作。

2.拆分音视频模块

接下来，咱们就对上面的直播客户端架构图进行逐步细化，细化的第一步就是拆分音视频模块。因为在实际开发中，音频与视频的处理是完全独立的，它们有各自的处理方式。如音频有独立的采集设备（声卡），独立的播放设备（扬声器）、访问音频设备的系统API等，另外，音频还有多种音频编解码器，如Opus、AAC、iLBC等；同样，视频也有自己独立的采集设备（摄像头）、渲染设备（显示器）、各种视频编码器，如H264、VP8等。细化后的直播客户端架构如（图2）所示。

（图2）

从（图2）中你可以看到，细化后的架构中，音频的采集模块与视频的采集模块是分开的，而音频编解码模块与视频的编解码模块也都是分开的。也就是说，音频是一条处理流程，视频是另外一条处理流程，它们之间并不相交。在音视频处理中，我们一般称每一路音频或每一路视频为一条轨。

除此之外，你还可以知道，自研音视频直播客户端要实现的模块远不止5个，至少应该包括：音频采集模块、视频采集模块、音频编码/音频解码模块、视频编码/视频解码模块、网络传输模块、音频播放模块以及视频渲染７