點(diǎn)擊上方“LiveVideoStack”關(guān)注我們

作者 | Tsahi Levent-Levi

翻譯?| Alex

技術(shù)審校?| 劉連響

WebRTC

年終盤點(diǎn)

#004#

本篇為WebRTC技術(shù)專家Tsahi Levent-Levi發(fā)布在BlogGeek.me上的文章，我們翻譯了其中部分內(nèi)容發(fā)布在LiveVideoStack的公眾號(hào)上。感謝Tsahi的授權(quán)。

我對(duì)WebRTC的主要擔(dān)心是：一場大戰(zhàn)蓄勢待發(fā)。一方面，谷歌雖然一直引領(lǐng)WebRTC的發(fā)展，但作為一家大公司，它很可能沒有從WebRTC中看到足夠的價(jià)值。另一方面，行業(yè)中的其他人對(duì)于WebRTC的主要庫libwebrtc（歸谷歌所有，由其控制和維護(hù)）正在發(fā)生的事感到沮喪不已。這就導(dǎo)致了不同分支的產(chǎn)生——人們不斷討論和嘗試為WebRTC這一規(guī)模宏大的項(xiàng)目找到更好的結(jié)構(gòu)解決方案。

WebRTC差異化時(shí)代

兩年以前，我們改變了主題：將“WebRTC增長時(shí)代”改為“WebRTC差異化時(shí)代”。

這一切都源于谷歌拆分了WebRTC開發(fā)工作，其中包括它在libwebrtc的內(nèi)部結(jié)構(gòu)，WebRTC 的開源實(shí)現(xiàn)以及WebRTC之外的實(shí)現(xiàn)方面做出的決策。結(jié)論是，任何機(jī)器學(xué)習(xí)算法都將在WebRTC之外。

其他大型供應(yīng)商紛紛效仿，也在情理之中。

??WebRTC巔峰時(shí)刻

我們已經(jīng)到達(dá)WebRTC的頂峰了嗎？

我通過Philipp了解到Chrome Platform Status網(wǎng)站，這里可以找到很多統(tǒng)計(jì)信息。該網(wǎng)站可以跟蹤頁面加載數(shù)據(jù)（包括某些 API 調(diào)用），其中許多都與 WebRTC 相關(guān)。上圖是我選擇的GetUserMediaPromise圖表，它顯示了Chrome 中加載的網(wǎng)頁請(qǐng)求訪問攝像頭或麥克風(fēng)權(quán)限的頻率——通常為發(fā)起 WebRTC 會(huì)話。

在整個(gè)新冠疫情期間，我們看到 WebRTC 的使用量大幅增加，隨后半年逐漸趨于穩(wěn)定，但仍是疫情前的4倍。WebRTC是否能夠保持這種狀態(tài)還是一個(gè)疑問。Clubhouse自其強(qiáng)勢亮相以來似乎已經(jīng)停滯不前，就是一個(gè)很好的例子。

無人能預(yù)測未來一年還將發(fā)生什么：如果奧密克戎或者其他新冠變體病毒迫使人們待在家里隔離，又或者結(jié)束疫情指日可待，世界會(huì)變成什么樣子？WebRTC呢？

谷歌和libwebrtc

谷歌全面控制了WebRTC，這樣做有利有弊。所有瀏覽器通過libwebrtc支持WebRTC，libwebrtc是谷歌的WebRTC實(shí)現(xiàn)：

• 谷歌旗下的Chrome使用libwebrtc

• 具有Chromium（=Chrome）內(nèi)核的Microsoft Edge也使用了libwebrtc

• Apple Safari采用了libwebrtc并在WebKit中得以實(shí)現(xiàn)

• Mozilla Firefox已經(jīng)將libwebrtc嵌入到Firefox并需要不時(shí)更新（最近剛進(jìn)行了一次重大更新）

對(duì)于WebRTC，谷歌似乎已經(jīng)轉(zhuǎn)向了維護(hù)模式。它改變了思維方式，聚焦于libwebrtc會(huì)給自身帶來哪些好處。對(duì)于谷歌來說，這都說得通。

在為整個(gè)行業(yè)“遮風(fēng)擋雨”十余年后，谷歌已開始初顯倦態(tài)，尤其是內(nèi)部創(chuàng)新不足的情況下，這種轉(zhuǎn)變在所難免。

谷歌通過WebRTC為自身帶來好處

