2022 WebRTC发展趋势分析
點擊上方“LiveVideoStack”關(guān)注我們
作者 | Tsahi Levent-Levi
翻譯?| Alex
技術(shù)審校?| 劉連響
WebRTC
年終盤點
#006#
本篇為WebRTC技術(shù)專家Tsahi Levent-Levi發(fā)布在BlogGeek.me上的文章，我們翻譯了其中部分內(nèi)容發(fā)布在LiveVideoStack的公眾號上。感謝Tsahi的授權(quán)。
2022年WebRTC的五大趨勢與我們之前所見稍有不同：有聚焦在規(guī)模上的，有探討新要求的，還有關(guān)注新市場的。
規(guī)模和性能
希伯來語中有句諺語：“盡快開始，緩慢發(fā)展”。這句諺語形象地描繪了WebRTC現(xiàn)在的處境。
WebRTC在2021年明顯就是這樣發(fā)展的。規(guī)模依然非常重要，而2022年規(guī)模將延續(xù)其重要地位。
在2021年11月份的Kranky Geek活動上，谷歌工程師分享了他們在過去一年所做的工作。下面是一張圍繞性能優(yōu)化的幻燈片?？梢钥吹?#xff0c;他們不斷努力，同時進行多項任務(wù)。其中很多任務(wù)已經(jīng)完成，但還有更多工作要做。
這些改進的目的都是為了向加入單一對話的更多參與者提供更好的可擴展性。我們在最近幾個月跟蹤到的硬件編解碼bug在2022年將繼續(xù)存在。
同時，我們看到很多公司為了擴展它們的服務(wù)而投資基礎(chǔ)設(shè)施。
2022將延續(xù)2021。
? ?新技術(shù)
大量新技術(shù)現(xiàn)在開始成熟，這些技術(shù)可以使供應(yīng)商充分利用WebRTC的價值。比如，在Kranky Geek上，我們就花了很多時間來介紹這些技術(shù)，并了解各個供應(yīng)商對這些技術(shù)的初步使用。
WebAssembly
WebAssembly很可能是WebRTC技術(shù)中的最佳選手。
WebAssembly 可提高Web 代碼性能并支持跨語言編譯。對于WebRTC來說，主要好處是將 WebAssembly 用于媒體操縱的機器學(xué)習(xí)任務(wù)。從噪聲抑制，到背景替換和視頻特效，再到視頻燈光效果。?這些都可以用WebAssembly實現(xiàn)。
希望越來越多的供應(yīng)商使用WebAssembly，也希望WebAssembly能支持更多特性。
WebTransport&WebCodecs
對WebRTC不滿意？還有WebTransport和WebCodecs。
WebTransport和WebCodecs（一起）理論上可以實現(xiàn)媒體的編解碼以及從服務(wù)器發(fā)送或接收媒體。
細節(jié)決定成敗，雖然WebTransport和WebCodecs還沒有達到可以取代WebRTC的受歡迎程度，但它們卻非常有前景。
我們將看到越來越多的供應(yīng)商試驗這些技術(shù)，并且將它們和WebRTC一起使用，這很合理。一年以前我就提出過這點，當(dāng)時谷歌正在拆分部分WebRTC。
谷歌自己對這些新技術(shù)熱情滿滿，因此人們也擔(dān)心它在幾年后是否會對WebRTC失去興趣。
AV1
然后是新的編解碼器。
AV1在2018年推出。2018年以來，顯然有人在推動AV1成為WebRTC的解決方案（不完全是）。事實上，到了2021年底，AV1仍然沒有對WebRTC產(chǎn)生重要影響。并不是因為AV1不夠優(yōu)秀，而是因為推出新的編解碼器需要花費很長時間，尤其是視頻編解碼器。
不過，等待快要結(jié)束了。AV1即將進入WebRTC，我們將在2022看到它的應(yīng)用，雖然仍有限制，但它最終會變得有趣并增加與WebRTC的相關(guān)性。
新的基于機器學(xué)習(xí)的音頻編解碼器（想想Lyra）還需要一點時間。對于它應(yīng)該是哪種音頻編解碼器目前還沒有達成共識。AV1就不會出現(xiàn)這種問題——我們已經(jīng)知道它將會是下一個統(tǒng)一共識下的編解碼器。
WebRTC基礎(chǔ)設(shè)施、超擴展和SD-WAN
設(shè)計和部署WebRTC的方式正在發(fā)生變化。平日里所使用的mesh/mix/route 解決方案依然存在。很多人也會選擇混合方法。最近的討論和關(guān)注都圍繞硬件、硬件部署以及如何準(zhǔn)確轉(zhuǎn)發(fā)數(shù)據(jù)包。聲網(wǎng)也許是第一家公開大規(guī)模使用此技術(shù)的公司，并將其作為更好的解決方案進行宣傳。2021年，我們看到Subspace 和Cloudflare宣布部署超過100個區(qū)域數(shù)據(jù)中心用于托管TURN服務(wù)。
我在2021年的Workshop中已將基礎(chǔ)設(shè)施列為WebRTC所面臨的挑戰(zhàn)之一。2022年，這一話題將變得更加有趣。Anycast將作為供應(yīng)商技術(shù)加入到競爭中。
我們現(xiàn)在還無法確定2022年哪些技術(shù)將更受青睞。這些技術(shù)在全球十幾個地區(qū)使用時，是否會帶來真正價值上的差異化以及質(zhì)量上的可觀提升？這么做還值得嗎？尤其是在大型云廠商每隔一個月就推出新的數(shù)據(jù)中心的情況下。
直播
從特性和技術(shù)到用例。
通過WebRTC實現(xiàn)直播。
其他技術(shù)也可以實現(xiàn)直播，但是它們都沒有WebRTC高效，而且可以在瀏覽器中運行。
人們越來越習(xí)慣使用視頻溝通。新冠疫情催生了很多新的遠程交流方式。人們渴望以直播、實時的方式互動。2秒鐘的延遲也許還過得去，但是次秒級的延遲會更棒！我們將看到越來越多的供應(yīng)商使用WebRTC達到次秒級的延遲。對于很多用例來說，低延遲還有更大的發(fā)展空間。但是要達到瞬時延遲，那就需要更多WebRTC的使用。至少要等到WebTransport 和WebCodecs技術(shù)成熟以后。
從2D到元宇宙
每個人都在重新思考未來通信方式，這些方式可不是過去20多年間我們所依賴的那種對著攝像機講話。
我看到的兩個終極方向：
將視頻會話置于2D和3D的合成環(huán)境中，其中用戶的Avatar可以自由出入。
在Facebook和微軟引領(lǐng)下的元宇宙（至少現(xiàn)在如此）。
2022年，我們還將看到更多關(guān)于元宇宙的討論?，F(xiàn)在，已經(jīng)推出了很多不同的元宇宙體驗，其中哪些體驗是曇花一現(xiàn)，而哪些又將保留下來，將會成2022年最值得關(guān)注的趣事。
WebRTC市場力量
當(dāng)我們邁入2022年，很重要的一件事就是要知道哪些公司是WebRTC的主要參與者和主要市場力量。
大科技：FAAMG 和 WebRTC
這些最大的科技公司引領(lǐng)WebRTC的發(fā)展并對其做出決策，每家公司都有自己的動機：
谷歌：谷歌是瀏覽器中WebRTC的最大用戶，它擁有l(wèi)ibwebrtc、Chrome、Google Meet和Stadia等使用WebRTC的工具。大部分情況下，谷歌的需求會直接影響WebRTC。
微軟：微軟擁有Skype、Azure通信服務(wù)和Teams。它們都使用WebRTC（至少在網(wǎng)頁瀏覽器中）。微軟也在圍繞WebRTC推動它自己的方案（雖然大部分方案目前只能為Windows操作系統(tǒng)和Office產(chǎn)品優(yōu)化某些特定區(qū)域）。
Apple:?Apple對WebRTC的反應(yīng)似乎有些遲鈍，看起來它是被迫卷入而非主動加入WebRTC。FaceTime網(wǎng)頁版應(yīng)該是目前為止Apple最為公開支持WebRTC的舉動。Apple使用libwebrtc卻對它毫無貢獻。即使所有人被Safari糟糕的WebRTC實現(xiàn)所“挾持”，也只有Apple自己才能改進這一點。
亞馬遜：亞馬遜正在悄悄增加使用WebRTC的服務(wù)和產(chǎn)品。這些服務(wù)和產(chǎn)品包括Kinesis、Chime SDK、Amazon Connect和Alexa等。亞馬遜似乎滿足于當(dāng)下，并不太關(guān)心WebRTC標(biāo)準(zhǔn)及其在特定瀏覽器中的實現(xiàn)。
Facebook：Facebook擁有Messenger、Instagram和Whatsapp，它也許是擁有最多WebRTC流量的公司。
Intel也可以列入以上名單中，這家公司正在推動WebRTC的硬件編碼（這件事通常被硬件供應(yīng)商所忽略）。
在2022年，以上這些公司都將成為WebRTC的塑造者。它們將決定是否聽取外部反饋并將這些反饋加入到自己的產(chǎn)品路線圖中——這將影響到WebRTC生態(tài)中的每一個人。
? ?對WebRTC不感興趣的Twilio
正如我在《關(guān)于WebRTC發(fā)展的擔(dān)憂和思考》中所述，Twilio對WebRTC真的沒有那么看重。Twilio無法通過WebRTC獲得太多收益，所以將關(guān)注點轉(zhuǎn)移到其他地方。不過Twilio的video-js repo確實是一個很好的錯誤報告來源（Twilio和Vonage在這方面領(lǐng)先于大部分公司）。
面對處于頭部的CPaaS供應(yīng)商（如Twilio），其他供應(yīng)商的選擇包括：
可以在WebRTC和視頻領(lǐng)域努力開拓市場。
或者也可以嘗試與Twilio在WebRTC之外的領(lǐng)域競爭。
但對于那些想要使用CPaaS的公司而言，這并不是最佳環(huán)境。某種程度上，對于那些想要擁有CPaaS的公司來說，以上選擇也并不高效。
同時它還削弱了 CPaaS 供應(yīng)商擁有的（或想要擁有？）對 WebRTC 發(fā)展方向的影響力。這些供應(yīng)商的背后聚集了成千上萬家公司、用例和需求，如果它們的聲音越來越多地被外界聽到，那就再好不過了。這也是我認(rèn)為UCaaS會在創(chuàng)新方面超越CPaaS的部分原因。
? ?Zoom所面臨的問題
Zoom會是例外嗎？
Zoom并沒有真正使用WebRTC，但它卻影響了WebRTC周圍的一切。
1. 使用WebRTC的供應(yīng)商最終常常會面臨和Zoom的市場競爭：
在很多垂直和細分市場的競爭。
作為新冠疫情中遠程交互的典型代表，Zoom的優(yōu)勢是廣為人知且已經(jīng)被很多公司使用。
2. WebRTC中的性能與Zoom性能比對：
Zoom推出的Gallery View最多可顯示49位參會者。
WebRTC在Opus編碼中引入REDundancy。
二者的CPU使用等。
3. Zoom認(rèn)為WebCodecs+WebTransport+WebAssembly會成為WebRTC的替代者，并在尋求與其他公司的差異化：
其他人也會走上這條路嗎？
谷歌會不會也在某個時刻接受這種替代，并對WebRTC失去興趣呢？
時間會證明一切。
雖然Zoom并不是WebRTC生態(tài)中的一員，但它將在很大程度上影響WebRTC市場。
WebRTC中的合作性競爭
?
合作性競爭隨處可見。我們看到很多競爭者走到一起進行合作，尤其在標(biāo)準(zhǔn)化組織中，供應(yīng)商們都在努力營造一個令所有人感到愉悅的好環(huán)境。在WebRTC中強制實現(xiàn)視頻編解碼器這一決策就是一個很好的例子。
現(xiàn)在，越來越多的公司之間直接進行合作——一方面相互競爭，另一方面又相互合作。微軟在谷歌的libwebrtc中改進了屏幕分享這一功能（在決定Edge采用Chromium之后），Intel助力AV1硬件編碼，RingCentral和8x8推動在WebRTC中向Opus添加RED等等。
眾所周知，我們不能對WebRTC的實現(xiàn)袖手旁觀，應(yīng)該發(fā)起更多的主動合作。供應(yīng)商應(yīng)該公開投資更多的開源實現(xiàn)，而不只是開發(fā)自己的專有代碼。
這只是我一廂情愿的想法，但WebRTC已經(jīng)走到了一個轉(zhuǎn)折點，整個社區(qū)和生態(tài)需要通力合作才能實現(xiàn)WebRTC的下一步發(fā)展。
更多拓展內(nèi)容：
https://bloggeek.me/webrtc-insights/
https://webrtchacks.com/red-improving-audio-quality-with-redundancy/
https://bloggeek.me/a-blueprint-to-improving-webrtc-media-quality-using-ai/
https://bloggeek.me/why-cpaas-is-losing-the-innovation-lead-to-ucaas/
https://bloggeek.me/managed-webrtc-turn-speed/
https://bloggeek.me/webrtc-unbundling/
致謝
本文已獲得作者Tsahi Levent-Levi授權(quán)翻譯和發(fā)布，特此感謝。
原文鏈接：https://bloggeek.me/webrtc-trends-for-2022/
更多年終技術(shù)盤點：
聊聊QUIC協(xié)議的發(fā)展
中南大學(xué)張昊：我非常期待基于AI的圖像視頻編碼技術(shù)的創(chuàng)新
音視頻出海，如何乘風(fēng)破浪？
互動白板的技術(shù)基礎(chǔ)和發(fā)展
掃描圖中二維碼或點擊閱讀原文
了解大會更多信息
喜歡我們的內(nèi)容就點個“在看”吧！
總結(jié)
以上是生活随笔為你收集整理的2022 WebRTC发展趋势分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 未来已来，音视频江湖再起波澜
- 下一篇： FFmpeg 5.0 正式发布