在与同行交换过程中，发现很多同行对 WebRTC 改变太多，导致无奈降级 WebRTC 版本。而 WebRTC 开源社区的疾速迭代，让他们感到欣慰又焦虑：开源社区的迭代成果，是不是超过了他们对 WebRTC 的优化成果？咱们针对特定场景优化 WebRTC 时，怎么紧跟 WebRTC 开源社区通用的优化？
作者：阿里云智能技术专家 熊金水
理念
简言之，把 WebRTC 作为 Framework 应用，而不是 Library，即：WebRTC 仓库轻量化，外围模块插件化。
具体的，WebRTC 作为 Framework 串联外围模块；外围模块既能够以插件模式应用咱们的实现，也能够 Fallback 到 WebRTC 的默认实现。目标是缩小 WebRTC 抵触的可能性，进步降级 WebRTC 的敏捷性。
指标：一年降级一次 WebRTC，一次破费一个人月。
架构
模块拆解
WebRTC 的外围模块，包含：
音频
- ADM 采集、APM、ACM 编码；
- NetEQ 与解码、AM、ADM 渲染；
视频
- 采集、编码；
- JB、解码、渲染；
通用
- RTP 打包与解包、FEC 生成与复原、CC 与 Pacer、ICE、SDP 信令等。
WebRTC 在长期的演进中，API 曾经具备了作为 Framework 的大部分能力。红色的外围模块，曾经根本能够插件化，如上面的 API：
仓库治理
light-rtc 作为 WebRTC 仓库，咱们须要保留两个 Remote，一个是 Alibaba，一个是 Google。降级 WebRTC 时，咱们从 Google 上 Pull 最新代码，解决抵触，而后 Push 到 Alibaba。
对插件化的模块，咱们须要放到独自的仓库 lrtc-plugin 里，这样有两个益处：
- 对 light-rtc 仓库改变少，缩小与 Google 抵触的可能性；
- 更重要的，让每个开发同学，在每次改变前，更被动、更无意识的思考，放到哪个仓库更适合，否则容易惯性思维，间接改变 light-rtc。
对 lrtc-plugin 依赖的第三方库，也应该以独自的仓库存在，并保留两个 Remote，比方 Opus，这样，即便批改了 Opus 源码，依然能够像降级 light-rtc 一样，不便的独自降级 Opus 版本。
模块
Codec
音频编解码器、视频编解码器，是咱们最常优化的局部之一：
- 新的编码工（AV1/SCC/ROI 等）优化视频品质和带宽；
- 分辨率自适应，使不同能力（编码能力、发送带宽等）的发送端，发送不同分辨率的码流；
- Simulcast，为不同能力（解码能力、显示能力、接管带宽等）的接收端，提供不同分辨率码流；
- SVC，提供时域 / 空域分层；
- 新的视频解码实现，躲避 Mac 硬解卡死等问题；
- 新的音频编码器，适配商用接收端；
- ……
这部分插件化是绝对简略的，只须要实现本人的 [Video|Audio][Encoder|Decoder]Factory 即可。以 Simulcast 为例，在本人实现的 VideoEncoderFactory 里，先用 WebRTC 原始的 VideoEncoderFactory，创立多个 Encoder 对象，而后封装到一个 Simulcast Encoder 里。
ADM
很惋惜，ADM(Audio Device Module) 没有提供检测设施插拔的性能，须要减少 Callback 接口。
另外，尽管 WebRTC 反对样本数量的监控，然而以后只用于打印日志，如果想在此基础上做更多事件（如：发现采集样本为 0 时，重启采集），则独自做一个 AudioSampleMoniter 的类，比拟有利于扩大。
ADM 是一个适配难点，置信是困扰 RTC 同行的独特难题。不同操作系统、不同机型，都可能有不一样的问题。例如：
- Mac 3.5mm 耳机插拔时，偶然解体；
- Mac 获取的设施 ID 在插拔后发生变化，不能做长久化；
- 联想 X1 电脑，屡次插拔后，整个 Audio 后盾服务生效；
- 某些 Windows 机型采集不到声音；
- 某些手机采音权限问题；
- ……
这些批改大部分属于 Bugfix，参考“Bugfix”章节。
APM
APM(Audio Processing Module) 可能是 light-rtc 绝对难解决的局部。
APM 与 NetEQ 一起，可能是 WebRTC 外围模块中，开源价值最大的局部。在我对 APM 无限的认知里，对 APM 常见的优化可能有：
- 混音后的远端信号，做滤波 / 平衡解决。这是业界不少音频算法的必要条件；
- 利用 Android 手机个性，优化 AECM，尤其是 Double Talk 时的成果；
- 啸叫检测与克制；
- 利用机型个性，优化 AGC，进步语音音量;
- ……
下图是 WebRTC APM 外部模块的数据流程图：
从图中能够看出，APM 其实也为插件化做了筹备，然而只在近端信号的尾部、远端信号的头部。从 APM 构造函数上也能够看进去：
滤波 / 平衡，能够不便的实现一个 CustomProcessing 的 render_pre_processor。
其余的优化，遵循轻量化 / 插件化的理念，没有现成的插件接口，咱们能够发明新的插件接口，如啸叫克制，以及 AECM 优化的局部算法。
但 APM 依然会有很多没方法插件化的，只能批改 light-rtc 仓库，如 AECM Double Talk 优化等。
AM
AM(Audio Mixer) 的插件化，能够在不批改 light-rtc 的根底上，玩出很多花色：
- 播放本地文件；
- 借助语音检测算法，优化语音排序，从而选出更精确的语音做混音；
- Mono 变成 Stereo，借助 HRTF，能够在多方同时谈话时进步谈话人辨识度和可懂度；
- 对 RTP 计划的回放，倍速回放时变速不变调；
- ……
FEC
FEC(Forward Error Correction)，常见的批改：
- 调参，如冗余度、MaxFrames、Table 类型，包含固定参数和动静自适应调参两类，已有的插件接口 WebRTC::FecControllerFactoryInterface 即可满足;
- RSFEC，须要发明新的插件接口；
- Opus Inband FEC。WebRTC 动静配置的 Opus FEC 参数，不能很好的解决弱网时声音卡顿问题。这时，一个方法是把 Opus 独立成仓库，间接批改 Opus 编码器。
CC
CC(Congestion Control)，蕴含两个方面，一个是 CC 算法自身，一个是 CC 关联模块。
算法自身，能够用不同的算法实现，如 WebRTC 默认的 goog_cc，也能够是 BBR，甚至是满足 WebRTC::NetworkControllerFactoryInterface 接口的内部插件。
关联模块：
- 带宽调配：不同场景可能不一样，如视频会议里，须要“保音频、保屏幕”。能够通过 rtc::BitrateAllocationStrategy 实现插件化。
- Pacer 调优：对于屏幕内容，I 帧往往十分大，WebRTC 的 2.5 倍的发送带宽，会导致微小的首帧工夫。具体解法见仁见智。
……
VideoRender
Android、iOS、Mac，WebRTC 都提供了默认的实现，尽管有大量 Bug，然而根本满足需要。
Windows 平台，晚期 WebRTC 提供了 D3D 的实现，最新版曾经剔除，咱们能够在 lrtc-plugin 仓库实现本人的 D3D，或者其余的渲染，如 QT OpenGL。
VideoProcess
WebRTC 并没有提供视频前解决（如：美颜）、后处理（如：超分辨率）的接口，然而咱们齐全能够像 rtc::BitrateAllocationStrategy 一样，发明 VideoProcessInterface 接口, 并在 lrtc-plugin 仓库里实现。
让 VideoProcessInterface 同时继承 Sink 和 Source 接口，能够不便的把多个对象串联起来。
其余 & Bugfix
其余外围模块，如 JitterBuffer、ICE 等，目前接触的次要是 Bugfix，还没有发现自己定制重写的必要。
Bugfix，往往只能批改 light-rtc 仓库。一方面，是尽量把 Bugfix 内聚成函数，缩小对已有代码的批改；另一方面，尽量把 Bugfix 奉献到开源社区 (Issue Tracker)，既为开源社区做了奉献，也彻底防止了降级的抵触。
奉献到开源社区，往往比设想的要简单，但也更能锤炼人。在特定场景，往往只用了 WebRTC 一部分能力，如视频 JitterBuffer，一个 Bugfix 可能只思考到了 H264，奉献到开源社区时，则须要同时兼顾 VP8/VP9，甚至是未来的 AV1。在这个过程中，Google 工程师会在 Code Review 中与你密切切磋，其实是十分好的锤炼机会，进一步提高对 WebRTC 的意识。
参考
WebRTC m74 源码
RSFEC：
- WebRTC RSFEC 详解和分析；
- ARTP 技术探秘之：WebRTC 中反对 RS FEC。
（以上两篇文章之后将会在本号推送）
CC
- Pantheon：GitHub；Paper；Summary of Results。
- NADA，GCC，SCReAM 性能比拟：Blog；Paper；GitHub。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实际技术文章，在这里与音视频畛域一流工程师交换切磋。