這意味著，如果你的用例剛好是谷歌涉及領(lǐng)域或者其所需，那么祝賀你，它們將保持良好狀態(tài)。如果你的用例不為谷歌所需，那就要祝你好運(yùn)了。

同時(shí)，圍繞WebRTC的行業(yè)中有很多心懷好意的人們，他們希望看到WebRTC不斷成長，繼續(xù)繁榮。他們想要為WebRTC的發(fā)展貢獻(xiàn)出自己的力量，但這并不容易：

• 作為谷歌外部人士，向libwebrtc添加修改、更新和新的特性十分困難。

• libwebrtc置于10~20億臺(tái)設(shè)備中，谷歌不會(huì)盲目地接受貢獻(xiàn)。

• 還有需要承擔(dān)的責(zé)任。Google全權(quán)負(fù)責(zé)添加進(jìn)Chrome和libwebrtc中的任何特性或修改等。他們甚至?xí)槠渌苏业降陌踩┒锤顿M(fèi)。

• 還需要有人來做測試，這將消耗很多資源，所以谷歌需要評(píng)估這么做是否合理。

• 從貢獻(xiàn)者的角度來看，根本不能做到一勞永逸：你不可能只是提交幾行代碼然后寄希望于這些代碼會(huì)集成到libwebrtc和Chrome中。

• 你需要為此付出努力：解釋W(xué)ebRTC為什么需要這些代碼、為什么由你來提交以及這些貢獻(xiàn)如何能幫助到每個(gè)人。

• 讓我們面對(duì)現(xiàn)實(shí)：我們熱愛寫代碼而不是評(píng)論、解釋或者向他人推銷自己。

• 那么公司呢？它們想要參與其中但卻不想投入人力和資金。

結(jié)果就是陷入僵局。

WebRTC開源技術(shù)突破

有很多圍繞WebRTC創(chuàng)建的開源項(xiàng)目，由于新冠疫情，在最近兩年發(fā)展迅速。

在過去10年中，我們看到一些開源項(xiàng)目脫穎而出。我知道以下列出的項(xiàng)目并非全部，但可以假設(shè)這些就是我在市場中最常看到的開源項(xiàng)目（我刻意忽略了諸如FreeSwitch和Asterisk的VoIP/SIP開源項(xiàng)目）。

上圖顯示了我對(duì)于這些頂級(jí)開源WebRTC技術(shù)的當(dāng)下思考：

• Kurento一直呈下降趨勢。一切都始于5年前它被Twilio收購的那一刻。Twilio奪走了Kurento的知識(shí)，給它留下了一個(gè)空殼。從那時(shí)起，這個(gè)項(xiàng)目就回天無力了。維護(hù)該項(xiàng)目的團(tuán)隊(duì)后來開發(fā)了OpenVidu并開始了從Kurento到mediasoup的遷移。

• 多年來Janus一直表現(xiàn)強(qiáng)勁，但今天在新的項(xiàng)目中卻越來越少看到它。它的發(fā)展緩慢也許是因?yàn)槠渌_源項(xiàng)目的興起，又或許是因?yàn)閙eetecho團(tuán)隊(duì)的重點(diǎn)轉(zhuǎn)向了NDI和OBS（WebRTC生態(tài)系統(tǒng)中的一個(gè)細(xì)分領(lǐng)域）。

• Jitsi的表現(xiàn)很棒。8x8從Atlassian手中收購Jitsi以后，向前一步，對(duì)此開源項(xiàng)目進(jìn)一步投資（感謝Emil Ivov，做出這個(gè)決策并不容易）。Jitsi功能豐富，而且非常適用于視頻會(huì)議。視頻會(huì)議之外的其他場景可能更適合其他項(xiàng)目。

• mediasoup也是一個(gè)很棒的選擇。最近幾年，使用mediasoup的用戶數(shù)量增長可觀。我聽到的大部分反饋都很正面。

• Pion很有趣。它作為WebRTC的Go實(shí)現(xiàn)出現(xiàn)，現(xiàn)在通過多種構(gòu)建在其上的開源項(xiàng)目，可以完成從客戶端解決方案到 SFU 的所有工作。對(duì)于某些任務(wù)而說，Pion是最佳解決方案。

對(duì)于WebRTC來說，Electron是一把雙刃劍

還有Electron，這是一個(gè)構(gòu)建于Chromium瀏覽器引擎之上的PC應(yīng)用框架，它在WebRTC應(yīng)用程序中也很受歡迎。

但使用Electron也意味著要向它選擇的Chromium+libwebrtc發(fā)布節(jié)奏妥協(xié)，或者不斷深入挖掘新技術(shù)，并同時(shí)擁有這項(xiàng)技術(shù)。

