在与同行交流过程中，发现很多同行对 WebRTC 改动太多，导致无法升级 WebRTC 版本。而 WebRTC 开源社区的快速迭代，让他们感到欣喜又焦虑：开源社区的迭代效果，是不是超过了他们对 WebRTC 的优化效果？我们针对特定场景优化 WebRTC 时，怎么紧跟 WebRTC 开源社区通用的优化？
简言之，把 WebRTC 作为 Framework 使用，而不是 Library，即：WebRTC 仓库轻量化，核心模块插件化。
详细的，WebRTC 作为 Framework 串联核心模块；核心模块既可以以插件形式使用我们的实现，也可以 Fallback 到 WebRTC 的默认实现。目的是减少 WebRTC 冲突的可能性，提高升级 WebRTC 的敏捷性。
目标：一年升级一次 WebRTC，一次花费一个人月。
WebRTC 的核心模块，包括：
WebRTC 在长期的演进中，API 已经具备了作为 Framework 的大部分能力。红色的核心模块，已经基本可以插件化，如下面的 API：
light-rtc 作为 WebRTC 仓库，我们需要保留两个 Remote，一个是 Alibaba，一个是 Google 。升级 WebRTC 时，我们从 Google 上 Pull 最新代码， 解决冲突，然后 Push 到 Alibaba 。
对插件化的模块，我们需要放到单独的仓库 lrtc-plugin 里，这样有两个好处：
对 lrtc-plugin 依赖的第三方库，也应该以单独的仓库存在，并保留两个 Remote，比如 Opus，这样，即使修改了 Opus 源码，仍然可以像升级 light-rtc 一样，方便的单独升级 Opus 版本。
音频编解码器、视频编解码器，是我们最常优化的部分之一：
这部分插件化是相对简单的，只需要实现自己的 [Video|Audio][Encoder|Decoder]Factory 即可。以 Simulcast 为例，在自己实现的 VideoEncoderFactory 里，先用 WebRTC 原始的 VideoEncoderFactory，创建多个 Encoder 对象，然后封装到一个 Simulcast Encoder 里。
很可惜，ADM(Audio Device Module)没有提供检测设备插拔的功能，需要增加 Callback 接口。
另外，虽然 WebRTC 支持样本数量的监控，但是当前只用于打印日志，如果想在此基础上做更多事情（如：发现采集样本为 0 时，重启采集），则单独做一个 AudioSampleMoniter 的类，比较有利于扩展。
ADM 是一个适配难点，相信是困扰 RTC 同行的共同难题。不同操作系统、不同机型，都可能有不一样的问题。例如：
这些修改大部分属于 Bugfix，参考“Bugfix”章节。
APM(Audio Processing Module)可能是 light-rtc 相对难处理的部分。
APM 与 NetEQ 一起，可能是 WebRTC 核心模块中，开源价值最大的部分。在我对 APM 有限的认知里，对 APM 常见的优化可能有：
下图是 WebRTC APM 内部模块的数据流程图：
从图中可以看出，APM 其实也为插件化做了准备，但是只在近端信号的尾部、远端信号的头部。从 APM 构造函数上也可以看出来：
滤波 /均衡，可以方便的实现一个 CustomProcessing 的 render_pre_processor 。
其他的优化，遵循轻量化 /插件化的理念，没有现成的插件接口，我们可以创造新的插件接口，如啸叫抑制，以及 AECM 优化的部分算法。
但 APM 仍然会有很多没办法插件化的，只能修改 light-rtc 仓库，如 AECM Double Talk 优化等。
AM(Audio Mixer)的插件化，可以在不修改 light-rtc 的基础上，玩出很多花样：
FEC(Forward Error Correction)，常见的修改：
CC(Congestion Control)，包含两个方面，一个是 CC 算法本身，一个是 CC 关联模块。
算法本身，可以用不同的算法实现，如 WebRTC 默认的 goog_cc，也可以是 BBR，甚至是满足 WebRTC::NetworkControllerFactoryInterface 接口的外部插件。
关联模块：
Android 、iOS 、Mac，WebRTC 都提供了默认的实现，虽然有少量 Bug，但是基本满足需求。
Windows 平台，早期 WebRTC 提供了 D3D 的实现，最新版已经剔除，我们可以在 lrtc-plugin 仓库实现自己的 D3D，或者其他的渲染，如 QT OpenGL 。
WebRTC 并没有提供视频前处理（如：美颜）、后处理（如：超分辨率）的接口，但是我们完全可以像 rtc::BitrateAllocationStrategy 一样，创造 VideoProcessInterface 接口, 并在 lrtc-plugin 仓库里实现。
让 VideoProcessInterface 同时继承 Sink 和 Source 接口，可以方便的把多个对象串联起来。
其他核心模块，如 JitterBuffer 、ICE 等，目前接触的主要是 Bugfix，还没有发现自己定制重写的必要。
Bugfix，往往只能修改 light-rtc 仓库。一方面，是尽量把 Bugfix 内聚成函数，减少对已有代码的修改；另一方面，尽量把 Bugfix 贡献到开源社区(Issue Tracker)，既为开源社区做了贡献，也彻底避免了升级的冲突。
贡献到开源社区，往往比想象的要复杂，但也更能锻炼人。在特定场景，往往只用了 WebRTC 一部分能力，如视频 JitterBuffer，一个 Bugfix 可能只考虑到了 H264，贡献到开源社区时，则需要同时兼顾 VP8/VP9，甚至是将来的 AV1 。在这个过程中，Google 工程师会在 Code Review 中与你亲密切磋，其实是非常好的锻炼机会，进一步提高对 WebRTC 的认识。
WebRTC m74 源码
RSFEC：
CC
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。