展望2018:WebRTC技术现状、应用开发与前景
2017年,蘋果宣布將在iOS 11中支持WebRTC,至此完成了主流PC瀏覽器、移動端的全覆蓋,而其提供了一整套完備的音視頻通信方案,這給開發(fā)者帶來了巨大利好。英特爾協(xié)同通信解決方案架構(gòu)師段先德針對WebRTC的能力、優(yōu)勢與不足、開發(fā)要點及未來發(fā)展幾方面進行分析。本文是『WebRTC-互聯(lián)網(wǎng)音視頻新標準?』系列的第一篇,如果您對WebRTC技術(shù)的未來有分析和洞見,歡迎聯(lián)系 contribute@livevideostack.com。
文 / 段先德
策劃 / LiveVideoStack
2017年,隨著微軟和蘋果表態(tài)在其瀏覽器或系統(tǒng)產(chǎn)品中對WebRTC技術(shù)的支持,以及WebRTC 1.0標準的定案,WebRTC的話題越來越多地出現(xiàn)在廣大互聯(lián)網(wǎng)行業(yè)開發(fā)人員的視野中。很多同學對WebRTC的背景、目的、意義以及限制其實并不明白,加上媒體上各種吹捧和質(zhì)疑的聲音互相摻雜,對WebRTC這項技術(shù)的應(yīng)用前景和開發(fā)難度沒有切實的判斷。本文希望通過對WebRTC技術(shù)的粗淺梳理,為大家提供參考。
WebRTC是什么?能做什么?
很多人期望WebRTC是一個“拿來即用”的“端到端解決方案”,只需要在web端寫幾行JavaScript調(diào)用甚至不需要編程就能實現(xiàn)瀏覽器之間的實時音視頻通信。也有很多人把WebRTC等同于Google在其Chromium工程中的開源實現(xiàn)。其實這都是誤解。WebRTC并不是一個“解決方案”,也不囿于某一種實現(xiàn)的代碼庫。WebRTC是終端的音視頻媒體訪問(輸入輸出)接口在類似web環(huán)境下的標準化抽象,以及用于實時通信的會話的建立過程、終端音視頻媒體(或其他數(shù)據(jù))編碼格式、傳輸方式和參數(shù)的描述和協(xié)商規(guī)范。既然是一種標準規(guī)范,那么無論具體實現(xiàn)方式如何,只要該實現(xiàn)符合該標準規(guī)范就應(yīng)該可以互聯(lián)互通、擁有實時通信的能力,這也是WebRTC最本質(zhì)的意義。
WebRTC雖然冠以“web”之名,但并不受限于傳統(tǒng)互聯(lián)網(wǎng)應(yīng)用或瀏覽器的終端運行環(huán)境。實際上無論終端運行環(huán)境是瀏覽器、桌面應(yīng)用、移動設(shè)備(Android或iOS)還是IoT設(shè)備,只要IP連接可到達且符合WebRTC規(guī)范就可以互通。這一點釋放了大量智能終端(或運行在智能終端上的app)的實時通信能力,打開了許多對于實時交互性要求較高的應(yīng)用場景的想象空間,譬如在線教育、視頻會議、視頻社交、遠程協(xié)助、遠程操控等等都是其合適的應(yīng)用領(lǐng)域。
WebRTC有什么優(yōu)勢和不足?
很長時間以來,實時通信能力一直是電信類專用設(shè)備(如電話、手機)的專有屬性。隨著各種互聯(lián)網(wǎng)應(yīng)用和移動互聯(lián)網(wǎng)應(yīng)用的層出不窮,特別是隨著用戶接入帶寬條件的不斷改善,許多新的應(yīng)用都對實時通信服務(wù)有著切實的需求,希望能夠把實時通信能力集成到應(yīng)用程序中。其實很多終端設(shè)備都具有實時通信的潛力的,但是在WebRTC之前,沒有一個統(tǒng)一的工業(yè)標準來描述一個設(shè)備的實時通信能力和連接建立過程。在對實時通信能力的需求特別迫切的應(yīng)用(如微信、WhasApp、FaceTime、Messenger等等)中,大家各做一套,“七國八制”,完全不能互通。
WebRTC最大的優(yōu)勢就是“標準化”,它解決的問題就是給所有需要進行實時通信的終端提供一套統(tǒng)一的、開放的實時通信能力描述和連接建立標準。只要符合WebRTC的規(guī)范,通信終端的形態(tài)和運行環(huán)境就是透明的(看不見也不關(guān)心),大家都可以用同一種“語言”進行“交談”。WebRTC對音視頻的編碼格式(codec)、傳輸方式和協(xié)商過程做出了明確的規(guī)定,原則上所有支持WebRTC的終端,在互操作性上將不存在障礙。目前各大瀏覽器廠商都積極參與到WebRTC技術(shù)的生態(tài)中,從web應(yīng)用開始,WebRTC將成為基于網(wǎng)頁的音視頻實時通信技術(shù)規(guī)范將。之后,在web應(yīng)用于移動終端應(yīng)用的交互需求驅(qū)動下,越來越多的移動應(yīng)用的音視頻服務(wù)也將采用WebRTC的技術(shù)規(guī)范。
要說不足之處,一個就是目前WebRTC標準剛剛塵埃落定,在2018年以及今后的一段時間內(nèi),還存在各家瀏覽器廠商的現(xiàn)有WebRTC實現(xiàn)與規(guī)范不完全相符的情況,會多少存在某些應(yīng)用場景下互聯(lián)互通的問題,亟待各家瀏覽器廠商將持續(xù)完善現(xiàn)有實現(xiàn)以向標準看齊。另一個很大的不足(遺憾)可能是Android和iOS系統(tǒng)原生支持WebRTC標準的愿景目前還不明確,需要通過在app中集成客戶端SDK來實現(xiàn)。不過向來技術(shù)標準的發(fā)展和與工業(yè)界的應(yīng)用普及是相互激勵的,我們也可以說這是WebRTC標準發(fā)展的一個巨大空間。
怎么做基于WebRTC的應(yīng)用開發(fā)?
首先當然要讓終端具備WebRTC能力。如果終端運行環(huán)境是瀏覽器,目前絕大部分瀏覽器都已經(jīng)實現(xiàn)了對WebRTC的支持(其中Safari和Edge的支持還在持續(xù)完善中),雖然彼此有一些差異,但是可以借助adapter.js等適配層屏蔽掉這些差異。如果終端運行環(huán)境不是瀏覽器,則可以采用其他的開源SDK或商業(yè)SDK,將其集成在終端應(yīng)用程序中。當然也可以基于Google的開源WebRTC實現(xiàn)的Native代碼進行裁剪或移植。值得一提的是Google的開源WebRTC代碼庫中有大量的終端多媒體問題和傳輸問題的應(yīng)對方案的實現(xiàn),包括音視頻的編解碼、同步、帶寬預(yù)測、QoS,AEC等,都是做終端(特別是IoT設(shè)備或桌面環(huán)境應(yīng)用)開發(fā)時很好的參考。
終端實現(xiàn)了WebRTC只是表示它具備了實時通信的能力,但各個終端任然是孤立的,需要將各個終端的SDP進行交換才能讓它們完成媒體和傳輸?shù)膮f(xié)商才能讓各個終端之間真正通起來。WebRTC并未就各個實現(xiàn)之間交換SDP的傳輸方式以及終端的“尋址”方式做出規(guī)定,這跟具體應(yīng)用場景和其實現(xiàn)方式高度相關(guān)。因此要實現(xiàn)基于WebRTC的應(yīng)用還需要一些“額外”的工作,通過一個各個終端都“認識”并能“找到”的“中間人”來進行SDP交換。譬如最簡單的“1對1”呼叫的場景,這個“中間人”就是信令服務(wù)器,這種WebRTC的信令服務(wù)器可以基于任何消息系統(tǒng)構(gòu)建,有很多開源實現(xiàn)可以利用或參考,自研開發(fā)也并不復(fù)雜。
如果要基于WebRTC做“1對多”或者“多對多”的實時通信應(yīng)用,則情況要復(fù)雜一些,具體的做法也會因?qū)嶋H應(yīng)用場景而不同,根據(jù)通信終端之間的媒體流拓撲結(jié)構(gòu),大體上可以分為Peer2Peer(終端點對點連接)模式、SFU(Selective Forwarding Unit,服務(wù)器選擇性轉(zhuǎn)發(fā))模式和MCU(MultipointControl Unit,服務(wù)器混音混流)模式。
Peer2Peer模式(所有參與方均需與其他所有參與方通信的情景又叫Mesh模式)的特征是呼叫中每兩個需要進行通信的參與者之間都建立起點對點的媒體連接(PeerConnection),所有的媒體連接都是終端之間的(有可能通過TURN服務(wù)器進行NAT穿越,但不影響本質(zhì)流拓撲),服務(wù)器側(cè)不參與。Peer2Peer模式的優(yōu)點是媒體拓撲去中心化,服務(wù)器側(cè)實現(xiàn)簡單,只需要將各個終端之間的信令交換送達即可;缺點是終端需要受理多路媒體流的收發(fā),隨著呼叫中參與方數(shù)的增加,媒體連接數(shù)會階乘函數(shù)式增長,無論對終端的編解碼計算力還是帶寬資源都會帶來巨大的壓力。如果一個呼叫中參數(shù)方數(shù)很少(譬如大多數(shù)時間2方偶爾3方),則可以考慮選用Peer2Peer模式的服務(wù)器側(cè)實現(xiàn)方案。
SFU模式的特征是呼叫中所有的參與者都與服務(wù)器側(cè)的媒體服務(wù)器建立媒體連接,把媒體流發(fā)送到媒體服務(wù)器,媒體服務(wù)器把媒體流(根據(jù)需要)選擇性轉(zhuǎn)發(fā)給需要接收該媒體流的所有參與者。SFU模式的優(yōu)點是終端編碼運算和上行網(wǎng)絡(luò)帶寬消耗大大減少,并且媒體服務(wù)器可以根據(jù)要求將媒體流(需支持SVC)的不同分層選擇性地發(fā)送給接收者,適當減少接收者側(cè)下行網(wǎng)絡(luò)帶寬的消耗并提供一定的“可定制性”用戶體驗。缺點(或“代價”)是媒體服務(wù)器需要受理所有媒體連接請求,接收所有參與者發(fā)布的流并轉(zhuǎn)發(fā)給所有訂閱者,產(chǎn)生服務(wù)器側(cè)運營壓力。
MCU模式的特征是呼叫中所有的參與者都與服務(wù)器側(cè)的媒體服務(wù)器建立媒體連接并把媒體流發(fā)送到媒體服務(wù)器,媒體服務(wù)器把所有收到的媒體流進行混流混音后發(fā)送給所有需要接收的參與者。MCU模式相對SFU模式的優(yōu)點是終端解碼運算和下行網(wǎng)絡(luò)帶寬消耗進一步減少,并且天然具有轉(zhuǎn)碼能力,可以放寬終端采用音視頻編解碼格式的限制,使終端可以選擇對自身最友好的編解碼格式,大大提高終端生存能力。并且由于將所有終端的媒體混合在一起,可以實現(xiàn)服務(wù)器側(cè)所見即所得的錄制和向外部流媒體服務(wù)器推流。MCU的缺點(或“代價”)是媒體服務(wù)器需要實時將所有接收的媒體流解碼混合再編碼,會帶來更大的計算力開銷。
在基于WebRTC的應(yīng)用的實際開發(fā)中,大多數(shù)時候服務(wù)集成商并不需要從頭自研一套SFU或MCU系統(tǒng),而是在市面上可用的開源或商業(yè)方案中進行選擇。在進行方案選擇時需要考慮的是,如果:
希望客戶端側(cè)擁有更多的顯示布局的靈活性且下行帶寬夠大夠穩(wěn)定;
呼叫中發(fā)布媒體流的參與方數(shù)較少(譬如不多于6方);
無異種終端接入需求也不需要轉(zhuǎn)碼,則可以選擇SFU模式。
否則,如果:
客戶端對下行數(shù)據(jù)量有苛刻的要求而對聚合畫面布局沒有差異化要求;
所有參與方(或很多參與方)都有發(fā)布媒體流的需求(視頻會議的情景);
有異種終端(譬如SIP終端、IPCamera)的接入需求或轉(zhuǎn)碼需求;
有服務(wù)器側(cè)(云端)錄制和推流到CDN的需求,則或許MCU模式更適合。除去所述這些情況以外的應(yīng)用場景,則需要在各種需求的矛盾中權(quán)衡輕重得失以做出選擇了。
不過其實SFU模式和MCU模式并不是絕對互斥的,有的解決方案(例如Intel CS for WebRTC及其商業(yè)化版本)是將這兩種模式集成在一起的,服務(wù)集成商可以根據(jù)具體的應(yīng)用場景進行靈活配置。
WebRTC發(fā)展前景如何?
作為終端技術(shù)規(guī)范,雖然WebRTC只是實時通信解決方案中的一部分,但是是最貼近用戶的一部分,也許也是最重要的一部分。終端技術(shù)規(guī)范的標準化,是一個很好的開始。連一向以封閉的技術(shù)生態(tài)聞名的Apple都擁抱WebRTC了,將促進WebRTC技術(shù)的發(fā)展和普及,會有越來越多的互聯(lián)網(wǎng)(和移動互聯(lián)網(wǎng))應(yīng)用基于WebRTC構(gòu)建其實時通信服務(wù)。
進入2018年,在互聯(lián)網(wǎng)快速發(fā)展的當下和將來,WebRTC將極大激活人與人、人與物、物與物(IoT)之間的信息紐帶,移除掉通信終端之間的時間(實時)和空間(基于互聯(lián)網(wǎng))的障礙,成為應(yīng)用場景創(chuàng)新的一道強大的技術(shù)保障。同時,類似VR、AR、自動駕駛等新的應(yīng)用場景的出現(xiàn)也會給WebRTC技術(shù)帶來新的需求和動力,應(yīng)用場景的商業(yè)化成功也將給技術(shù)發(fā)展持續(xù)注入活力和物質(zhì)資源。譬如近年來直播連麥、網(wǎng)上課堂、遠程控制(抓娃娃機)等基于互聯(lián)網(wǎng)的視頻應(yīng)用的猛烈發(fā)展和火熱,一次次催動著基于互聯(lián)網(wǎng)的的實時音視頻通信技術(shù)的發(fā)展,呼喚著WebRTC這樣的統(tǒng)一、開放、透明的標準規(guī)范成熟和落地。
想象一下,在基于WebRTC構(gòu)建的世界里,所有通信終端的媒體描述和連接建立過程都是一致的,只要終端之間開放媒體協(xié)商的通道,就可以建立起實時通信,“微信”與“WhatsApp”能建立視頻通話,就像你在中國用手機跟美國的朋友家中的座機打電話一樣。那多美好!推動這一天的早日到來難道不也是我們互聯(lián)網(wǎng)音視頻通信工作者們的歷史責任嗎?
總結(jié)
以上是生活随笔為你收集整理的展望2018:WebRTC技术现状、应用开发与前景的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 王立众:学习多媒体开发从编解码开始
- 下一篇: WebRTC:应用中最大难点在于根据业务