light-rtc: 理念与实践

在与同行交流过程中，发现很多同行对 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 里，这样有两个好处：