共计 3637 个字符，预计需要花费 10 分钟才能阅读完成。
在与同行交换过程中，发现很多同行对 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。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实际技术文章，在这里与音视频畛域一流工程师交换切磋。
