騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐
一、概述
本文來自騰訊視頻雲終端技術總監rexchang（常青）技術分享，內容分別介紹了微信小程序視音視頻和WebRTC的技術特徵、差別等，並針對二者的技術差別分享和總結了微信小程序視音視頻和WebRTC互通的實現思路以及技術方案。但願能帶給你啓發。javascript
學習交流：php
- 即時通信開發交流3羣：185926912[推薦]html
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》java
（本文同步發佈於：http://www.52im.net/thread-1988-1-1.html）git
二、關於做者
rexchang（常青）：騰訊視頻雲終端技術總監，2008 年畢業加入騰訊，一直從事客戶端研發相關工做，前後參與過 PC QQ、手機QQ、QQ物聯 等產品項目，目前在騰訊視頻雲團隊負責音視頻終端解決方案的優化和落地工做。（常青的另外一篇分享你可能也感興趣：《騰訊技術分享：微信小程序音視頻技術背後的故事》）github
三、相關文章
微信團隊分享的音視頻技術文章：web
《微信團隊分享：微信每日億次實時音視頻聊天背後的技術解密》微信小程序
有關WebRTC的技術文章：
《訪談WebRTC標準之父：WebRTC的過去、如今和將來》
《良心分享：WebRTC 零基礎開發者教程（中文）[附件下載]》
《新手入門：到底什麼是WebRTC服務器，以及它是如何聯接通話的？》
《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》
《基於開源WebRTC開發實時音視頻靠譜嗎？第3方SDK有哪些？》
《開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用》
《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》
《網頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》
《了不得的WebRTC：生態日趨完善，或將實時音視頻技術白菜化》
>> 更多同類文章 ……
四、分別介紹一下小程序音視頻和WebRTC
小程序音視頻是什麼？
2017年騰訊視頻雲團隊跟微信團隊聯合，將視頻雲 SDK 跟微信小程序整合在一塊兒，並經過 <live-pusher> 和 <live-player> 兩個標籤的形式開放內部的功能。經過這兩個標籤，開發者能夠實如今線直播、低延時監控、雙人視頻通話以及多人視頻會議等功能。
微信小視頻音視頻技術的由來，請看這篇：《騰訊技術分享：微信小程序音視頻技術背後的故事》。
那麼WebRTC又是什麼？
WebRTC（Web Real-Time Communication），是一個支持網頁瀏覽器進行實時語音對話或視頻對話的技術，是谷歌收購 GIPS 公司而得到的一項技術，在 Chrome 瀏覽器上無需安裝插件，經過 javascript 就能夠編寫實時音視頻通話程序。
想了解更多WebRTC工程的背後，請閱讀：《訪談WebRTC標準之父：WebRTC的過去、如今和將來》。
五、微信小程序音視頻和WebRTC的區別在哪裏？
若是您跟我同樣是一個實用主義者，那我就簡單從實用主義角度說一下個人結論：小程序音視頻搞定了手機，WebRTC拿下了PC。
若是你對技術比較感興趣，那咱們就能夠從多個技術的角度去列舉二者的區別，下面是一張詳細對比的表格：
實現原理：
小程序音視頻是將騰訊視頻雲的 liteavsdk 嵌入到微信內部實現的，而後經過 <live-pusher> 和 <live-player> 兩個標籤將 SDK 內部的音視頻能力開放出來。因此小程序的標籤起到了開發者 API 的做用，而內部的 SDK 則是真正用來實現音視頻功能。
WebRTC 由谷歌收購 GIPS 得來（這裏不得不提一下，我加入騰訊時所在的第一個團隊就是 QQ 團隊，當時 QQ 的音視頻仍是購買的 GIPS 公司的產品，不過因爲各類不靠譜，後來就轉爲自研路線了）。因此其技術被完整的保留而且加入到了 Google 的 Chrome 瀏覽器內核當中。並且最近蘋果也已經開始在 Safari 瀏覽器中支持 WebRTC 的相關能力。
底層協議：
小程序音視頻的主要協議是目前在直播領域最爲經常使用的 RTMP 推流協議，以及 HTTP-FLV 播放協議，這兩種協議都已經有多年的沉澱並且在互聯網上的資料也是汗牛充棟。
WebRTC的底層則是使用RTP和RTCP兩種數據協議，其中RTP主要用於音視頻數據傳輸，而RTCP則通常用於控制。
移動端碎片化問題：
小程序音視頻因爲是微信統一實現的，並且微信團隊每一個版本都儘可能要求功能對齊，不然寧肯不上，因此在碎片化問題上基本不存在。
WebRTC在這裏則要尷尬的多，一方面Android系統的碎片化自己讓WebRTC的具體表現呈現「百花齊放」的景象，同時，iOS 目前的內嵌WebView（也就是在微信等APP裏打開的各類內嵌網頁）不支持WebRTC也仍是個很麻煩的問題。
擴展性：
小程序音視頻跟隨微信的版本發佈，有什麼問題通常是當前代碼流修正，而後跟隨下一個版本發佈，因此通常一個功能點（好比給 pusher 加一個美顏的功能）或者一個問題點（好比不支持手勢放大）從確立到最終實現（或解決）僅須要一個月的時間，並且微信APP新版本的覆蓋速度也確實挺快。
相比之下，WebRTC則不是一個團隊或者一家公司的問題了，由於它如今已經走標準路線，因此每個新特性都是先肯定標準，而後再推進瀏覽器廠商（包括蘋果）進行跟隨。這裏面的故事就多了，時間也就更久了。
桌面瀏覽器支持：
相信您已經發現，在前面幾個問題的分析上，個人觀點都傾向小程序音視頻。確實，在目前國內的移動領域裏，谷歌和蘋果都不能一家說了算，真正說了算的仍是微信。
可是在桌面瀏覽器這個部分，Chrome目前在PC瀏覽器市場上留到地位的存在決定了 WebRTC 的優點就很大了，開發者能夠在不安裝插件的狀況下就能夠實現本身想要的功能。
相比之下，因爲沒有 Chrome 的原生支持，因此若是咱們要在 PC 上對接小程序音視頻，就須要安裝瀏覽器插件或者經過 wxlite://start 這樣的僞協議喚起本地 exe 應用程序（相似在網頁上打開 QQ 聊天窗口）。
六、微信小程序音視頻和WebRTC並不是零和博弈
小程序音視頻和WebRTC支架並不是零和博藝，雙方都有本身的優點和不足，因此本着「打不過他們，就加入他們」的思路，騰訊視頻雲團隊在2018年春節回來後，就快馬加鞭地開始了小程序音視頻和WebRTC互通的相關工做。
目前，須要向各位開發者彙報的是，在最新版本的微信中，小程序音視頻已經能夠跟WebRTC打通，目前在PC 的Chrome瀏覽器上就能夠跟小程序進行實時音視頻互通。
七、知己知彼，充分了解WebRTC
就像結婚同樣，既然你決定要選擇另外一我的做爲人生下半輩子的伴侶，那你確定會先深刻地瞭解一下TA這我的，好比性格，脾氣，愛好等各個方面。
一樣，咱們要想很好的將小程序音視頻和WebRTC打通，那也必需要多瞭解一下WebRTC，這裏我就說一下我對 WebRTC 這個「人」 在性格上的一些理解。
首先，她雖然長得不太好看，但頗有內涵：
說WebRTC長得很差看，只是個人一種比喻，個人意思是想說WebRTC的學習成本不低，雖然Google作了不少淺顯易懂的PPT來教你怎麼 Getting Start，但真要完整的學進去，仍是須要靜下心來，慢慢地把她當成本身承認的目標去學下去。可是若是你是第一次戀愛（也就是第一次接觸實時音視頻），你會發現學習WebRTC的過程，自己就是了解一個實時音視頻技術細節的過程。
其次，她很是喜歡遷就別人，各類架構方案她都能支持到：
說WebRTC喜歡遷就比人，也是一種比喻，WebRTC所支持的後臺架構很是多（好比 Mixer， Mesh，Router），並且谷歌認爲這些後臺實現都比較簡單，因此既沒有開放後臺相關的源碼，也沒有提供統一的後臺解決方案。這種開放式的設計思路很是好，但反作用就是實現成本高。在真刀真槍的項目落地時，小規模的公司或者開發者就很容易被這種技術門檻擋在門外。尤爲是想要將 WebRTC 真正應用到企業級解決方案中，面對錄製和存檔的剛性需求，就須要花費大量時間進行定製開發。
八、微信小程序音視頻和WebRTC互通方案的確立
瞭解到 WebRTC 的這些特色後，咱們的互通方案也就比較清晰了：
1）首先，小程序音視頻的特色是接口簡單，快速上手，這是小程序的優點；而這一點偏偏是WebRTC的劣勢，因此咱們沒有必要在小程序端爲WebRTC暴露十幾個接口類，而是繼續採用小程序音視頻的 和 標籤來解決問題；
2）其次，WebRTC 的後臺沒有官方實現，那就意味着這裏有很大的發揮空間，騰訊視頻雲就能夠實現一套WebRTC後臺並將其同小程序音視頻所使用RTMP後臺進行打通。簡單來講，騰訊視頻雲要在小程序音視頻和WebRTC之間充當紅娘（更確切的說，應該是翻譯員）的角色。
可是看過《新聞聯播》裏國家領導人之間談話鏡頭的人都知道，這種翻譯是會影響交流速度的。小程序音視頻和WebRTC之間互通，中間引入一個翻譯員，是否是通信延時也就增長了？
其實不會，由於小程序音視頻和WebRTC的視頻編碼標準在常規應用場景中是一致的，都是H.264標準，這是音頻格式不一樣而已。這就意味着，翻譯員要作的事情不多，兩邊基本都能挺對對方在說什麼，因此延時不會增長太多。
九、微信小程序音視頻和WebRTC的成功握手
下圖所展現的就是本次互通問題上所採起的方案：
如上圖所示，本次互通方案的原理以下：
1）首先，微信端的小程序經過騰訊視頻雲SDK將音視頻流推送到騰訊雲 RTMP 服務器；
2）其次，騰訊雲 RTMP 服務器的會對音視頻數據進行初步的轉化處理，而後透傳給騰訊視頻雲的實時音視頻後臺集羣；
3）再次，實時音視頻後臺會再次將數據交給一個叫作 WebRTC-Proxy 的模塊，就在這裏， WebRTC-Proxy 要未來自小程序音視頻的音視頻數據翻譯成 WebRTC 理解的「語言」；
4）最後，在PC上的Chrome瀏覽器，就能夠經過瀏覽器內置的WebRTC模塊跟 WebRTC-Proxy 通信，進而看到小程序端的視頻影像；
5）上面的四個過程倒過來，就能夠實現雙向視頻通話；而將騰訊視頻雲做爲星型結構的中心節點，多個端（無論是小程序仍是Chrome瀏覽器）都接入進來，那就能夠造成多人音視頻解決方案。
十、微信小程序音視頻和WebRTC打通房間邏輯
僅僅完成了音視頻數據在小程序和WebRTC之間的握手還遠遠不夠，由於在一次成功的音視頻通話背後，不只僅是把一端的音視頻數據傳遞到另外一端這麼簡單，還有狀態的同步和成員間的狀態協同。
好比多人視頻通話中，涉及到呼叫和接通的流程，其中一方若是掛斷了，其餘人要收到掛斷的通知。同時，若是有新的參與者加入，那麼其餘人也要收到相應的通知。WebRTC 中有不少組件，好比 RTCPeerConnection 就在處理上訴林林種種的邏輯。可是 WebRTC 的接口中引入的新名詞很是多，對於初學者來講仍是有必定的入門門檻，爲了簡化這裏的邏輯，咱們引入一個叫作「房間」的概念。
所謂房間（Room），就是把同時參與視頻通話的各方圈在一塊兒的一個東西。好比雙人通話中，通話中的兩我的 A 和 B 就能夠認爲在一個房間中。再好比在多人通話中，通話中的五我的（A B C D E）也能夠認爲是在一個房間裏。
有了房間的概念，那咱們就能夠對剛纔說的狀態協同用兩個簡單的動做描述一下：若是有一我的加入了視頻通話，那麼就能夠理解爲他/她已經進房（EnterRoom）了；若是有一個退出了視頻通話，那麼就能夠理解爲他/她已經離開房間（LeaveRoom）了。而房間的門板上始終寫着：「目前在房間裏有哪幾我的」。
有了房間的概念，咱們就能夠將小程序的兩個簡單的 <live-pusher> 和 <live-player> 標籤，同 WebRTC 那一套複雜的 API 進行功能上的對齊，咱們甚至不須要修改咱們在初版中定義的接口，就能夠達成這個目標：
如上圖所示，原理以下：
1） 的 url 接口再也不傳遞 rtmp:// 協議的推流地址，而是傳遞 room:// 協議的推流地址。room:// 協議的使用方式能夠參考咱們的原理版文檔DOC。；
2）<live-pusher> 標籤在 start 成功以後，就至關於成功進入一個 room，以後，您能夠經過 onPushEvent (PUSH_EVT_ROOM_USERLIST = 1020) 事件，收到房間裏還有那些人的信息。在視頻通話期間，房間內各個成員的進進出出，也都會經過這個事件通知給您的小程序代碼；
3）ROOM_USERLIST 裏每一項都是一個二元組（若是是 1v1 的視頻通話，ROOM_USERLIST 裏只會有一我的）: userid 和 playurl。 userid 表明是哪一個用戶， playurl 則是這個用戶遠程畫面的播放地址。您要作的只是使用 <live-player> 標籤播放這些遠程畫面的圖像和聲音而已；
4）在 WebRTC 這一端，您能夠參考咱們的 webrtc API，這套 API 相對於 WebRTC 原生的 API，更適合初學者使用。
十一、來看看最終的接入效果
若是您但願一天內就打通 webrtc 和 小程序音視頻 的互通，那麼我推薦您不要從零開始，由於那會耗費您太多時間去踩坑和 bugfix，推薦您直接使用咱們封裝好的 <webrtc-room> ，這套方案既能夠幫助您完成快速接入，又能知足必定的定製需求。
本次方案的最終接入效果，能夠在從「微信=>發現=>小程序=>騰訊雲視頻雲」，體驗騰訊雲官方 Demo 中的 WebRTC 互通效果：
標籤說明：
標籤是基於 和 實現的用於 WebRTC 互通的自定義組件。若是您但願直接使用 和 標籤完成對接，或者想要了解 的內部原理，能夠參考 DOC。
版本要求：
微信 6.6.6 版本開始支持。
效果演示：
1）PC 端：用 Chrome 瀏覽器打開 體驗頁面 能夠體驗桌面版 WebRTC 的效果；
2）微信端：發現=>小程序=>搜索「騰訊視頻雲」，點擊 WebRTC 功能卡，就能夠體驗跟桌面版 Chrome 互通的效果了。
對接資料：
1）小程序源碼（包含<webrtc-room>的組件源碼以及demo源碼）；
2）PC端源碼（基於Webrtc API實現的Chrome版WebRTC接入源碼（其中 component/WebRTCRoom.js 實現了一個簡單的房間管理功能，component/mainwindow.js包含了對 WebRTC API 的使用代碼））；
3）後臺源碼（實現了一個簡單的房間列表功能，同時包含<webrtc-room>幾個所需參數的生成代碼）。
附錄：更多音視頻技術文章彙總
《即時通信音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通信音視頻開發（九）：實時語音通信的迴音及迴音消除概述》
《即時通信音視頻開發（十）：實時語音通信的迴音消除技術詳解》
《即時通信音視頻開發（十一）：實時語音通信丟包補償技術詳解》
《即時通信音視頻開發（十三）：實時視頻編碼H.264的特色與優點》
《即時通信音視頻開發（十五）：聊聊P2P與實時音視頻的應用狀況》
《即時通信音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
《即時通信音視頻開發（十七）：視頻編碼H.26四、VP8的前世此生》
《學習RFC3550：RTP/RTCP實時傳輸協議基礎知識》
《基於RTMP數據傳輸協議的實時流媒體技術研究（論文全文）》
《還在靠「喂喂喂」測試實時語音通話質量？本文教你科學的評測方法！》
《實現延遲低於500毫秒的1080P實時音視頻直播的實踐分享》
《技術揭祕：支持百萬級粉絲互動的Facebook實時視頻直播》
《理論聯繫實際：實現一個簡單地基於HTML5的實時視頻直播》
《首次披露：快手是如何作到百萬觀衆同場看直播仍能秒開且不卡頓的？》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《七牛雲技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
《實時視頻直播客戶端技術盤點：Native、HTML五、WebRTC、微信小程序》
《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》
《以網遊服務端的網絡接入層設計爲例，理解實時通訊的技術挑戰》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-1988-1-1.html）
- 1. 騰訊技術分享：微信小程序音視頻技術背後的故事
- 2. Android音視頻開發之-WebRTC技術實踐
- 3. 仿騰訊視頻-微信小程序
- 4. 音視頻通話：小議音頻處理與壓縮技術
- 5. DirectX技術實現視頻會議中的音頻通信
- 6. 騰訊實時音視頻（TRTC）研究技術文檔
- 7. K歌、短視頻技術最佳實踐——「唱吧」音視頻技術探索
- 8. 視頻通訊中音視頻處理技術
- 9. 基於 WebRTC 技術的實時通訊服務開發實踐
- 10. 騰訊微信技術架構
- 更多相關文章...
- • XML 相關技術 - XML 教程
- • Hibernate的快照技術 - Hibernate教程
- • Docker容器實戰(一) - 封神Server端技術
- • 三篇文章瞭解 TiDB 技術內幕——說存儲
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. No provider available from registry 127.0.0.1:2181 for service com.ddbuy.ser 解決方法
- 2. Qt5.7以上調用虛擬鍵盤(支持中文)，以及源碼修改(可拖動，水平縮放)
- 3. 軟件測試面試- 購物車功能測試用例設計
- 4. ElasticSearch（概念篇）：你知道的, 爲了搜索…
- 5. redux理解
- 6. gitee創建第一個項目
- 7. 支持向量機之硬間隔（一步步推導，通俗易懂）
- 8. Mysql 異步複製延遲的原因及解決方案
- 9. 如何在運行SEPM配置嚮導時將不可認的複雜數據庫密碼改爲簡單密碼
- 10. windows系統下tftp服務器使用