关于WebRTC发展的担忧和思考

Posted 2022-02-02 LiveVideoStack_

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了关于WebRTC发展的担忧和思考相关的知识，希望对你有一定的参考价值。

点击上方“LiveVideoStack”关注我们

作者 | Tsahi Levent-Levi

翻译 | Alex

技术审校 | 刘连响

WebRTC

年终盘点

#004#

本篇为WebRTC技术专家Tsahi Levent-Levi发布在BlogGeek.me上的文章，我们翻译了其中部分内容发布在LiveVideoStack的公众号上。感谢Tsahi的授权。

我对WebRTC的主要担心是：一场大战蓄势待发。一方面，谷歌虽然一直引领WebRTC的发展，但作为一家大公司，它很可能没有从WebRTC中看到足够的价值。另一方面，行业中的其他人对于WebRTC的主要库libwebrtc（归谷歌所有，由其控制和维护）正在发生的事感到沮丧不已。这就导致了不同分支的产生——人们不断讨论和尝试为WebRTC这一规模宏大的项目找到更好的结构解决方案。

WebRTC差异化时代

两年以前，我们改变了主题：将“WebRTC增长时代”改为“WebRTC差异化时代”。

这一切都源于谷歌拆分了WebRTC开发工作，其中包括它在libwebrtc的内部结构，WebRTC 的开源实现以及WebRTC之外的实现方面做出的决策。结论是，任何机器学习算法都将在WebRTC之外。

其他大型供应商纷纷效仿，也在情理之中。

WebRTC巅峰时刻

我们已经到达WebRTC的顶峰了吗？

我通过Philipp了解到Chrome Platform Status网站，这里可以找到很多统计信息。该网站可以跟踪页面加载数据（包括某些 API 调用），其中许多都与 WebRTC 相关。上图是我选择的GetUserMediaPromise图表，它显示了Chrome 中加载的网页请求访问摄像头或麦克风权限的频率——通常为发起 WebRTC 会话。

在整个新冠疫情期间，我们看到 WebRTC 的使用量大幅增加，随后半年逐渐趋于稳定，但仍是疫情前的4倍。WebRTC是否能够保持这种状态还是一个疑问。Clubhouse自其强势亮相以来似乎已经停滞不前，就是一个很好的例子。

无人能预测未来一年还将发生什么：如果奥密克戎或者其他新冠变体病毒迫使人们待在家里隔离，又或者结束疫情指日可待，世界会变成什么样子？WebRTC呢？

谷歌和libwebrtc

谷歌全面控制了WebRTC，这样做有利有弊。所有浏览器通过libwebrtc支持WebRTC，libwebrtc是谷歌的WebRTC实现：

谷歌旗下的Chrome使用libwebrtc
具有Chromium（=Chrome）内核的Microsoft Edge也使用了libwebrtc
Apple Safari采用了libwebrtc并在WebKit中得以实现
Mozilla Firefox已经将libwebrtc嵌入到Firefox并需要不时更新（最近刚进行了一次重大更新）

对于WebRTC，谷歌似乎已经转向了维护模式。它改变了思维方式，聚焦于libwebrtc会给自身带来哪些好处。对于谷歌来说，这都说得通。

在为整个行业“遮风挡雨”十余年后，谷歌已开始初显倦态，尤其是内部创新不足的情况下，这种转变在所难免。

谷歌通过WebRTC为自身带来好处

这意味着，如果你的用例刚好是谷歌涉及领域或者其所需，那么祝贺你，它们将保持良好状态。如果你的用例不为谷歌所需，那就要祝你好运了。

同时，围绕WebRTC的行业中有很多心怀好意的人们，他们希望看到WebRTC不断成长，继续繁荣。他们想要为WebRTC的发展贡献出自己的力量，但这并不容易：

作为谷歌外部人士，向libwebrtc添加修改、更新和新的特性十分困难。
libwebrtc置于10~20亿台设备中，谷歌不会盲目地接受贡献。
还有需要承担的责任。Google全权负责添加进Chrome和libwebrtc中的任何特性或修改等。他们甚至会为其他人找到的安全漏洞付费。
还需要有人来做测试，这将消耗很多资源，所以谷歌需要评估这么做是否合理。
从贡献者的角度来看，根本不能做到一劳永逸：你不可能只是提交几行代码然后寄希望于这些代码会集成到libwebrtc和Chrome中。
你需要为此付出努力：解释WebRTC为什么需要这些代码、为什么由你来提交以及这些贡献如何能帮助到每个人。
让我们面对现实：我们热爱写代码而不是评论、解释或者向他人推销自己。
那么公司呢？它们想要参与其中但却不想投入人力和资金。

结果就是陷入僵局。

WebRTC开源技术突破

有很多围绕WebRTC创建的开源项目，由于新冠疫情，在最近两年发展迅速。

在过去10年中，我们看到一些开源项目脱颖而出。我知道以下列出的项目并非全部，但可以假设这些就是我在市场中最常看到的开源项目（我刻意忽略了诸如FreeSwitch和Asterisk的VoIP/SIP开源项目）。

上图显示了我对于这些顶级开源WebRTC技术的当下思考：

Kurento一直呈下降趋势。一切都始于5年前它被Twilio收购的那一刻。Twilio夺走了Kurento的知识，给它留下了一个空壳。从那时起，这个项目就回天无力了。维护该项目的团队后来开发了OpenVidu并开始了从Kurento到mediasoup的迁移。
多年来Janus一直表现强劲，但今天在新的项目中却越来越少看到它。它的发展缓慢也许是因为其他开源项目的兴起，又或许是因为meetecho团队的重点转向了NDI和OBS（WebRTC生态系统中的一个细分领域）。
Jitsi的表现很棒。8x8从Atlassian手中收购Jitsi以后，向前一步，对此开源项目进一步投资（感谢Emil Ivov，做出这个决策并不容易）。Jitsi功能丰富，而且非常适用于视频会议。视频会议之外的其他场景可能更适合其他项目。
mediasoup也是一个很棒的选择。最近几年，使用mediasoup的用户数量增长可观。我听到的大部分反馈都很正面。
Pion很有趣。它作为WebRTC的Go实现出现，现在通过多种构建在其上的开源项目，可以完成从客户端解决方案到 SFU 的所有工作。对于某些任务而说，Pion是最佳解决方案。

对于WebRTC来说，Electron是一把双刃剑

还有Electron，这是一个构建于Chromium浏览器引擎之上的PC应用框架，它在WebRTC应用程序中也很受欢迎。

但使用Electron也意味着要向它选择的Chromium+libwebrtc发布节奏妥协，或者不断深入挖掘新技术，并同时拥有这项技术。

CPaaS中WebRTC的复杂状况