欧美,精品,综合,亚洲,好吊妞视频免新费观看,免费观看三级吃奶,一级a片女人自慰免费看

您當(dāng)前的位置是:  首頁 > 新聞 > 文章精選 >
 首頁 > 新聞 > 文章精選 >

網(wǎng)頁端實(shí)時音視頻服務(wù)架構(gòu)與實(shí)踐

2017-10-26 09:48:12   作者:陳功   來源:CTI論壇   評論:0  點(diǎn)擊:


  負(fù)責(zé)網(wǎng)頁端音視頻通信技術(shù)架構(gòu)。畢業(yè)于中國科學(xué)技術(shù)大學(xué),Ph.D。原英特爾服務(wù)器事業(yè)部多媒體架構(gòu)師,主導(dǎo)基于WebRTC的視頻會議解決方案搭建。曾任職Marvell視頻事業(yè)部,研究多媒體系統(tǒng)框架,參與Google TV, OTT等項目
  我們看一下網(wǎng)頁端的實(shí)時通信有什么樣的特點(diǎn)。
  首先,在瀏覽器端,依賴于瀏覽器獲取音視頻的能力,以及強(qiáng)大的網(wǎng)頁上的渲染能力,所以,就能夠為高清的通信體驗打下基礎(chǔ)。同時,相比移動端來說,屏幕比較大,視窗選擇也比較靈活。
  第二,跨平臺。大家都了解瀏覽器對各個終端的特殊性,不止PC上有瀏覽器、移動端上有瀏覽器,甚至是一些知名的社交APP也嵌入了瀏覽器。這需要一個跨平臺的體驗,現(xiàn)在支持WebRTC的瀏覽器也越來越多了,這也是網(wǎng)頁實(shí)時通信的一個特點(diǎn)
  第三,免安裝,方便接入。隨著WebRTC的普及,它不需要安裝任何插件就可以實(shí)現(xiàn)網(wǎng)頁端的實(shí)時通信。
  再來看一下網(wǎng)頁端實(shí)時通信可以應(yīng)用在什么場景里?
  首先是直播,直播非常火。直播的主播端會有需求,在網(wǎng)頁端進(jìn)行開播,因為網(wǎng)頁端的屏幕比較大、視頻比較清晰、處理能力比較強(qiáng)。同時,也非常有意思,我們一個客戶也在用我們網(wǎng)頁端的SDK做直播的監(jiān)控。大家也知道,直播開播的房間數(shù)很多,在一個網(wǎng)頁上可以監(jiān)控40-50個房間,來做直播的巡視員,用網(wǎng)頁端的實(shí)時音視頻SDK是比較方便的。
  另外一個是在線教育,在線教育的老師端一般都在PC上,如果要安裝應(yīng)用程序,有些老師也不是很懂電腦技術(shù),要去配置的話就比較麻煩。如果有網(wǎng)頁端免安裝的方案的話,他們用起來的話,用戶體驗也會比較好。在線教育除了音視頻,還要求有屏幕共享、白板,因為都是H5的技術(shù),所以與Web端的SDK集成起來的話也會非常方便。
  最后就是視頻會議,大家在公司里用過瀏覽器的視頻會議的話都會有體驗,HR發(fā)一個鏈接,某一個時間點(diǎn)你點(diǎn)這個鏈接,除此之外還有一些說明,你要安裝哪些東西,這個會比較復(fù)雜。現(xiàn)在有了免安裝的WebRTC之后,大家對視頻會議的體驗也會上升一個臺階。這邊列的這幾個是比較典型的場景,其實(shí)還有遠(yuǎn)程醫(yī)療、企業(yè)協(xié)作之類的。
  接下來從技術(shù)上分析一下,網(wǎng)頁端的實(shí)時通信是否已經(jīng)成熟?是否已經(jīng)準(zhǔn)備好了?
  如果說到網(wǎng)頁端、瀏覽器端的實(shí)時通信的話,大家首先會想到的就是Webex,它的體驗是非常不錯的,也培養(yǎng)了一大群目標(biāo)用戶,讓用戶認(rèn)知到在瀏覽器上就可以進(jìn)行視頻的溝通,打開了一個市場。但是,它有一個缺點(diǎn),就是必須安裝瀏覽器的插件和擴(kuò)展程序,和GoToMeeting是一樣的,非常不方便。另一種做法是,在PC上安裝一個應(yīng)用程序,通過這個程序來代理獲取、處理音視頻的流,網(wǎng)頁端只是做渲染和展示。
  在很長一段時間里,這些網(wǎng)頁端的用戶覺得這個技術(shù)就是這樣的,體驗就是這樣的,無法提升了。直到2011年,WebRTC技術(shù)的出現(xiàn),并且由谷歌做推廣。WebRTC帶來的體驗是因為免安裝才受到了關(guān)注,F(xiàn)在在差不多6年的發(fā)展時間里,其實(shí)也有很多的質(zhì)疑聲,比如,Google的項目會不會半途而廢,各大瀏覽器廠商會不會不支持這種打通瀏覽器生態(tài)的想法。
  接下來我想跟大家從不同的維度來分析一下WebRTC這個技術(shù)是否已經(jīng)成熟,是否可以產(chǎn)品化?
  首先,來看一下目前知識WebRTC瀏覽器跟平臺的情況。
  最早支持WebRTC的是Firefox和Chrome,之后是Opera,跟隨者chrome支持WebRTC,它們內(nèi)核是一樣的。微軟前兩年提出了一個ORTC的協(xié)議,跟WebRTC有些相似。ORTC發(fā)展并不順利,現(xiàn)在在edge中開始支持WebRTC。近期蘋果更新了IOS系統(tǒng)之后,Safari 11也開始支持WebRTC了。在安卓平臺上,其實(shí)很早就開始支持了WebRTC。
  我們看一下這幾個瀏覽器在市場上的占有情況,不難看出,現(xiàn)在除了占百分之8點(diǎn)幾的IE之外不支持,其他的其實(shí)都已經(jīng)支持了。
  我們再從協(xié)議棧的角度來看一下。WebRTC 1.0 Spec已經(jīng)基本定稿了,除了一些比較細(xì)節(jié)的問題還沒有最終確認(rèn)。各個瀏覽器對標(biāo)準(zhǔn)的支持也越來越好。雖然谷歌自己也在推廣這個技術(shù),但是谷歌自己的瀏覽器Chrome對WebRTC 1.0的支持并不是很好,這是因為谷歌在內(nèi)部對WebRTC做了很多實(shí)驗性的東西。Chrome團(tuán)隊對外聲稱,會在今年底,完全跟上WebRTC 1.0的標(biāo)準(zhǔn)。
  另外一個方面,看一下開源社區(qū)。舉幾個比較典型的開源項目,一個是Kurento,它是功能比較強(qiáng)大的一個多媒體處理框架,支持WebRTC協(xié)議棧。它可以作為Media server,后臺有轉(zhuǎn)碼的能力,并且有OpenCV處理能力。Licode可以作為WebRTC的輕量通信平臺,是純轉(zhuǎn)發(fā)的服務(wù)器處理模式。Janus可以作為WebRTC通信網(wǎng)關(guān),比較輕量。值得關(guān)注的是React-Native-WebRTC,F(xiàn)在越來越多的開發(fā)者開始轉(zhuǎn)向前端,JS。這種情況在國外更為普遍。在開源社區(qū)上出現(xiàn)了這么一個項目,封裝了一個WebRTC的模塊,開發(fā)者就可以很方便的在手機(jī)上來實(shí)現(xiàn)帶有實(shí)時通信能力、兼容WebRTC的應(yīng)用。
  最后,看一下生態(tài)圈。在CPaas這一層,有聲網(wǎng)、Twilio、Tokbox這樣的公司在做貢獻(xiàn)。
  市場分析對WebRTC非?春茫A(yù)計到2022年市場規(guī)模將達(dá)到64.9億美金。總的來說,WebRTC技術(shù)現(xiàn)在處在一個最好的時代。
  對于開發(fā)者來說,如何用這個技術(shù)、如何能夠構(gòu)建起一個WebRTC的系統(tǒng)?其實(shí)是有一段必經(jīng)之路。
  我們知道WebRTC的底層是基于P2P連接,是點(diǎn)對點(diǎn)的通信。很多開發(fā)者上手的時候,都會去做P2P質(zhì)量的檢驗。比如說一個公司的產(chǎn)品經(jīng)理告訴開發(fā)人員說“現(xiàn)在WebRTC很火,你給我整一個WebRTC的系統(tǒng)。”八成的開發(fā)人員會交付這樣一個網(wǎng)狀結(jié)構(gòu)WebRTC的架構(gòu)。
  那么,完全基于點(diǎn)對點(diǎn)之間通信的架構(gòu)有什么特點(diǎn)?延時會比較小。但是,有一個很大的缺點(diǎn)。這種點(diǎn)對點(diǎn)音視頻流的傳遞,每一個用戶都要給另外一個用戶傳自己的視頻流,這樣對它上行帶寬的壓力很大。并且,每一路視頻流都是獨(dú)立進(jìn)行采集編碼,這對瀏覽器端編碼壓力的考驗也很大。有人會問,能不能只采集一次編碼,然后就把這個流發(fā)給不同的終端接收者?很遺憾,這是不行的。因為WebRTC的協(xié)議是做端到端的質(zhì)量策略優(yōu)化,所以它有一些策略調(diào)整,都是端對端的RTCP來實(shí)現(xiàn),必須要經(jīng)過多次的編碼,然后分別傳輸給不同的接收者。
  右下角的表格列的是一個權(quán)威的行業(yè)機(jī)構(gòu)統(tǒng)計的目前在互聯(lián)網(wǎng)上使用WebRTC的系統(tǒng)架構(gòu),純P2P的只占19%。
  如果按剛才介紹的這個架構(gòu),開發(fā)人員交付給產(chǎn)品的話,肯定會打回來的,因為大家都知道,上行帶寬非常寶貴,也非常受限。為了解決這個問題,開發(fā)人員會做一些深度的研究,發(fā)現(xiàn)領(lǐng)域內(nèi)的WebRTC架構(gòu)其實(shí)中間加了一個點(diǎn),這個點(diǎn)就是服務(wù)器,典型的媒體服務(wù)器只做多路流的轉(zhuǎn)發(fā),不做后臺的媒體處理和轉(zhuǎn)碼。
  上文提到的Janus和Licode開源項目都可以實(shí)現(xiàn)轉(zhuǎn)發(fā)媒體服務(wù)器的功能。它的特點(diǎn)是,每個終端用戶只要上傳一路流到中間服務(wù)器,節(jié)省了帶寬。同時SFU只是做轉(zhuǎn)發(fā),所以對延時的影響相對比較小。弊端是,如果有兩路接收者,下行帶寬的能力不一樣,一個是500K,一個是2m,由于源端發(fā)送者只送一路流,所以就很難適配多路的終端。
  改成純轉(zhuǎn)發(fā)的媒體服務(wù)器之后,它還有一些弊端,開發(fā)人員又會想辦法說,我在中間這個節(jié)點(diǎn)加上混流的功能。大家也可以從這個架構(gòu)當(dāng)中看出來,在服務(wù)器端收到不同的兩路視頻流之后,會分別做解碼、拼接合成、編碼。根據(jù)不同接收者的帶寬情況,分別給不同的接收者發(fā)送不同profile的視頻流。這就解決了,如果是多個接收端的用戶,無法做到帶寬的適配。這個缺點(diǎn)也很明顯,中間做轉(zhuǎn)碼必然帶來延時,其次是轉(zhuǎn)碼服務(wù)器的成本很高,但是,確實(shí)節(jié)省了下行的帶寬,
  介紹了幾種典型的WebRTC的系統(tǒng)架構(gòu)之后,開發(fā)人員可以基于剛才說的幾個開源項目,可以很方便的搭建出,或者是不用費(fèi)太多的時間就可以搭建出這么一個Demo的系統(tǒng),是不是故事就到此結(jié)束了?其實(shí)還差很遠(yuǎn),這邊還有很多隱藏的坑。
  下面再跟大家分享一下,經(jīng)歷過、探索過的一些背后的技術(shù)的難點(diǎn)。
  上圖是從一個Demo做成一個比較穩(wěn)定的產(chǎn)品,會遇到的坑。
  首先是可用性。WebRTC是基于P2P的,P2P的可用性、連接成功率也是大家一直在詬病的,不止是打洞、穿越這些技術(shù)。
  平臺互通:WebRTC出來的時間還是有限的,很多領(lǐng)域內(nèi)的公司都有自己自研的通信協(xié)議,這些協(xié)議一般是用在Native端,手機(jī)端、PC端、mac、windows,這也帶來了一些問題,自研的協(xié)議跟WebRTC協(xié)議之間如何可以做到平臺互通?這也有很多的坑在這里面。剛才說它是一個端到端優(yōu)化的傳輸策略,你拆開這個端到端,你的上行是WebRTC,你的發(fā)送者是WebRTC,接收者是自研的端,這里面有很多策略匹配的工作需要去做。
  編碼器選擇:音視頻的編碼在實(shí)時通信中非常重要。WebRTC的視頻,支持VP8/9,H.264。可能有人會選擇H.264,認(rèn)為它在移動端適應(yīng)性強(qiáng)。但是H.264在Chrome上不太成熟,所以很多商用產(chǎn)品依然在用VP8,但是涉及到移動端的互通,又得考慮編碼器的選擇。
  弱網(wǎng)對抗:WebRTC有一套自己的傳輸策略,比如說丟包重傳、FEC、帶寬檢測、動態(tài)碼率調(diào)整。但是,在弱網(wǎng)對抗方面,前面架構(gòu)圖也提到,我們會在中間加一個轉(zhuǎn)發(fā)節(jié)點(diǎn),就做不到端到端的傳輸鏈路。所以,弱網(wǎng)對抗又是比較頭疼的問題。如何在瀏覽器上,和轉(zhuǎn)發(fā)服務(wù)器上,實(shí)現(xiàn)上行跟下行鏈路的分別優(yōu)化,這里面也有很多難題是需要克服的。
  多用戶場景:就像是典型的小型直播的場景,有很多的接收者,一個發(fā)送者。如果用純WebRTC的傳輸策略,因為它多個接收者之間估計出來的下行帶寬是不一樣的,對發(fā)送端的要求,發(fā)送的碼率調(diào)整也不一樣。大家如果有測試經(jīng)驗就會發(fā)現(xiàn),WebRTC做多人的場景,如果接收端的人數(shù)超過4個、5個的話,它發(fā)送出來的碼率就會非常低,所以看到的畫面就會非常的糊。
  雖然主流的瀏覽器都開始支持WebRTC,但是,其實(shí)所謂的支持WebRTC還是有很多兼容的問題。上圖黃色代表的是部分兼容,在這里只有Firefox支持的比較好。目前炒的比較熱的是Safari,在這里可以看到種種的技術(shù)難點(diǎn),做WebRTC,在Demo產(chǎn)品化的時候我們就必須要去面對。
  智能路由:瀏覽器跟服務(wù)器之間進(jìn)行優(yōu)化傳輸,但是服務(wù)器跟分布式服務(wù)器之間還有一段傳輸。這就要求提供WebRTC服務(wù)的廠商對后臺服務(wù)器之間的傳輸有一個非常好的智能路由選擇、有一個傳輸?shù)膬?yōu)化,比如說跨運(yùn)營商的、跨國的。高可用運(yùn)維,就不展開說了,要保證服務(wù)可用,服務(wù)進(jìn)程不可以掛掉。海量的并發(fā)架構(gòu),一般提供WebRTC的廠商,是一種on demand擴(kuò)容的形式,但是也要求你設(shè)計的架構(gòu)能夠支持海量并發(fā)的擴(kuò)展。還有全局監(jiān)控系統(tǒng),你要對在線上跑的服務(wù)質(zhì)量穩(wěn)定性的數(shù)據(jù)可以進(jìn)行監(jiān)控。還有一個很重要的問題就是調(diào)查工具,當(dāng)你提供WebRTC實(shí)時通信之后,要有問題調(diào)查的能力。比如,在通信中發(fā)生了卡頓、延時,到底是什么原因產(chǎn)生的,哪些因素帶來了不好的通信體驗,這要有一套很完備的問題調(diào)查工具。
  說了這么多,總結(jié)兩點(diǎn),你要從一個WebRTC開發(fā)的Demo到真正成熟的產(chǎn)品服務(wù)的話,首先,你要有一個專業(yè)團(tuán)隊。這個專業(yè)團(tuán)隊要覆蓋音視頻的專業(yè)人才、專家,還要有音視頻通信的、視頻傳輸領(lǐng)域的專家,需要很強(qiáng)的行業(yè)經(jīng)驗,高可用運(yùn)維、實(shí)時監(jiān)控、調(diào)查工具這些,都需要真正的工程師、專家在日積月累的工作當(dāng)中積累下來的經(jīng)驗。
  最后向大家介紹一下聲網(wǎng)WebRTC的SDK。也是從幾個方面來介紹一下:核心質(zhì)量、集成的簡易度、功能的靈活擴(kuò)展、服務(wù)的穩(wěn)定性跟全局監(jiān)控的能力。
  核心質(zhì)量:聲網(wǎng)有一套大網(wǎng)SD-RTN?,可以保障全球傳輸。Web的SDK用到了分布式網(wǎng)關(guān)的架構(gòu),網(wǎng)關(guān)是接在大網(wǎng)的邊緣來部署,可以提升可用性。
  專注互通:正因為聲網(wǎng)有這么一個分布式網(wǎng)關(guān)的架構(gòu),我們就可以接收到不同端上發(fā)來的適配信息,可以對各個平臺的策略進(jìn)行靈活的調(diào)整。所以,在各個瀏覽器的監(jiān)控上,我們也可以做得相對比較好。
  靈活配置的傳輸策略:我們把整個端到端WebRTC的傳輸鏈路改造成端到網(wǎng)關(guān)、網(wǎng)關(guān)到端。在這里面,我們也配置了很多FEC、策略上的一些優(yōu)化。同時,我們也可以多流發(fā)送。
  差異化的編碼器選擇:我們可以選擇不同的編碼器,根據(jù)終端的能力進(jìn)行適配,同時兼顧到端上有沒有硬件編解碼,和軟件的編解碼。這些點(diǎn)加起來,保證了我們聲網(wǎng)Web的SDK就可以提升為一個高質(zhì)量的傳輸服務(wù)。
  快速集成:非常方便,只需要四行代碼就可以接入到我們視頻通信的頻道里,很方便,一般4、5分鐘就可以完成一個音視頻聊天的小程序。同時,我們也有完備的文檔,非常簡單易讀的Demo。
  功能的靈活擴(kuò)展:傳統(tǒng)的WebRTC是用來做通信的場景,我們這個Web SDK,目前也支持直播的場景,支持旁路推流、服務(wù)器錄制。
  全局監(jiān)控的能力:我們目前提供了Dashboard、服務(wù)質(zhì)量報表,可以看到頻道內(nèi)的傳輸質(zhì)量、傳輸效果、用戶接入等各種數(shù)據(jù)。另外,我們還有全局網(wǎng)絡(luò)的指標(biāo),包含丟包、延時、抖動的信息。右邊這個是問題診斷系統(tǒng)的一部分。為什么問題診斷系統(tǒng)重要?當(dāng)用戶接入實(shí)時通信,你發(fā)生延時、抖動的時候,我們就可以知道在什么地方出現(xiàn)了問題,綜合這些信息,我們要很清楚的知道線上的某一個頻道的傳輸渠道出了什么問題,在什么地方可以調(diào)優(yōu)。
【免責(zé)聲明】本文僅代表作者本人觀點(diǎn),與CTI論壇無關(guān)。CTI論壇對文中陳述、觀點(diǎn)判斷保持中立,不對所包含內(nèi)容的準(zhǔn)確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔(dān)全部責(zé)任。

專題