當前位置:首頁 > 消費電子 > 音視頻及家電
[導讀] 2017年騰訊視頻云團隊跟微信團隊聯(lián)合,將視頻云 SDK 跟微信小程序整合在一起,并通過和 兩個標簽的形式開放內(nèi)部的功能。通過這兩個標簽,開發(fā)者可以實現(xiàn)在線直播、低延時監(jiān)控、雙人視頻通話以及多人

2017年騰訊視頻云團隊跟微信團隊聯(lián)合,將視頻云 SDK 跟微信小程序整合在一起,并通過和 兩個標簽的形式開放內(nèi)部的功能。通過這兩個標簽,開發(fā)者可以實現(xiàn)在線直播、低延時監(jiān)控、雙人視頻通話以及多人視頻會議等功能。

WebRTC(Web Real-Time CommunicaTIon),是一個支持網(wǎng)頁瀏覽器進行實時語音對話或視頻對話的技術(shù),是谷歌收購 GIPS 公司而獲得的一項技術(shù),在 Chrome 瀏覽器上無需安裝插件,通過 javascript 就可以編寫實時音視頻通話程序。

如果您跟我一樣是一個實用主義者,那我就簡單從實用主義角度說一下我的結(jié)論:小程序音視頻搞定了手機,WebRTC拿下了PC。如果你對技術(shù)比較感興趣,那我們就可以從多個技術(shù)的角度去列舉兩者的區(qū)別,下面是一張詳細對比的表格:

小程序音視頻是將騰訊視頻云的 liteavsdk 嵌入到微信內(nèi)部實現(xiàn)的,然后通過和 兩個標簽將 SDK 內(nèi)部的音視頻能力開放出來。所以小程序的標簽起到了開發(fā)者 API 的作用,而內(nèi)部的 SDK 則是真正用來實現(xiàn)音視頻功能。

WebRTC 由谷歌收購 GIPS 得來(這里不得不提一下,我加入騰訊時所在的第一個團隊就是 QQ 團隊,當時 QQ 的音視頻還是購買的 GIPS 公司的產(chǎn)品,不過由于各種不靠譜,后來就轉(zhuǎn)為自研路線了)。所以其技術(shù)被完整的保留并且加入到了 Google 的 Chrome 瀏覽器內(nèi)核當中。而且最近蘋果也已經(jīng)開始在 Safari 瀏覽器中支持 WebRTC 的相關(guān)能力。

小程序音視頻的主要協(xié)議是目前在直播領(lǐng)域最為常用的 RTMP 推流協(xié)議,以及 HTTP-FLV 播放協(xié)議,這兩種協(xié)議都已經(jīng)有多年的沉淀而且在互聯(lián)網(wǎng)上的資料也是汗牛充棟。WebRTC的底層則是使用RTP和RTCP兩種數(shù)據(jù)協(xié)議,其中RTP主要用于音視頻數(shù)據(jù)傳輸,而RTCP則一般用于控制。小程序音視頻由于是微信統(tǒng)一實現(xiàn)的,而且微信團隊每個版本都盡量要求功能對齊,否則寧可不上,所以在碎片化問題上基本不存在。

WebRTC在這里則要尷尬的多,一方面Android系統(tǒng)的碎片化本身讓WebRTC的具體表現(xiàn)呈現(xiàn)“百花齊放”的景象,同時,iOS 目前的內(nèi)嵌WebView(也就是在微信等APP里打開的各種內(nèi)嵌網(wǎng)頁)不支持WebRTC也還是個很麻煩的問題。

小程序音視頻跟隨微信的版本發(fā)布,有什么問題一般是當前代碼流修正,然后跟隨下一個版本發(fā)布,所以一般一個功能點(比如給 pusher 加一個美顏的功能)或者一個問題點(比如不支持手勢放大)從確立到最終實現(xiàn)(或解決)僅需要一個月的時間,而且微信APP新版本的覆蓋速度也確實挺快。

相比之下,WebRTC則不是一個團隊或者一家公司的問題了,因為它現(xiàn)在已經(jīng)走標準路線,所以每一個新特性都是先確定標準,然后再推動瀏覽器廠商(包括蘋果)進行跟隨。這里面的故事就多了,時間也就更久了。相信您已經(jīng)發(fā)現(xiàn),在前面幾個問題的分析上,我的觀點都傾向小程序音視頻。確實,在目前國內(nèi)的移動領(lǐng)域里,谷歌和蘋果都不能一家說了算,真正說了算的還是微信。

但是在桌面瀏覽器這個部分,Chrome目前在PC瀏覽器市場上留到地位的存在決定了 WebRTC 的優(yōu)勢就很大了,開發(fā)者可以在不安裝插件的情況下就可以實現(xiàn)自己想要的功能。相比之下,由于沒有 Chrome 的原生支持,所以如果我們要在 PC 上對接小程序音視頻,就需要安裝瀏覽器插件或者通過 wxlite://start 這樣的偽協(xié)議喚起本地 exe 應用程序(類似在網(wǎng)頁上打開 QQ 聊天窗口)。

小程序音視頻和WebRTC支架并非零和博藝,雙方都有自己的優(yōu)勢和不足,所以本著“打不過他們,就加入他們”的思路,騰訊視頻云團隊在2018年春節(jié)回來后,就馬不停蹄地開始了小程序音視頻和WebRTC互通的相關(guān)工作。

