共计 6491 个字符，预计需要花费 17 分钟才能阅读完成。
本文依据霍锴（七牛云 音视频客户端架构师）于 2021 年 6 月 26 日举办的「ECUG Meetup 第 1 期 | 2021 音视频技术最佳实际·杭州站」上的分享整顿而成。
获取「讲师完整版 PPT」，请增加 ECUG 小助手微信（微信 ID：ECUGCON）并备注「ECUG PPT」。其余讲师的分享也将于后续陆续放出，敬请期待。
以下为分享注释：
大家好，我先进行一个自我介绍。我叫霍锴，是七牛云的音视频客户端架构师，2017 年退出七牛云，主导和参加开发了短视频、推流、播放器等多个音视频相干 SDK，目前工作次要是集中在实时音视频 SDK 的设计和研发，次要精力还是在客户端上。
这是我明天为大家讲的内容：
1）实时音视频 SDK 的技术与挑战
2）七牛实时音视频 SDK 的架构
3）实时音视频 SDK 的实践经验
简略来说就是分享在开发实时音视频 SDK 的过程中，咱们常常遇到的问题，以及怎么去做优化，能够说是咱们的一些实践经验。
一、实时音视频 SDK 的技术与挑战
明天是音视频专场，置信在座各位必定对音视频技术都有所理解或者是有所教训的，然而不晓得有多少人已经做过或者设计过 SDK，它其实也有其独特的挑战。
1. 客户对实时音视频 SDK 的诉求
七牛云作为一家提供技术服务的公司，常常会听到很多的客户声音，比方客户常常会问，视频的码率应该配置多少，某个接口调用之后为什么没有成果，第三方美颜如何接入等问题。
此外，一些客户在应用过程中有可能遇到一些异样的景象，比如说呈现花屏、黑屏、退出房间失败等等。
还有就是，客户也常常会给咱们提出一些性能需要，比方有些客户想同时公布摄像头和手机屏幕上两局部的视频内容，或者想获取每路的视频或音频帧数据等等。
遇到这些问题之后，咱们依照发现问题、剖析问题和解决问题的步骤，一点一点的把问题解决。首先让咱们静下心来好好去剖析一下，这些问题背地的诉求是什么。简略来说，咱们总结了三点：
1）接入者的音视频技术水平参差不齐，然而无一例外，都心愿可能疾速接入。
咱们不能强制要求客户的音视频技术要达到某一个高度能力接入这个 SDK，所以咱们只能给本人提要求：SDK 要设计得极为简略易用，这样能力让用户尽可能快地去接入。
2）接入者的应用场景和环境复杂多变，然而对音视频的体验要求都很高。
比方，视频会议场景对于提早的要求很高，超过 300 毫秒就能会很显著地感知到对方谈话有所提早。而在直播的场景下，用户则对清晰度的要求很高，一个主播可能会面对海量观众，主播的画面不清晰，对观众的影响是十分大的。再比方，同样是直播场景，户外直播和室内直播是两个截然不同的环境，但咱们都要保障在现有环境下可能给用户最好的音视频体验。
3）接入者须要“安全感”，对服务的稳定性、监测伎俩、排障能力都有要求。
接入者须要实在地感知到线上用户的应用状况，包含音视频的实时品质，产生的谬误或异样，另外就是一旦呈现了问题，无论是 SDK 的起因还是用户应用姿态的起因，都要可能迅速排障，把影响减到最低。
2. 实时音视频 SDK 的外围要求
依据客户的诉求，咱们能够去定义一款优良的实时音视频 SDK 的规格：
1）接口简略，边界清晰。
不能让接入者调用咱们 API 的时候有不置可否的感觉，接口肯定要简略清晰，从而不便用户调用。
2）扩展性强，生态化好。
在 SDK 的根底上能不便地扩大性能，比方高级美颜、人脸审核、语音转文字等。咱们的做法是在 SDK 下层依据不同的场景，为用户做了不同的插件，最大水平中央便用户进行扩大。
3）按场景进行形象和优化，扩大性能。
方才曾经提到，对于视频会议和直播场景，音视频品质的要求是有所区别的，所以咱们应该针对不同的场景进行优化，并尽可能地提供笼罩该场景的外围性能。
4）首帧、卡顿、提早、回声等音视频体验极致优化。
这些都是影响音视频体验的最外围的指标，所以在 QoS 的优化方面，咱们无论做多少致力都不会过分。
5）服务稳固牢靠，丰盛的数据埋点，可视化的数据监测与剖析。
可靠性是一个技术服务的前提，而数据化又是保障可靠性的前提。
3. 实时音视频 SDK 的技术难点
说了这么多，大家也可能感知到，想把一款实时音视频 SDK 做好还是十分难的，更加具体的来说，它的技术难点都有什么呢？我略微给大家列举了一些：
包含音视频的采集、编码、传输。还有视频解决和音频解决，比方美颜滤镜和混音。以及弱网的优化，数据的打点上报，解体剖析，音频的 3A 算法等等。
除此之外，还有兼容性的适配，性能的优化等方面。这些都是咱们须要面对和解决的技术难点，前面我会在第三局部实际篇为大家简略介绍一下咱们的一些教训。
二、七牛云实时音视频 SDK 的架构
接下来，我为大家介绍一下七牛云实时音视频 SDK 是怎么设计的。首先，让咱们看一下七牛云实时音视频 SDK 的迭代历程。
2018 年，咱们上线了 1.0 版本，反对外围的音视频通信性能，之后，咱们发现越来越多的客户都会在房间内公布不止一路的流，比方屏幕内容和摄像头采集的内容，所以咱们就在 2.0 的版本上反对了多 track，也就是反对用户公布多路流的计划。再往后到 3.0，咱们想做到让每个人在以后的网络环境下可能体验到的音视频的体验是最好的，所以咱们又做了大小流策略。
另外，咱们不仅只是做了 SDK 的失常迭代，同时还公布了一些配套的解决方案，比方视频会议计划、互动直播计划、在线面试计划。除此之外，还提供了一些插件，比方美颜插件，不便客户去接入美颜 SDK，还有马上要推出的白板插件，不便教育场景的用户不便接入。
1. 七牛云实时音视频 SDK 的模块划分
这是七牛云实时音视频 SDK 的模块划分：
最底层是咱们依赖的一些内部库，比方咱们通过 WebRTC 实现 SDK 的通信，通过 WebSocket 做信令的传输，其余还有咱们自研的像 HappyDNS，QNBeautyLib，QNEncoderLib, QNAECLib 等等。
往上面一层，咱们在底层根底之上，依照业务模块做了一些封装，其中有：
- CameraManager，负责摄像头的采集，旋转、曝光值、对焦等性能。
- MicrophoneManager，负责麦克风的采集。
- RenderProcesser，负责视频解决，比方水印，剪裁，美颜，滤镜等性能。
- AudioProcesser，负责音频解决，比方音频的重采样，混音等性能。
- RoomManager，负责退出房间、公布、订阅等外围性能。
- CrashReporter，负责在产生解体的时候，及时把堆栈信息给上报上来。
再往上的一层，咱们提供了外围的 API，另外还有高级美颜，白板等插件。
最上层的就是用户本人的业务层。
2. 七牛云实时音视频 SDK 数据流程
接下来为大家简略介绍一下七牛云实时音视频 SDK 的数据流转是怎么的。
1）采集数据：从摄像头或者屏幕去采集视频数据，从麦克风采集音频数据，采集到的视频数据有 YUV 和纹理数据，音频的 PCM 数据。
2）数据处理：采集完当前，就送到音频解决和视频解决模块，视频能够做美颜、水印、镜像等解决，音频能够做重采样和混音等解决。
3）编码：解决完之后，把数据送到视频编码器和音频编码器里，能够抉择软编或者硬编。编码后输入的是 H.264 和 Opus 数据包。
4）封装：把编码之后的这些数据送到音视频的封装模块里进行封装。
5）上传：把封装好的数据包通过 RTP 协定传输到咱们的流媒体服务器。
6）转发：流媒体服务器进行转发，把数据传输给房间内的订阅端用户。
订阅端和公布端的流程刚好是逆向的，通过解封装，解码，音视频的解决，最初渲染!
三、实时音视频 SDK 的实践经验
接下来为大家介绍一下咱们在实时音视频 SDK 的一些实践经验。
1. 可扩展性美颜插件
首先，给大家介绍的是咱们的可扩展性美颜插件。不少用户感觉在接入美颜 SDK 的时候，和音视频 SDK 的联合会很难。因为应用美颜 SDK 前可能会须要应用 OpenGL 对视频帧做一些预处理，而这一点对用户来说是比拟难的，所以咱们在美颜 SDK 和 RTC SDK 之间做了一个插件，如下图：
首先，咱们通过 RTC SDK 去做摄像头的采集，而后把采集的数据先给美颜插件这一层。美颜插件解决哪些事件呢？包含美颜特效资源的加载，或者把 OES 纹理转为 2D 纹理，又或者把摄像头采集的纹理的角度转正。咱们把通过插件解决之后、合乎美颜 SDK 规格的纹理数据输出进去，通过美颜 SDK 的美颜、美妆、滤镜、贴纸等解决，解决完之后，再把这张纹理返回到 RTC SDK 里，最初再进行预览、编码和传输。
这是咱们外部实现的细节，外部处理过程还是比较复杂的，但对外其实非常简单，对外咱们只提供最简略的只个接口，比如说 setBeauty、setSticker、setFilter 等，从而让用户缩小接入老本。
2. 大小流策略
接下来为大家介绍一下大小流的策略。
为什么要有大小流策略？咱们想做到在每个用户的网络环境下，它的音视频体验可能达到最好。举个例子：用户 A 公布了一路视频，这路视频送到编码器里会进去三路，别离是高、中、低分辨率三路视频，而后给到流媒体服务器。
流媒体服务器进行转发的时候，会依据用户 B 和 C、D 的网络带宽状况进行订阅。比如说用户 B 的网络环境比拟好，那么就间接订阅最高分辨率的这一路；D 的网络环境不好，且在弱网环境下，就订阅最低的分辨率。用户 B 的网络环境如果发生变化，一开始订阅高分辨率，之后网络环境变差了，那就主动回退到低分辨率，用户就不会呈现卡顿景象，能放弃流畅性。
3. QoS 优化
QoS 优化在整个音视频体验中是十分重要的一个位置，无论怎么强调都不过分。咱们在 WebRTC 的根底上，次要从以下方面做的优化。
1）带宽预计：带宽预计咱们次要应用了 GCC、BBR 等算法。
2）抗丢包：抗丢包方面咱们次要针对数据冗余包和丢包重传的智能联合方面做了优化。
3）平滑抖动：平滑抖动包含 Neteq、Jitterbuffer 等方面的优化。
4）带宽调配：带宽调配包含音频优先、视频分层、发送兼顾上下行等策略，或者联合用户的场景和业务来制订对应的调配策略
4. 回声打消优化
接下来我通过两个场景给大家介绍一下咱们对回声打消的优化。
下面左右两张频谱图别离代表着两种场景，每幅图都有三行数据：
第一行：原声音的声音信号图像；
第二行：用 WebRTC 自带的回声打消过滤后的图像；
第三行：用七牛云自研的回声打消过滤后的图像。
右边这张图的场景是一个人谈话的时候，背景会放一个特地嘈杂的背景音乐，咱们想要把前面的背景音乐消掉。能够看到，两头这一行还是能够看到上面有显著的间断横线，这是残留的音乐声音图像。右边第三行能够很显著地看到这些音乐声音毫无残留地被打消，打消得比拟彻底。
左边这张图是一个语音通话的场景，次要是双讲模式：A 正在谈话，突然对方 B 也开始谈话，此时咱们不心愿把 A 用户的声音消掉。但用 WebRTC 自带的回声打消算法，会把 A 的一些声音过滤掉，而从右图第三行比照看出，咱们自研的回声打消算法，“吃字”景象要好得多。
5. 兼容性优化
兼容性是咱们遇到的十分头疼的一件事件。比方在第一页上用户提出的在某个机器上呈现的花屏或者回声的景象，都能够归结到兼容性的问题上。兼容性的优化，总体来说咱们分为两种策略：
第一种策略，动静切换策略。在运行的过程中，编码器是可能动静切换的。
比方咱们设置的编码配置，在某一款手机上关上硬编码器的时候，会呈现开启失败的异样，此时咱们首先要捕捉异样，而后在用户无感知的状况上来切换为软编码器，而使得这个性能失常应用。
另一个例子，在用户应用软编码器的时候，某个手机上的编码效率极低，FPS 远远低于咱们的预期值，此时咱们也会关上硬编码器进行比照，看看哪个编码器的效率更为杰出，从而在用户无感知的时候动静切换最为适宜的编码器进行编码。
第二种策略，白名单策略。在初始化 RTC SDK 的时候，要依据探测到的一些设施，让服务器主动下发配置白名单。
比方某一款 Android 手机，在硬编场景下，分辨率如果不是 16 的倍数则会呈现花屏景象。咱们就把这些机型演绎总结，整顿到咱们的配置白名单上，当检测到是这种机型时，咱们就把分辨率调整为 16 的倍数，或者说把手机的硬编码器切换成软编码器进行编码，从而解决花屏的兼容性问题。
再举个例子，采样率为 48K 的时候，咱们发现有一些手机的回声打消成果十分不好，所以当检测到这个设施后，能够把 48K 的采样率调到 16K，或者切换成自研的回声打消策略，从而解决回声的兼容性问题。
6. 数据的采集与上报
对于数据的采集与上报模块，咱们提出了三个要求：
1）实时上报。RTC SDK，不能在整个操作完结当前再上报，而是须要实时地把一些数据给上报上来。
2）动作还原。要可能通过采集到的 SDK 日志，实在地去还原用户调用 SDK 的状况。比方在第一页有客户提到为什么调用某个接口没有成果，或者为什么进入房间会失败，咱们通过上报的日志还原常常帮用户发现其接口调用的程序，或者传递的参数谬误，从而迅速帮客户进行排障。
3）模块隔离。数据采集与上报模块，肯定不可能影响到失常的音视频通信模块，也就是不能影响主业务模块，哪怕呈现了一些异样，也要把这些异样捕捉，不能因为采集率上报呈现了问题，导致用户用不了这个服务。
咱们采集哪些内容呢？首先向大家申明，七牛云不会去采集用户的公有数据，这是相对不容许的。从大的方面来说，包含两局部内容：SDK 根底信息和音视频品质信息。
- SDK 根底信息：包含 SDK 的调用日志、谬误与解体信息、设置型号信息、SDK 外部状态等信息。
- 音视频品质信息：包含首帧工夫、实时帧率、实时码率、实时丢包率等信息。
7. 数据的监测与剖析
最初，咱们要把采集到的数据进行可视化的监测和剖析。
这张图举的例子就是我方才说的动作还原，咱们能够通过这张图很分明地看到用户调用了哪些接口、调用程序是什么样的、外部的状态又是什么样的。从初始化，到退出房间、公布、订阅，最初退出房间，在后盾咱们都能够看清楚，只有用户应用姿态谬误，咱们可能马上感知到。
这张图是某一路流实时码率的数据。
因为是实时上报，所以咱们可能看到以后的码率、帧率、丢包率、rtt 等一系列影响音视频体验的外围指标，当这些曲线有很大幅度变动的时候，咱们能够在一些门槛上做一些阀值，从而触发报警机制。
Q & A
发问：明天这个主题是对于音视频的，但咱们可能平时接触的还是摄像头的人脸识别这种比拟多，能不能用到 SDK 技术？
霍锴：咱们之后会基于实时音视频 SDK 提供一套包含人脸识别，活体检测，语音转文字等性能的插件，这套插件的背地是和咱们七牛云的智能多媒体服务相通的，从而不便用户在音视频通话的过程中去实现人脸识别等相干性能。
发问：不同的手机机型的硬编能力是不一样的，各个厂家实现的底层技术也不一样，方才您提到一些兼容性的问题，然而在理论做的时候，硬编要依赖于厂家的编码器能力，所以它在编码的时候要放弃码率的，然而硬编的一些编码器是做不到的。那么，七牛云是首先推硬编，还是优先举荐软编？
霍锴：咱们优先举荐应用硬编码，因为硬编的效率比拟好。然而有一个前提，硬编码器呈现问题的时候，须要立刻感知到，感知到之后，通过动静切换的策略，主动切换成软编。
对于七牛云、ECUG 和 ECUG Meetup
七牛云：七牛云成立于 2011 年，作为国内出名的云计算及数据服务提供商，七牛云继续在海量文件存储、CDN 内容散发、视频点播、互动直播及大规模异构数据的智能剖析与解决等畛域的核心技术进行深度投入，致力于以数据科技全面驱动数字化将来，赋能各行各业全面进入数据时代。
ECUG：全称为 Effective Cloud User Group（实效云计算用户组），成立于 2007 年的 CN Erlounge II，由许式伟发动，是科技领域不可或缺的高端前沿个人。作为行业技术提高的一扇窗口，ECUG 汇聚泛滥技术人，关注当下热点技术与尖端实际，独特引领行业技术的改革。
ECUG Meetup：ECUG、七牛云联结打造的技术分享系列流动，定位于开发者以及技术从业者的线下团聚，指标是为开发者打造一个高质量的学习与社交平台，期待每一位参会者之间常识的共创、共建和相互影响，产生新知推动认知倒退以及技术提高，通过交换促成行业共同进步，为开发者以及技术从业者打造更好的交流平台与倒退空间。
