共计 2692 个字符，预计需要花费 7 分钟才能阅读完成。
最近几年，实时音视频畛域越来越热，往年的疫情更是“推波助澜”了一把。网易智企旗下产品网易云信在实时音视频畛域深耕多年，积攒了不少实践经验。在本文里，笔者将以烹饪为比喻，深入浅出地将网易云信如何从 0 到 1 构建实时音视频引擎的过程分享给读者。
跟业界很多引擎的实现计划一样，网易云信也是基于 WebRTC 构建的实时音视频引擎。本文会从介绍 WebRTC 提供了什么开始，一步步引入工程化 / 产品化 / 优化实际等内容，残缺出现引擎的整个构建过程。
首先，WebRTC 是什么？
WebRTC 全称 Web Real-Time Communication。本来是用于反对网页浏览器开发实时音视频用的一套 API，它提供了对立的交互协定：SDP，同时提供了视频会议的核心技术，包含音频引擎、视频引擎、传输管制三大块，并且还反对跨平台：Windows / Mac / Linux / Android / iOS。
WebRTC 原本就是给浏览器用的，没有 native 代码能够参考。然而，在 2011 年它被 Google 开源了，源码被利用于各种 native 开发，并被业内宽泛借鉴，大有一统天下的趋势。
有了 WebRTC，是不是就等于有了实时音视频引擎呢？并不是，以烹饪来做比喻的话，有了 WebRTC 就好比是有了厨具 / 原材料，而实时音视频引擎是给客户的那顿大餐。
有了厨具 / 原材料，第一步是什么呢？“学会厨具应用办法”—WebRTC 的源码工程化。
WebRTC 官网和其余第三方渠道已有不少材料介绍如何应用 Google 提供的工具编译出 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 原先的设计里，根本只思考了语音，跟娱乐场景相干的局部都须要优化反对。同时，为了可能兼容更多的音频解决 / 更差性能的机器，咱们在优化过程中，将播放 / 采集线程进行了拆散，相当于硬件要求升高了一半。
优化四：__ 传输策略优化
传输策略要关照实时性 / 清晰度 / 晦涩度三个维度，现实中的优化当然是三个都做得更好，惋惜这三个维度是互为掣肘的。如下图所示：
这三个点里，一个点增强了，其余点会被影响。举个例子：实时性要求很高，那缓存工夫就得升高，这时候如果呈现网络抖动，很可能会卡顿，流畅性就受影响。所以想要同一个策略满足不同的需要不太事实。在我的项目实际中，咱们依据不同的场景，设置不同的策略，来满足不同偏向的需要。
通信场景个别对实时性要求高。举个例子，你跟他人语音聊天，隔了一秒钟才听见对面的声音，那么两个人的聊天很容易“打架”，相互抢着发言。如果是多人语音聊天，那这个景象就更加重大了。娱乐直播场景对清晰度要求很高，但却能够承受较高的延时。所以咱们在实际过程中给予了不同的策略反对，就好比做不同口味的饭菜来满足不同人的口味。
以上就是网易云信在构建音视频引擎过程中的一些实践经验，在此分享给大家，心愿能给有趣味的同学参考。