目前,需要向各位開發(fā)者匯報的是,在最新版本的微信中,小程序音視頻已經(jīng)可以跟WebRTC打通,目前在PC 的Chrome瀏覽器上就可以跟小程序進行實時音視頻互通。就像結(jié)婚一樣,既然你決定要選擇另一個人作為人生下半輩子的伴侶,那你肯定會先深入地了解一下TA這個人,比如性格,脾氣,愛好等各個方面。

同樣,我們要想很好的將小程序音視頻和WebRTC打通,那也必須要多了解一下WebRTC,這里我就說一下我對 WebRTC 這個“人” 在性格上的一些理解。

說WebRTC長得不好看,只是我的一種比喻,我的意思是想說WebRTC的學習成本不低,雖然Google做了很多淺顯易懂的PPT來教你怎么 GetTIng Start,但真要完整的學進去,還是需要靜下心來,慢慢地把她當成自己認可的目標去學下去。但是如果你是第一次戀愛(也就是第一次接觸實時音視頻),你會發(fā)現(xiàn)學習WebRTC的過程,本身就是了解一個實時音視頻技術(shù)細節(jié)的過程。

說WebRTC喜歡遷就比人,也是一種比喻,WebRTC所支持的后臺架構(gòu)非常多(比如 Mixer, Mesh,Router),而且谷歌認為這些后臺實現(xiàn)都比較簡單,所以既沒有開放后臺相關(guān)的源碼,也沒有提供統(tǒng)一的后臺解決方案。這種開放式的設(shè)計思路非常好,但副作用就是實現(xiàn)成本高。在真刀真槍的項目落地時,小規(guī)模的公司或者開發(fā)者就很容易被這種技術(shù)門檻擋在門外。尤其是想要將 WebRTC 真正應用到企業(yè)級解決方案中,面對錄制和存檔的剛性需求,就需要花費大量時間進行定制開發(fā)。

但是看過《新聞聯(lián)播》里國家領(lǐng)導人之間談話鏡頭的人都知道,這種翻譯是會影響交流速度的。小程序音視頻和WebRTC之間互通,中間引入一個翻譯員,是不是通訊延時也就增加了?

其實不會,因為小程序音視頻和WebRTC的視頻編碼標準在常規(guī)應用場景中是一致的,都是H.264標準,這是音頻格式不同而已。這就意味著,翻譯員要做的事情很少,兩邊基本都能挺對對方在說什么,所以延時不會增加太多。

僅僅完成了音視頻數(shù)據(jù)在小程序和WebRTC之間的握手還遠遠不夠,因為在一次成功的音視頻通話背后,不僅僅是把一端的音視頻數(shù)據(jù)傳遞到另一端這么簡單,還有狀態(tài)的同步和成員間的狀態(tài)協(xié)同。

比如多人視頻通話中,涉及到呼叫和接通的流程,其中一方如果掛斷了,其他人要收到掛斷的通知。同時,如果有新的參與者加入,那么其他人也要收到相應的通知。WebRTC 中有很多組件,比如 RTCPeerConnecTIon 就在處理上訴林林種種的邏輯。但是 WebRTC 的接口中引入的新名詞非常多,對于初學者來說還是有一定的入門門檻,為了簡化這里的邏輯,我們引入一個叫做“房間”的概念。

所謂房間(Room),就是把同時參與視頻通話的各方圈在一起的一個東西。比如雙人通話中,通話中的兩個人 A 和 B 就可以認為在一個房間中。再比如在多人通話中,通話中的五個人(A B C D E)也可以認為是在一個房間里。

有了房間的概念,那我們就可以對剛才說的狀態(tài)協(xié)同用兩個簡單的動作描述一下:如果有一個人加入了視頻通話,那么就可以理解為他/她已經(jīng)進房(EnterRoom)了;如果有一個退出了視頻通話,那么就可以理解為他/她已經(jīng)離開房間(LeaveRoom)了。而房間的門板上始終寫著:“目前在房間里有哪幾個人”。

有了房間的概念,我們就可以將小程序的兩個簡單的和 標簽,同 WebRTC 那一套復雜的 API 進行功能上的對齊,我們甚至不需要修改我們在第一版中定義的接口,就可以達成這個目標:原理如下:1) 的 url 接口不再傳遞 rtmp:// 協(xié)議的推流地址,而是傳遞 room:// 協(xié)議的推流地址。room:// 協(xié)議的使用方式可以參考我們的原理版文檔DOC。;

2)標簽在 start 成功之后,就相當于成功進入一個 room,之后,您可以通過 onPushEvent (PUSH_EVT_ROOM_USERLIST = 1020) 事件,收到房間里還有那些人的信息。在視頻通話期間,房間內(nèi)各個成員的進進出出,也都會通過這個事件通知給您的小程序代碼;

3)ROOM_USERLIST 里每一項都是一個二元組(如果是 1v1 的視頻通話,ROOM_USERLIST 里只會有一個人): userid 和 playurl。 userid 代表是哪個用戶, playurl 則是這個用戶遠程畫面的播放地址。您要做的只是使用標簽播放這些遠程畫面的圖像和聲音而已;

4)在 WebRTC 這一端,您可以參考我們的 webrtc API,這套 API 相對于 WebRTC 原生的 API,更適合初學者使用。

本站聲明: 本文章由作者或相關(guān)機構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫毥谦F公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運行,同時企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風險,如企業(yè)系統(tǒng)復雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機 衛(wèi)星通信

要點: 有效應對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅持高質(zhì)量發(fā)展策略,塑強核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運營商 數(shù)字經(jīng)濟

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術(shù)學會聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(shù)(集團)股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