WebRTC 1.0 之後,WebRTC API將發生的變革
作者:Varun Singh,http://Callstats.io CEO,RTC 2018 實時互聯網大會受邀演講嘉賓。
在6月19日至20日,WebRTC 工作組進行了一次臨時會議,討論 WebRTC 的未來。 所有瀏覽器供應廠商都對WebRTC v1.0做出了很正向的評價。WebRTC v1.0在2018年6月更新修復了多個 bug。WebRTC v1.0新 API 包括:
RTCRtpSender.setStreams()
RTCRtpTransceiver.currentDirection
RTCSctpTransport.maxChannels
RTCPeerConnection.onstatsended
RTCStatsEvent interface
在本文中,我們一起來探討下 WebRTC 可能將發生的變化。
WebRTC的應用場景
在我們討論 WebRTC API 未來的變化之前,我們應該考慮它的實際應用。當我們在2011年構建 WebRTC v1.0時,我們僅討論了幾個應用場景。自2011年以來,行業發生了許多變化,其中最引人注目的就是移動互聯網。我們可以通過移動應用、虛擬現實、增強現實和其他方式,為最終用戶提供完全身臨其境的體驗。我們還發現圖片的重要性也越發明顯,互動式網站也逐漸成為互聯網的新常態。因此,對於現在的 WebRTC API,及其未來可能出現的任何變化,都應該以這些新的應用趨勢作為出發點來考慮。
不過,遺憾的是,現在的 WebRTC API 還無法很好地實現或適應其中部分應用場景。因此,我們需要強化 API 的能力。這種強化主要涉及兩方面:應用場景和開發易用性。
媒體與數據的統一
這次會議也廣泛討論了媒體與數據的統一,包括幾方面:
- 多個媒體流與數據流的同步;
- IoT 設備通信;
- 直播;
- 遊戲,包括VR/AR;
media pipline 的控制
為了可以更好地控制 media pipline,會議上討論了幾個策略,包括:
可插拔擁塞控制(Pluggable Congestion Control):有幾個可插拔擁塞控制的支持者,包括 http://Callstats.io。支持它的主要原因之一就是會採用多路徑協議來做多媒體實時通訊。 我們在這個領域有長期的投入,包括在多媒體擁塞控制和相關優化方面的工作。
取代瀏覽器實現的演算法:能夠取代瀏覽器實現的演算法,意味著開發者將能使用自己的 jitter buffer、FEC 演算法(例如 LDPC,Raptor 等),編碼器和解碼器(編解碼器)等。
WebRTC 下一步的演進
在會議上,Google 的 Peter Thatcher 提出了很多 WebRTC 下一步演進的可能性。我們接下來逐一來聊聊這些提議。
請記住,隨著 API 的每一次更新,應用開發者都將得到對信道更好的控制。同時,也意味著 API 將變得更加複雜,但對信令的把控上將更可靠且靈活。
通常來講,我們認為應用開發者獲得的可控性越高,就越能開發出好的產品。首先,要降低一些協議和演算法為瀏覽器開發帶來的複雜度。
其次,Web 開發者已經知道如何通過 shim 來進行更好的開發,並讓其也能被其它開發者復用。