最近几年，实时音视频领域愈来愈热，今年的疫情更是“火上浇油”了一把。网易智企旗下产品网易云信在实时音视频领域深耕多年，积累了很多实践经验。在本文里，笔者将以烹饪为比喻，深刻浅出地将网易云信如何从0到1构建实时音视频引擎的过程分享给读者。浏览器
跟业界不少引擎的实现方案同样，网易云信也是基于 WebRTC 构建的实时音视频引擎。本文会从介绍 WebRTC 提供了什么开始，一步步引入工程化/产品化/优化实践等内容，完整呈现引擎的整个构建过程。缓存
WebRTC 是什么
首先，WebRTC 是什么？服务器
WebRTC 全称 Web Real-Time Communication。本来是用于支持网页浏览器开发实时音视频用的一套 API，它提供了统一的交互协议：SDP，同时提供了视频会议的核心技术，包括音频引擎、视频引擎、传输控制三大块，而且还支持跨平台：Windows / Mac / Linux / Android / iOS。网络
WebRTC 原本就是给浏览器用的，没有 native 代码能够参考。可是，在 2011 年它被 Google 开源了，源码被应用于各类 native 开发，并被业内普遍借鉴，大有一统天下的趋势。ide
WebRTC 提供了什么？
有了 WebRTC，是否是就等于有了实时音视频引擎呢？并非，以烹饪来作比喻的话，有了 WebRTC 就比如是有了厨具/原材料，而实时音视频引擎是给客户的那顿大餐。工具
有了厨具/原材料，第一步是什么呢？“学会厨具使用方法”— WebRTC 的源码工程化。性能
WebRTC 官网和其余第三方渠道已有很多资料介绍如何使用 Google 提供的工具编译出 WebRTC 的生成物，本文再也不详细赘述。优化
会用厨具以后，是否是就能作出一顿好吃的饭菜了呢？编码
现实每每是这样的：用着很牛的厨具和材料，作着难如下咽的料理…线程
因此要以合理的步骤来作一顿饭菜，这饭菜才适合下咽。
基于 WebRTC 网易云信如何构建音视频能力
在网易云信的实践中，咱们选择了怎样的步骤呢？由于基于 WebRTC 创建通话的基础是经过设置 SDP 来完成的，因此咱们选择了经过信令传递 SDP 信息，而后设置 SDP 信息给 PeerConnection 来完成建联。整个多人音视频能力中核心的是发布、订阅、响应订阅等媒体功能，其余的功能都是围绕着这些核心功能来作的。而核心功能是采用以下流程来完成的：
举例：
发布音视频：把本身的 SDP 信息给媒体服务器（上图中的媒体服务器是 SFU 服务器），媒体服务器把本身对应的 SDP 信息返回来。这样就具有了 Local SDP 和 Remote SDP，就能够完成一次设置并建联了。
订阅和被订阅也是相似的过程，经过发送本身的 SDP 给服务器，拿到远端的 SDP 信息，而后创建/更新联接。
以上是一个基本的建联过程。拿烹饪来讲，是否是饭菜作熟了就很好吃了呢？其实还有不少须要提高的：把饭菜作得更好吃/根据不一样人的口味作不一样的饭菜。这个提高的过程，就是各类优化。
网易云信优化实践
网易云信的优化实践有不少，下面介绍其中的几种优化。
优化一：Simulcast
所谓 Simulcast，就是在一路视频里提供多个分辨率的视频流，订阅方灵活根据须要订阅想要的视频流。典型的就是在会议场景的应用，以下图：
若是没有 Simulcast 功能，假定须要 720P 的视频，在这个场景里，发送方须要发送/压码一路 720P 视频，接收/解码4路 720P 视频，带宽和性能压力很是大。若是增长了 Simulcast 能力，同时可以发送 720P/180P 的视频。在这个场景里，发送方一般只要发送/压码 180P 视频，接收/解码1路 720P 视频，接收/解码3路 180P 视频。带宽要求和性能要求降到了原先的1/4左右，而效果是彻底同样的。
WebRTC 的 Simulcast 功能，并非由 WebRTC 团队完成的，而是一个第三方开发团队开发，并 merge 到 WebRTC 里去的。要开启它，须要开启一个实验室接口，而后在 Video quality control 里更改相应的源码才能正常运行。配合上层的信令，就能作到灵活订阅了。
优化二：视频硬件编解码
一般，视频硬件编解码会比软件编解码性能开销更低。不管在平常使用仍是上高清分辨率（好比 1080P）都有很重要的做用。WebRTC 的硬件编解码功能不够完整，为了能用起来，咱们在整条路径中作了很多事情。以下图：
Android 端主要是硬件的碎片化引发，iOS 端主要是偶发的崩溃引发。碎片化靠下发白名单来解决（只对认证过的硬件启用），偶发崩溃靠收集线上信息来限制特定版本/特定机型来解决。两个移动端都有偶发失败的问题，因此设计了一个失败时的回退机制，以避免视频卡住的现象发生。最后再补完 simulcast 逻辑，就完成了这个硬件编解码的支持。
以上的优化，基本上是大部分场景均可以适用的，但也有些优化要看具体场景肯定。这就比如不一样的人口味不同，有人喜欢辣，有人喜欢原味，作不到一套方法搞定全部的食客，因而咱们作了定制化的优化来进行适应。
优化三：Audio profile
Audio 的优化作了不少，这其中挑了一个 Audio profile 的优化来说。语音场景里，须要的编码码率不过高，而娱乐场景里（好比播放伴音歌曲的），对码率要求就高不少了，否则会丢失音质。码率要求高了对网络要求也会高，因此为了应对不一样的场景，audio 的采样数/声道数都是不同的。音频硬件又是五花八门，能力不统一，若是采集上来的数据不合适，就须要作重采样支持。同时 codec 的倾向也作了 speech 和 music 的区分，以适应不一样的须要。WebRTC 原先的设计里，基本只考虑了语音，跟娱乐场景相关的部分都须要优化支持。同时，为了可以兼容更多的音频处理/更差性能的机器，咱们在优化过程当中，将播放/采集线程进行了分离，至关于硬件要求下降了一半。
优化四：传输策略优化
传输策略要照顾实时性/清晰度/流畅度三个维度，理想中的优化固然是三个都作得更好，惋惜这三个维度是互为掣肘的。以下图所示：
这三个点里，一个点增强了，其余点会被影响。举个例子：实时性要求很高，那缓存时间就得下降，这时候若是出现网络抖动，极可能会卡顿，流畅性就受影响。因此想要同一个策略知足不一样的需求不太现实。在项目实践中，咱们根据不一样的场景，设置不一样的策略，来知足不一样倾向的需求。
通讯场景通常对实时性要求高。举个例子，你跟别人语音聊天，隔了一秒钟才听见对面的声音，那么两我的的聊天很容易“打架”，互相抢着发言。若是是多人语音聊天，那这个现象就更加严重了。娱乐直播场景对清晰度要求很高，但却能够接受较高的延时。因此咱们在实践过程当中给予了不一样的策略支持，就比如作不一样口味的饭菜来知足不一样人的口味。
以上就是网易云信在构建音视频引擎过程当中的一些实践经验，在此分享给你们，但愿能给有兴趣的同窗参考。
更多内容欢迎关注 网易智企技术+ 公众号。