作者 | Tsahi Levent-Levi
翻译 | Alex
技术审校 | 刘连响
年终盘点#006#——WebRTC
本篇为WebRTC技术专家Tsahi Levent-Levi发布在BlogGeek.me上的文章,我们翻译了其中部分内容发布在LiveVideoStack的公众号上。感谢Tsahi的授权。
2022年WebRTC的五大趋势与我们之前所见稍有不同:有聚焦在规模上的,有探讨新要求的,还有关注新市场的。
规模和性能
希伯来语中有句谚语:“尽快开始,缓慢发展”。这句谚语形象地描绘了WebRTC现在的处境。
WebRTC在2021年明显就是这样发展的。规模依然非常重要,而2022年规模将延续其重要地位。
在2021年11月份的Kranky Geek活动上,谷歌工程师分享了他们在过去一年所做的工作。下面是一张围绕性能优化的幻灯片。可以看到,他们不断努力,同时进行多项任务。其中很多任务已经完成,但还有更多工作要做。
这些改进的目的都是为了向加入单一对话的更多参与者提供更好的可扩展性。我们在最近几个月跟踪到的硬件编解码bug在2022年将继续存在。
同时,我们看到很多公司为了扩展它们的服务而投资基础设施。
2022将延续2021。
新技术
大量新技术现在开始成熟,这些技术可以使供应商充分利用WebRTC的价值。比如,在Kranky Geek上,我们就花了很多时间来介绍这些技术,并了解各个供应商对这些技术的初步使用。
WebAssembly
WebAssembly很可能是WebRTC技术中的最佳选手。
WebAssembly 可提高Web 代码性能并支持跨语言编译。对于WebRTC来说,主要好处是将 WebAssembly 用于媒体操纵的机器学习任务。从噪声抑制,到背景替换和视频特效,再到视频灯光效果。 这些都可以用WebAssembly实现。
希望越来越多的供应商使用WebAssembly,也希望WebAssembly能支持更多特性。
WebTransport&WebCodecs
对WebRTC不满意?还有WebTransport和WebCodecs。
WebTransport和WebCodecs(一起)理论上可以实现媒体的编解码以及从服务器发送或接收媒体。
细节决定成败,虽然WebTransport和WebCodecs还没有达到可以取代WebRTC的受欢迎程度,但它们却非常有前景。
我们将看到越来越多的供应商试验这些技术,并且将它们和WebRTC一起使用,这很合理。一年以前我就提出过这点,当时谷歌正在拆分部分WebRTC。
谷歌自己对这些新技术热情满满,因此人们也担心它在几年后是否会对WebRTC失去兴趣。
AV1
然后是新的编解码器。
AV1在2018年推出。2018年以来,显然有人在推动AV1成为WebRTC的解决方案(不完全是)。事实上,到了2021年底,AV1仍然没有对WebRTC产生重要影响。并不是因为AV1不够优秀,而是因为推出新的编解码器需要花费很长时间,尤其是视频编解码器。
不过,等待快要结束了。AV1即将进入WebRTC,我们将在2022看到它的应用,虽然仍有限制,但它最终会变得有趣并增加与WebRTC的相关性。
新的基于机器学习的音频编解码器(想想Lyra)还需要一点时间。对于它应该是哪种音频编解码器目前还没有达成共识。AV1就不会出现这种问题——我们已经知道它将会是下一个统一共识下的编解码器。
WebRTC基础设施、超扩展和SD-WAN
设计和部署WebRTC的方式正在发生变化。平日里所使用的mesh/mix/route 解决方案依然存在。很多人也会选择混合方法。最近的讨论和关注都围绕硬件、硬件部署以及如何准确转发数据包。声网也许是第一家公开大规模使用此技术的公司,并将其作为更好的解决方案进行宣传。2021年,我们看到Subspace 和Cloudflare宣布部署超过100个区域数据中心用于托管TURN服务。
我在2021年的Workshop中已将基础设施列为WebRTC所面临的挑战之一。2022年,这一话题将变得更加有趣。Anycast将作为供应商技术加入到竞争中。
我们现在还无法确定2022年哪些技术将更受青睐。这些技术在全球十几个地区使用时,是否会带来真正价值上的差异化以及质量上的可观提升?这么做还值得吗?尤其是在大型云厂商每隔一个月就推出新的数据中心的情况下。
直播
从特性和技术到用例。
通过WebRTC实现直播。
其他技术也可以实现直播,但是它们都没有WebRTC高效,而且可以在浏览器中运行。
人们越来越习惯使用视频沟通。新冠疫情催生了很多新的远程交流方式。人们渴望以直播、实时的方式互动。2秒钟的延迟也许还过得去,但是次秒级的延迟会更棒!我们将看到越来越多的供应商使用WebRTC达到次秒级的延迟。对于很多用例来说,低延迟还有更大的发展空间。但是要达到瞬时延迟,那就需要更多WebRTC的使用。至少要等到WebTransport 和WebCodecs技术成熟以后。
从2D到元宇宙
每个人都在重新思考未来通信方式,这些方式可不是过去20多年间我们所依赖的那种对着摄像机讲话。
我看到的两个终极方向:
- 将视频会话置于2D和3D的合成环境中,其中用户的Avatar可以自由出入。
- 在Facebook和微软引领下的元宇宙(至少现在如此)。
2022年,我们还将看到更多关于元宇宙的讨论。现在,已经推出了很多不同的元宇宙体验,其中哪些体验是昙花一现,而哪些又将保留下来,将会成2022年最值得关注的趣事。
WebRTC市场力量
当我们迈入2022年,很重要的一件事就是要知道哪些公司是WebRTC的主要参与者和主要市场力量。
大科技:FAAMG 和 WebRTC
这些最大的科技公司引领WebRTC的发展并对其做出决策,每家公司都有自己的动机:
- 谷歌:谷歌是浏览器中WebRTC的最大用户,它拥有libwebrtc、Chrome、Google Meet和Stadia等使用WebRTC的工具。大部分情况下,谷歌的需求会直接影响WebRTC。
- 微软:微软拥有Skype、Azure通信服务和Teams。它们都使用WebRTC(至少在网页浏览器中)。微软也在围绕WebRTC推动它自己的方案(虽然大部分方案目前只能为Windows操作系统和Office产品优化某些特定区域)。
- Apple: Apple对WebRTC的反应似乎有些迟钝,看起来它是被迫卷入而非主动加入WebRTC。FaceTime网页版应该是目前为止Apple最为公开支持WebRTC的举动。Apple使用libwebrtc却对它毫无贡献。即使所有人被Safari糟糕的WebRTC实现所“挟持”,也只有Apple自己才能改进这一点。
- 亚马逊:亚马逊正在悄悄增加使用WebRTC的服务和产品。这些服务和产品包括Kinesis、Chime SDK、Amazon Connect和Alexa等。亚马逊似乎满足于当下,并不太关心WebRTC标准及其在特定浏览器中的实现。
- Facebook:Facebook拥有Messenger、Instagram和Whatsapp,它也许是拥有最多WebRTC流量的公司。
Intel也可以列入以上名单中,这家公司正在推动WebRTC的硬件编码(这件事通常被硬件供应商所忽略)。
在2022年,以上这些公司都将成为WebRTC的塑造者。它们将决定是否听取外部反馈并将这些反馈加入到自己的产品路线图中——这将影响到WebRTC生态中的每一个人。
对WebRTC不感兴趣的Twilio
正如我在《关于WebRTC发展的担忧和思考》中所述,Twilio对WebRTC真的没有那么看重。Twilio无法通过WebRTC获得太多收益,所以将关注点转移到其他地方。不过Twilio的video-js repo确实是一个很好的错误报告来源(Twilio和Vonage在这方面领先于大部分公司)。
面对处于头部的CPaaS供应商(如Twilio),其他供应商的选择包括:
- 可以在WebRTC和视频领域努力开拓市场。
- 或者也可以尝试与Twilio在WebRTC之外的领域竞争。
但对于那些想要使用CPaaS的公司而言,这并不是最佳环境。某种程度上,对于那些想要拥有CPaaS的公司来说,以上选择也并不高效。
同时它还削弱了 CPaaS 供应商拥有的(或想要拥有?)对 WebRTC 发展方向的影响力。这些供应商的背后聚集了成千上万家公司、用例和需求,如果它们的声音越来越多地被外界听到,那就再好不过了。这也是我认为UCaaS会在创新方面超越CPaaS的部分原因。
Zoom所面临的问题
Zoom会是例外吗?
Zoom并没有真正使用WebRTC,但它却影响了WebRTC周围的一切。
1. 使用WebRTC的供应商最终常常会面临和Zoom的市场竞争:
- 在很多垂直和细分市场的竞争。
- 作为新冠疫情中远程交互的典型代表,Zoom的优势是广为人知且已经被很多公司使用。
2. WebRTC中的性能与Zoom性能比对:
- Zoom推出的Gallery View最多可显示49位参会者。
- WebRTC在Opus编码中引入REDundancy。
- 二者的CPU使用等。
3. Zoom认为WebCodecs+WebTransport+WebAssembly会成为WebRTC的替代者,并在寻求与其他公司的差异化:
- 其他人也会走上这条路吗?
- 谷歌会不会也在某个时刻接受这种替代,并对WebRTC失去兴趣呢?
- 时间会证明一切。
虽然Zoom并不是WebRTC生态中的一员,但它将在很大程度上影响WebRTC市场。
WebRTC中的合作性竞争
合作性竞争随处可见。我们看到很多竞争者走到一起进行合作,尤其在标准化组织中,供应商们都在努力营造一个令所有人感到愉悦的好环境。在WebRTC中强制实现视频编解码器这一决策就是一个很好的例子。
现在,越来越多的公司之间直接进行合作——一方面相互竞争,另一方面又相互合作。微软在谷歌的libwebrtc中改进了屏幕分享这一功能(在决定Edge采用Chromium之后),Intel助力AV1硬件编码,RingCentral和8x8推动在WebRTC中向Opus添加RED等等。
众所周知,我们不能对WebRTC的实现袖手旁观,应该发起更多的主动合作。供应商应该公开投资更多的开源实现,而不只是开发自己的专有代码。
这只是我一厢情愿的想法,但WebRTC已经走到了一个转折点,整个社区和生态需要通力合作才能实现WebRTC的下一步发展。
更多拓展内容:
https://bloggeek.me/webrtc-in...
https://webrtchacks.com/red-i...
https://bloggeek.me/a-bluepri...
https://bloggeek.me/why-cpaas...
https://bloggeek.me/managed-w...
https://bloggeek.me/webrtc-un...
致谢
本文已获得作者Tsahi Levent-Levi授权翻译和发布,特此感谢。
原文链接:https://bloggeek.me/webrtc-tr...
更多年终技术盘点:
扫描图中二维码了解大会更多信息
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。