从0到1 构建实时音视频引擎

最近几年，实时音视频领域越来越热，今年的疫情更是“火上浇油”了一把。网易智企旗下产品网易云信在实时音视频领域深耕多年，积累了不少实践经验。在本文里，笔者将以烹饪为比喻，深入浅出地将网易云信如何从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原先的设计里，基本只考虑了语音，跟娱乐场景相关的部分都需要优化支持。同时，为了能够兼容更多的音频处理/更差性能的机器，我们在优化过程中，将播放/采集线程进行了分离，相当于硬件要求降低了一半。

优化四：传输策略优化

传输策略要照顾实时性/清晰度/流畅度三个维度，理想中的优化当然是三个都做得更好，可惜这三个维度是互为掣肘的。如下图所示：

这三个点里，一个点加强了，其他点会被影响。举个例子：实时性要求很高，那缓存时间就得降低，这时候如果出现网络抖动，很可能会卡顿，流畅性就受影响。所以想要同一个策略满足不同的需求不太现实。在项目实践中，我们根据不同的场景，设置不同的策略，来满足不同倾向的需求。

通信场景一般对实时性要求高。举个例子，你跟别人语音聊天，隔了一秒钟才听见对面的声音，那么两个人的聊天很容易“打架”，互相抢着发言。如果是多人语音聊天，那这个现象就更加严重了。娱乐直播场景对清晰度要求很高，但却可以接受较高的延时。所以我们在实践过程中给予了不同的策略支持，就好比做不同口味的饭菜来满足不同人的口味。

以上就是网易云信在构建音视频引擎过程中的一些实践经验，在此分享给大家，希望能给有兴趣的同学参考。

从0到1 构建实时音视频引擎相关推荐

技术系列课｜从0到1 构建实时音视频引擎
随着5G和AI时代的到来,在线实时互动在越来越多的场景中被使用,支撑这一功能实现的关键性技术--RTC也受到了空前的关注.本节技术系列课,来自网易云信的讲师将以做菜的过程为比喻,深入浅出地讲述如何从0 ...
anyRTC加持AI，打造下一代实时音视频引擎
前言: 伴随着音视频技术高速发展,直播行业异军突起,在社交.娱乐.电商.教育.医疗等领域高歌猛进.当下,5G和AI时代已至,音视频技术已经上升到一个全新的高度,新场景.新应用.新标准也必将出现.any ...
实时音视频服务的“既要、又要、还要”
采访讲师|庄泽森声网Agora架构师,毕业于复旦大学电子工程系,专业方向是信号处理和估计理论,毕业后一直从事音视频相关算法研究和优化.2014年加入声网后,专注于实时音视频方案的架构和实时网络加速相 ...
【11月7日】实时音视频技术专场来袭！就在本周六！
RTC(Real-time Communications),直译或者广义指实时通信,狭义一般称为实时音视频,在这次全球大爆发的新冠肺炎疫情中,视频会议.视频通话.远程办公.远程上课.远程开会.远程演唱 ...
【金猿产品展】拍乐云——新一代实时音视频云服务，构建云上的每一次美好互动...
拍乐云产品本项目由拍乐云投递并参与"数据猿年度金猿策划活动--2021大数据产业创新服务产品榜单及奖项"评选. 数据智能产业创新服务媒体 --聚焦数智 · 改变商业拍乐云提供的 ...
即构科技：解决行业痛点，以MSDN为基础构建全球实时音视频通信云
点击上方"LiveVideoStack"关注我们近日,LiveVideoStack很荣幸地采访到了即构科技RTC后台技术总监--肖潇.在访谈中我们了解到即构科技在构建全球实时音视 ...
如何构建全球实时音视频云及其海外网络传输优化
点击上方"LiveVideoStack"关注我们全球不同国家和地区的网络基建水平参差不齐,如何利用有限的网络资源提供更高质量的音视频通话体验是音视频服务商必须面对的挑战.在此次L ...
实时音视频聊天中超低延迟架构的思考与技术实践
1.前言从直播在线上抓娃娃,不断变化的是玩法的创新,始终不变的是对超低延迟的苛求.实时架构是超低延迟的基石,如何在信源编码.信道编码和实时传输整个链条来构建实时架构?在实时架构的基础之上,如果通过优 ...
解密华为云原生媒体网络如何保障实时音视频服务质量
随着5G和AI的发展,内容表达视频化成为了当今的主流,很多行业对视频分发有非常旺盛的需求.我们非常荣幸地请到了华为云的资深视频架构师黄挺,为大家介绍基于互联网的实时音视频服务所面临的挑战,分享华为云原 ...

从0到1 构建实时音视频引擎

从0到1 构建实时音视频引擎相关推荐

最新文章

热门文章