? ?CPaaS中WebRTC的復(fù)雜狀況

使用WebRTC CPaaS解決方案從來都不是一件容易的事。在即將到來的2022年會(huì)變得更加復(fù)雜，為什么會(huì)這樣？因?yàn)樾蝿莶⒉幻骼省?/p>

Twilio

Twilio正在向CEP（Customer Engagement Platform，客戶參與平臺(tái)）遷移。我支持它這么做，雖然這與WebRTC無關(guān)。

但涉及到WebRTC，Twilio對(duì)市場變化的反應(yīng)較慢。對(duì)Twilio而言，WebRTC更像是事后的補(bǔ)救方法。

Agora（聲網(wǎng)）

雖然聲網(wǎng)的表現(xiàn)和流量都很強(qiáng)勁，但也存在市場不確定性，比如WebRTC已到巔峰，由Clubhouse帶來的巨大增長以及政府的監(jiān)管等。我在這里特別提到聲網(wǎng)，是因?yàn)樗俏ㄒ灰患覍Ｗ⒂赗TC的CPaaS供應(yīng)商，并且是一家上市公司。

Daily

從好的方面來說，我們已經(jīng)看到對(duì)Daily的投資（B輪已達(dá)到4000萬美金）。這家公司正在成長中，致力于為開發(fā)者實(shí)現(xiàn)WebRTC。

Vonage

Vonange剛剛被愛立信收購。當(dāng)我們分析它的WebRTC CPaaS性能時(shí)，我們就要看下這家公司迄今為止的收購鏈：

TokBox → Telefonica→ Vonage → Nexmo → Ericsson

• Telefonica收購了TokBox

• 然后Vonage從Telefonica手中收購了TokBox

• 將TokBox納入Nexmo CPaaS平臺(tái)

• 然后更名為Vonage API和Vonage Video API

• 現(xiàn)在Vonage已被愛立信收購

對(duì)于Vonage API平臺(tái)的發(fā)展，我們拭目以待。

新的加入者

不斷有新的參與者（規(guī)模不一）進(jìn)入這個(gè)市場：微軟和亞馬遜紛紛加入CPaaS，尤其是使用WebRTC的CPaaS。Zoom最近也在涉足CPaaS。

像100ms這樣更加年輕的公司（成立于2020年）也參與進(jìn)來。它的API很有意思：可以使開發(fā)者提供用例的提示，或者在后臺(tái)為開發(fā)者做更多事（與傳統(tǒng)供應(yīng)商解決方案相比）。

小部件、嵌入式和預(yù)生成

CPaaS市場還在不斷增長和成熟。我們開始看到更高級(jí)別的、提供UI/UX的API。它們雖然大小、形態(tài)不一，名稱不盡相同，但開發(fā)者都能輕松使用。

應(yīng)該使用哪一家的產(chǎn)品？

明年你會(huì)選擇哪家供應(yīng)商？

這家公司會(huì)轉(zhuǎn)移業(yè)務(wù)方向，從而拋棄你嗎？

它所提供的API和各種性能真的好用嗎？

問題種種，但都很難回答。

---

更多拓展內(nèi)容：

https://bloggeek.me/webrtc-unbundling/

https://bloggeek.me/webrtc-new-era/

https://chromestatus.com/metrics/feature/timeline/popularity/1402

https://bloggeek.me/chrome-only-browser/

https://bloggeek.me/twilio-acquires-kurento/

https://bloggeek.me/8x8-acquires-jitsi-from-atlassian/

https://bloggeek.me/twilio-signal/

https://www.daily.co/blog/announcing-our-40m-series-b/

致謝

本文已獲得作者Tsahi Levent-Levi授權(quán)翻譯和發(fā)布，特此感謝。

原文鏈接：https://bloggeek.me/webrtc-trends-for-2022/

更多年終技術(shù)盤點(diǎn)：

聊聊QUIC協(xié)議的發(fā)展

中南大學(xué)張昊：我非常期待基于AI的圖像視頻編碼技術(shù)的創(chuàng)新

音視頻出海，如何乘風(fēng)破浪？

---

掃描圖中二維碼或點(diǎn)擊閱讀原文

了解大會(huì)更多信息

喜歡我們的內(nèi)容就點(diǎn)個(gè)“在看”吧！

總結(jié)

以上是生活随笔為你收集整理的关于WebRTC发展的担忧和思考的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。