在6月19日至20日,WebRTC 工作組進行了一次臨時會議,討論 WebRTC 的未來。 所有瀏覽器供應(yīng)廠商都對WebRTC v1.0做出了很正向的評價。WebRTC v1.0在2018年6月更新修復(fù)了多個 bug。WebRTC v1.0新 API 包括:
RTCRtpSender.setStreams()RTCRtpTransceiver.currentDirectionRTCSctpTransport.maxChannelsRTCPeerConnection.onstatsendedRTCStatsEvent interface
在本文中,我們一起來探討下 WebRTC 可能將發(fā)生的變化。
WebRTC的應(yīng)用場景
在我們討論 WebRTC API 未來的變化之前,我們應(yīng)該考慮它的實際應(yīng)用。當(dāng)我們在2011年構(gòu)建 WebRTC v1.0時,我們僅討論了幾個應(yīng)用場景。自2011年以來,行業(yè)發(fā)生了許多變化,其中最引人注目的就是移動互聯(lián)網(wǎng)。我們可以通過移動應(yīng)用、虛擬現(xiàn)實、增強現(xiàn)實和其他方式,為最終用戶提供完全身臨其境的體驗。我們還發(fā)現(xiàn)圖片的重要性也越發(fā)明顯,交互式網(wǎng)站也逐漸成為互聯(lián)網(wǎng)的新常態(tài)。因此,對于現(xiàn)在的 WebRTC API,及其未來可能出現(xiàn)的任何變化,都應(yīng)該以這些新的應(yīng)用趨勢作為出發(fā)點來考慮。
不過,遺憾的是,現(xiàn)在的 WebRTC API 還無法很好地實現(xiàn)或適應(yīng)其中部分應(yīng)用場景。因此,我們需要強化 API 的能力。這種強化主要涉及兩方面:應(yīng)用場景和開發(fā)易用性。
媒體與數(shù)據(jù)的統(tǒng)一
這次會議也廣泛討論了媒體與數(shù)據(jù)的統(tǒng)一,包括幾方面:
多個媒體流與數(shù)據(jù)流的同步;
直播;
游戲,包括VR/AR;
media pipline 的控制
為了可以更好地控制 media pipline,會議上討論了幾個策略,包括:
可插拔擁塞控制(Pluggable Congestion Control):有幾個可插拔擁塞控制的支持者,包括 Callstats.io。支持它的主要原因之一就是會采用多路徑協(xié)議來做多媒體實時通訊。 我們在這個領(lǐng)域有長期的投入,包括在多媒體擁塞控制和相關(guān)優(yōu)化方面的工作。
取代瀏覽器實現(xiàn)的算法:能夠取代瀏覽器實現(xiàn)的算法,意味著開發(fā)者將能使用自己的 jitter buffer、FEC算法(例如 LDPC,Raptor 等),編碼器和解碼器(編解碼器)等。
WebRTC 下一步的演進
在會議上,Google 的 Peter Thatcher 提出了很多 WebRTC 下一步演進的可能性。我們接下來逐一來聊聊這些提議。
請記住,隨著 API 的每一次更新,應(yīng)用開發(fā)者都將得到對信道更好的控制。同時,也意味著 API 將變得更加復(fù)雜,但對信令的把控上將更可靠且靈活。
通常來講,我們認為應(yīng)用開發(fā)者獲得的可控性越高,就越能開發(fā)出好的產(chǎn)品。首先,要降低一些協(xié)議和算法為瀏覽器開發(fā)帶來的復(fù)雜度。
其次,Web 開發(fā)者已經(jīng)知道如何通過 shim 來進行更好的開發(fā),并讓其也能被其它開發(fā)者復(fù)用。
ORTC
在 ORTC 中首次提出的幾個對象被添加到WebRTC v1.0中。 ORTC 不使用 SDP 作為控制界面,開發(fā)者可直接控制媒體和數(shù)據(jù)傳輸通道,這一點與 WebRTC v1.0完全不同。更多對象可被直接控制。例如,使用 ORTC,您可以使用和控制可擴展的視頻編解碼器。
可插拔傳輸
考慮到進一步拆分 media pipeline 的對象,可插拔傳輸可實現(xiàn)更多對 media pipeline 控制功能。 例如,向編碼/解碼幀添加或移除元數(shù)據(jù),或?qū)γ襟w質(zhì)量進行控制。
為了實現(xiàn)這一點,并讓媒體傳輸更加可控。我們需要分別將編碼器和解碼器與 RTCRtpSender 和 RTCRtpReceiver 分隔開。進一步,我們可以將媒體和數(shù)據(jù)分開傳輸,比如 RTP over UDP 或 QUIC 或 SCTP。 除了可插拔傳輸之外,這將能夠讓大規(guī)模會議服務(wù)使用不同的加密密鑰進行 hop-by-hop 加密(通過DTLS / SRTP)和 end-to-end 加密。
媒體裸數(shù)據(jù)和完全控制
提供對 pipeline 完整的控制權(quán)限,將讓 App 可以完全控制編碼和解碼、媒體擁塞控制、安全性(任何形式的加密),媒體幀的處理(如 FEC、RTX),以及解碼這一端的媒體同步等。這種靈活度的提升,也會需要 App 支持更多功能,需要在開發(fā)方面下更多功夫,當(dāng)然,做與不做,這決定權(quán)也在開發(fā)者的手上。
小結(jié)
將有兩個方面的變化:
為音頻,視頻和數(shù)據(jù)的信道中的組件創(chuàng)建更多對象;
提供訪問媒體裸數(shù)據(jù)的權(quán)限。
這些變化也將帶來一些疑問:
裸數(shù)據(jù)加密與否;
JavaScript 并不具備實時性。
關(guān)于安全性的討論,我們認為媒體裸數(shù)據(jù)應(yīng)該是加密的,而且應(yīng)用不會接收未加密的數(shù)據(jù)。
關(guān)于JavaScript 的問題。如果在主線程中管理完整的 pipeline,每秒將只能處理1幀,甚至更低。因此,我們需要一系列新的 JavaScript 和瀏覽器功能,比如 WebWorkers、WebAssembly(wasm)。除此之外,JavaScript 還會帶來其它問題,在這種情況下, 也需要讓 Web 端能訪問媒體流,App 端可以跟蹤預(yù)期任務(wù)狀態(tài)。
對這些 WebRTC 將可能發(fā)生的變化,以及我們更多關(guān)于未來實時互聯(lián)網(wǎng)變革的想法。我們將在 RTC 2018 實時互聯(lián)網(wǎng)大會上與大家進行深入分享和探討。
Tips
Varun Singh 將在 RTC 2018 實時互聯(lián)網(wǎng)大會的“實時網(wǎng)絡(luò)與質(zhì)量專場”上分享更多干貨與 WebRTC 的近期動態(tài),席位有限,希望深入了解的話,就趕快掃碼報名吧。
-
編碼器
+關(guān)注
關(guān)注
45文章
3640瀏覽量
134453 -
WebRTC
+關(guān)注
關(guān)注
0文章
57瀏覽量
11241
原文標題:WebRTC 工作組:我們相信 WebRTC 將會有這些革新
文章出處:【微信號:shengwang-agora,微信公眾號:聲網(wǎng)Agora】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論