1、概述
本文來自騰訊視頻云終端技術總監(jiān)rexchang（常青）技術分享，內容分別介紹了微信小程序視音視頻和WebRTC的技術特征、差異等，并針對兩者的技術差異分享和總結了微信小程序視音視頻和WebRTC互通的實現(xiàn)思路以及技術方案。希望能帶給你啟發(fā)。
學習交流：
- 即時通訊開發(fā)交流3群：185926912[推薦]
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
（本文同步發(fā)布于：http://www.52im.net/thread-1988-1-1.html）
2、關于作者
rexchang（常青）：騰訊視頻云終端技術總監(jiān)，2008 年畢業(yè)加入騰訊，一直從事客戶端研發(fā)相關工作，先后參與過 PC QQ、手機QQ、QQ物聯(lián) 等產品項目，目前在騰訊視頻云團隊負責音視頻終端解決方案的優(yōu)化和落地工作。（常青的另一篇分享你可能也感興趣：《騰訊技術分享：微信小程序音視頻技術背后的故事》）
3、相關文章
微信團隊分享的音視頻技術文章：
《騰訊技術分享：微信小程序音視頻技術背后的故事》
《微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密》
《微信多媒體團隊訪談：音視頻開發(fā)的學習、微信的音視頻技術和挑戰(zhàn)等》
《微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術》
《專訪微信視頻技術負責人：微信實時視頻聊天技術的演進》
《騰訊音視頻實驗室：使用AI黑科技實現(xiàn)超低碼率的高清實時視頻聊天》
有關WebRTC的技術文章：
《開源實時音視頻技術WebRTC的現(xiàn)狀》
《簡述開源實時音視頻技術WebRTC的優(yōu)缺點》
《訪談WebRTC標準之父：WebRTC的過去、現(xiàn)在和未來》
《良心分享：WebRTC 零基礎開發(fā)者教程（中文）[附件下載]》
《WebRTC實時音視頻技術的整體架構介紹》
《新手入門：到底什么是WebRTC服務器，以及它是如何聯(lián)接通話的？》
《WebRTC實時音視頻技術基礎：基本架構和協(xié)議棧》
《淺談開發(fā)實時視頻直播平臺的技術要點》
《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》
《基于開源WebRTC開發(fā)實時音視頻靠譜嗎？第3方SDK有哪些？》
《開源實時音視頻技術WebRTC中RTP/RTCP數(shù)據(jù)傳輸協(xié)議的應用》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《實時通信RTC技術棧之：視頻編解碼》
《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》
《網(wǎng)頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》
《了不起的WebRTC：生態(tài)日趨完善，或將實時音視頻技術白菜化》
>> 更多同類文章 ……
4、分別介紹一下小程序音視頻和WebRTC
小程序音視頻是什么？
2017年騰訊視頻云團隊跟微信團隊聯(lián)合，將視頻云 SDK 跟微信小程序整合在一起，并通過 <live-pusher> 和 <live-player> 兩個標簽的形式開放內部的功能。通過這兩個標簽，開發(fā)者可以實現(xiàn)在線直播、低延時監(jiān)控、雙人視頻通話以及多人視頻會議等功能。
微信小視頻音視頻技術的由來，請看這篇：《騰訊技術分享：微信小程序音視頻技術背后的故事》。
那么WebRTC又是什么？
WebRTC（Web Real-Time Communication），是一個支持網(wǎng)頁瀏覽器進行實時語音對話或視頻對話的技術，是谷歌收購 GIPS 公司而獲得的一項技術，在 Chrome 瀏覽器上無需安裝插件，通過 javascript 就可以編寫實時音視頻通話程序。
想了解更多WebRTC工程的背后，請閱讀：《訪談WebRTC標準之父：WebRTC的過去、現(xiàn)在和未來》。
5、微信小程序音視頻和WebRTC的區(qū)別在哪里？
如果您跟我一樣是一個實用主義者，那我就簡單從實用主義角度說一下我的結論：小程序音視頻搞定了手機，WebRTC拿下了PC。
如果你對技術比較感興趣，那我們就可以從多個技術的角度去列舉兩者的區(qū)別，下面是一張詳細對比的表格：
實現(xiàn)原理：
小程序音視頻是將騰訊視頻云的 liteavsdk 嵌入到微信內部實現(xiàn)的，然后通過 <live-pusher> 和 <live-player> 兩個標簽將 SDK 內部的音視頻能力開放出來。所以小程序的標簽起到了開發(fā)者 API 的作用，而內部的 SDK 則是真正用來實現(xiàn)音視頻功能。
WebRTC 由谷歌收購 GIPS 得來（這里不得不提一下，我加入騰訊時所在的第一個團隊就是 QQ 團隊，當時 QQ 的音視頻還是購買的 GIPS 公司的產品，不過由于各種不靠譜，后來就轉為自研路線了）。所以其技術被完整的保留并且加入到了 Google 的 Chrome 瀏覽器內核當中。而且最近蘋果也已經開始在 Safari 瀏覽器中支持 WebRTC 的相關能力。
底層協(xié)議：
小程序音視頻的主要協(xié)議是目前在直播領域最為常用的 RTMP 推流協(xié)議，以及 HTTP-FLV 播放協(xié)議，這兩種協(xié)議都已經有多年的沉淀而且在互聯(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 目前的內嵌WebView（也就是在微信等APP里打開的各種內嵌網(wǎng)頁）不支持WebRTC也還是個很麻煩的問題。
擴展性：
小程序音視頻跟隨微信的版本發(fā)布，有什么問題一般是當前代碼流修正，然后跟隨下一個版本發(fā)布，所以一般一個功能點（比如給 pusher 加一個美顏的功能）或者一個問題點（比如不支持手勢放大）從確立到最終實現(xiàn)（或解決）僅需要一個月的時間，而且微信APP新版本的覆蓋速度也確實挺快。
相比之下，WebRTC則不是一個團隊或者一家公司的問題了，因為它現(xiàn)在已經走標準路線，所以每一個新特性都是先確定標準，然后再推動瀏覽器廠商（包括蘋果）進行跟隨。這里面的故事就多了，時間也就更久了。
桌面瀏覽器支持：
相信您已經發(fā)現(xiàn)，在前面幾個問題的分析上，我的觀點都傾向小程序音視頻。確實，在目前國內的移動領域里，谷歌和蘋果都不能一家說了算，真正說了算的還是微信。
但是在桌面瀏覽器這個部分，Chrome目前在PC瀏覽器市場上留到地位的存在決定了 WebRTC 的優(yōu)勢就很大了，開發(fā)者可以在不安裝插件的情況下就可以實現(xiàn)自己想要的功能。
相比之下，由于沒有 Chrome 的原生支持，所以如果我們要在 PC 上對接小程序音視頻，就需要安裝瀏覽器插件或者通過 wxlite://start 這樣的偽協(xié)議喚起本地 exe 應用程序（類似在網(wǎng)頁上打開 QQ 聊天窗口）。
6、微信小程序音視頻和WebRTC并非零和博弈
小程序音視頻和WebRTC支架并非零和博藝，雙方都有自己的優(yōu)勢和不足，所以本著“打不過他們，就加入他們”的思路，騰訊視頻云團隊在2018年春節(jié)回來后，就馬不停蹄地開始了小程序音視頻和WebRTC互通的相關工作。
目前，需要向各位開發(fā)者匯報的是，在最新版本的微信中，小程序音視頻已經可以跟WebRTC打通，目前在PC 的Chrome瀏覽器上就可以跟小程序進行實時音視頻互通。
7、知己知彼，充分了解WebRTC
就像結婚一樣，既然你決定要選擇另一個人作為人生下半輩子的伴侶，那你肯定會先深入地了解一下TA這個人，比如性格，脾氣，愛好等各個方面。
同樣，我們要想很好的將小程序音視頻和WebRTC打通，那也必須要多了解一下WebRTC，這里我就說一下我對 WebRTC 這個“人” 在性格上的一些理解。
首先，她雖然長得不太好看，但很有內涵：
說WebRTC長得不好看，只是我的一種比喻，我的意思是想說WebRTC的學習成本不低，雖然Google做了很多淺顯易懂的PPT來教你怎么 Getting Start，但真要完整的學進去，還是需要靜下心來，慢慢地把她當成自己認可的目標去學下去。但是如果你是第一次戀愛（也就是第一次接觸實時音視頻），你會發(fā)現(xiàn)學習WebRTC的過程，本身就是了解一個實時音視頻技術細節(jié)的過程。
其次，她非常喜歡遷就別人，各種架構方案她都能支持到：
說WebRTC喜歡遷就比人，也是一種比喻，WebRTC所支持的后臺架構非常多（比如 Mixer， Mesh，Router），而且谷歌認為這些后臺實現(xiàn)都比較簡單，所以既沒有開放后臺相關的源碼，也沒有提供統(tǒng)一的后臺解決方案。這種開放式的設計思路非常好，但副作用就是實現(xiàn)成本高。在真刀真槍的項目落地時，小規(guī)模的公司或者開發(fā)者就很容易被這種技術門檻擋在門外。尤其是想要將 WebRTC 真正應用到企業(yè)級解決方案中，面對錄制和存檔的剛性需求，就需要花費大量時間進行定制開發(fā)。
8、微信小程序音視頻和WebRTC互通方案的確立
了解到 WebRTC 的這些特點后，我們的互通方案也就比較清晰了：
1）首先，小程序音視頻的特點是接口簡單，快速上手，這是小程序的優(yōu)勢；而這一點恰恰是WebRTC的劣勢，所以我們沒有必要在小程序端為WebRTC暴露十幾個接口類，而是繼續(xù)采用小程序音視頻的 和 標簽來解決問題；
2）其次，WebRTC 的后臺沒有官方實現(xiàn)，那就意味著這里有很大的發(fā)揮空間，騰訊視頻云就可以實現(xiàn)一套WebRTC后臺并將其同小程序音視頻所使用RTMP后臺進行打通。簡單來說，騰訊視頻云要在小程序音視頻和WebRTC之間充當紅娘（更確切的說，應該是翻譯員）的角色。
但是看過《新聞聯(lián)播》里國家領導人之間談話鏡頭的人都知道，這種翻譯是會影響交流速度的。小程序音視頻和WebRTC之間互通，中間引入一個翻譯員，是不是通訊延時也就增加了？
其實不會，因為小程序音視頻和WebRTC的視頻編碼標準在常規(guī)應用場景中是一致的，都是H.264標準，這是音頻格式不同而已。這就意味著，翻譯員要做的事情很少，兩邊基本都能挺對對方在說什么，所以延時不會增加太多。
9、微信小程序音視頻和WebRTC的成功握手
下圖所展示的就是本次互通問題上所采取的方案：
如上圖所示，本次互通方案的原理如下：
1）首先，微信端的小程序通過騰訊視頻云SDK將音視頻流推送到騰訊云 RTMP 服務器；
2）其次，騰訊云 RTMP 服務器的會對音視頻數(shù)據(jù)進行初步的轉化處理，然后透傳給騰訊視頻云的實時音視頻后臺集群；
3）再次，實時音視頻后臺會再次將數(shù)據(jù)交給一個叫做 WebRTC-Proxy 的模塊，就在這里， WebRTC-Proxy 要將來自小程序音視頻的音視頻數(shù)據(jù)翻譯成 WebRTC 理解的“語言”；
4）最后，在PC上的Chrome瀏覽器，就可以通過瀏覽器內置的WebRTC模塊跟 WebRTC-Proxy 通訊，進而看到小程序端的視頻影像；
5）上面的四個過程倒過來，就可以實現(xiàn)雙向視頻通話；而將騰訊視頻云作為星型結構的中心節(jié)點，多個端（不管是小程序還是Chrome瀏覽器）都接入進來，那就可以形成多人音視頻解決方案。
10、微信小程序音視頻和WebRTC打通房間邏輯
僅僅完成了音視頻數(shù)據(jù)在小程序和WebRTC之間的握手還遠遠不夠，因為在一次成功的音視頻通話背后，不僅僅是把一端的音視頻數(shù)據(jù)傳遞到另一端這么簡單，還有狀態(tài)的同步和成員間的狀態(tài)協(xié)同。
比如多人視頻通話中，涉及到呼叫和接通的流程，其中一方如果掛斷了，其他人要收到掛斷的通知。同時，如果有新的參與者加入，那么其他人也要收到相應的通知。WebRTC 中有很多組件，比如 RTCPeerConnection 就在處理上訴林林種種的邏輯。但是 WebRTC 的接口中引入的新名詞非常多，對于初學者來說還是有一定的入門門檻，為了簡化這里的邏輯，我們引入一個叫做“房間”的概念。
所謂房間（Room），就是把同時參與視頻通話的各方圈在一起的一個東西。比如雙人通話中，通話中的兩個人 A 和 B 就可以認為在一個房間中。再比如在多人通話中，通話中的五個人（A B C D E）也可以認為是在一個房間里。
有了房間的概念，那我們就可以對剛才說的狀態(tài)協(xié)同用兩個簡單的動作描述一下：如果有一個人加入了視頻通話，那么就可以理解為他/她已經進房（EnterRoom）了；如果有一個退出了視頻通話，那么就可以理解為他/她已經離開房間（LeaveRoom）了。而房間的門板上始終寫著：“目前在房間里有哪幾個人”。
有了房間的概念，我們就可以將小程序的兩個簡單的 <live-pusher> 和 <live-player> 標簽，同 WebRTC 那一套復雜的 API 進行功能上的對齊，我們甚至不需要修改我們在第一版中定義的接口，就可以達成這個目標：
如上圖所示，原理如下：
1） 的 url 接口不再傳遞 rtmp:// 協(xié)議的推流地址，而是傳遞 room:// 協(xié)議的推流地址。room:// 協(xié)議的使用方式可以參考我們的原理版文檔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，更適合初學者使用。
11、來看看最終的接入效果
如果您希望一天內就打通 webrtc 和 小程序音視頻 的互通，那么我推薦您不要從零開始，因為那會耗費您太多時間去踩坑和 bugfix，推薦您直接使用我們封裝好的 <webrtc-room> ，這套方案既可以幫助您完成快速接入，又能滿足一定的定制需求。
本次方案的最終接入效果，可以在從“微信=>發(fā)現(xiàn)=>小程序=>騰訊云視頻云”，體驗騰訊云官方 Demo 中的 WebRTC 互通效果：
標簽說明：
標簽是基于 和 實現(xiàn)的用于 WebRTC 互通的自定義組件。如果您希望直接使用 和 標簽完成對接，或者想要了解 的內部原理，可以參考 DOC。
版本要求：
微信 6.6.6 版本開始支持。
效果演示：
1）PC 端：用 Chrome 瀏覽器打開 體驗頁面 可以體驗桌面版 WebRTC 的效果；
2）微信端：發(fā)現(xiàn)=>小程序=>搜索“騰訊視頻云”，點擊 WebRTC 功能卡，就可以體驗跟桌面版 Chrome 互通的效果了。
對接資料：
1）小程序源碼（包含<webrtc-room>的組件源碼以及demo源碼）；
2）PC端源碼（基于Webrtc API實現(xiàn)的Chrome版WebRTC接入源碼（其中 component/WebRTCRoom.js 實現(xiàn)了一個簡單的房間管理功能，component/mainwindow.js包含了對 WebRTC API 的使用代碼））；
3）后臺源碼（實現(xiàn)了一個簡單的房間列表功能，同時包含<webrtc-room>幾個所需參數(shù)的生成代碼）。
附錄：更多音視頻技術文章匯總
《即時通訊音視頻開發(fā)（一）：視頻編解碼之理論概述》
《即時通訊音視頻開發(fā)（二）：視頻編解碼之數(shù)字視頻介紹》
《即時通訊音視頻開發(fā)（三）：視頻編解碼之編碼基礎》
《即時通訊音視頻開發(fā)（四）：視頻編解碼之預測技術介紹》
《即時通訊音視頻開發(fā)（五）：認識主流視頻編碼技術H.264》
《即時通訊音視頻開發(fā)（六）：如何開始音頻編解碼技術的學習》
《即時通訊音視頻開發(fā)（七）：音頻基礎及編碼原理入門》
《即時通訊音視頻開發(fā)（八）：常見的實時語音通訊編碼標準》
《即時通訊音視頻開發(fā)（九）：實時語音通訊的回音及回音消除概述》
《即時通訊音視頻開發(fā)（十）：實時語音通訊的回音消除技術詳解》
《即時通訊音視頻開發(fā)（十一）：實時語音通訊丟包補償技術詳解》
《即時通訊音視頻開發(fā)（十二）：多人實時音視頻聊天架構探討》
《即時通訊音視頻開發(fā)（十三）：實時視頻編碼H.264的特點與優(yōu)勢》
《即時通訊音視頻開發(fā)（十四）：實時音視頻數(shù)據(jù)傳輸協(xié)議介紹》
《即時通訊音視頻開發(fā)（十五）：聊聊P2P與實時音視頻的應用情況》
《即時通訊音視頻開發(fā)（十六）：移動端實時音視頻開發(fā)的幾個建議》
《即時通訊音視頻開發(fā)（十七）：視頻編碼H.264、VP8的前世今生》
《實時語音聊天中的音頻處理與編碼壓縮技術簡述》
《網(wǎng)易視頻云技術分享：音頻處理與壓縮技術快速入門》
《學習RFC3550：RTP/RTCP實時傳輸協(xié)議基礎知識》
《基于RTMP數(shù)據(jù)傳輸協(xié)議的實時流媒體技術研究（論文全文）》
《聲網(wǎng)架構師談實時音視頻云的實現(xiàn)難點(視頻采訪)》
《淺談開發(fā)實時視頻直播平臺的技術要點》
《還在靠“喂喂喂”測試實時語音通話質量？本文教你科學的評測方法！》
《實現(xiàn)延遲低于500毫秒的1080P實時音視頻直播的實踐分享》
《移動端實時視頻直播技術實踐：如何做到實時秒開、流暢不卡》
《如何用最簡單的方法測試你的實時音視頻方案》
《技術揭秘：支持百萬級粉絲互動的Facebook實時視頻直播》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《移動端實時音視頻直播技術詳解（一）：開篇》
《移動端實時音視頻直播技術詳解（二）：采集》
《移動端實時音視頻直播技術詳解（三）：處理》
《移動端實時音視頻直播技術詳解（四）：編碼和封裝》
《移動端實時音視頻直播技術詳解（五）：推流和傳輸》
《移動端實時音視頻直播技術詳解（六）：延遲優(yōu)化》
《理論聯(lián)系實際：實現(xiàn)一個簡單地基于HTML5的實時視頻直播》
《IM實時音視頻聊天時的回聲消除技術詳解》
《淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標》
《如何優(yōu)化傳輸機制來實現(xiàn)實時音視頻的超低延遲？》
《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》
《Android直播入門實踐：動手搭建一套簡單的直播系統(tǒng)》
《網(wǎng)易云信實時視頻直播在TCP數(shù)據(jù)傳輸層的一些優(yōu)化思路》
《實時音視頻聊天技術分享：面向不可靠網(wǎng)絡的抗丟包編解碼器》
《P2P技術如何將實時視頻直播帶寬降低75%？》
《專訪微信視頻技術負責人：微信實時視頻聊天技術的演進》
《騰訊音視頻實驗室：使用AI黑科技實現(xiàn)超低碼率的高清實時視頻聊天》
《微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密》
《近期大熱的實時直播答題系統(tǒng)的實現(xiàn)思路與技術難點分享》
《福利貼：最全實時音視頻開發(fā)要用到的開源工程匯總》
《七牛云技術分享：使用QUIC協(xié)議實現(xiàn)實時視頻直播0卡頓！》
《實時音視頻聊天中超低延遲架構的思考與技術實踐》
《理解實時音視頻聊天中的延時問題一篇就夠》
《實時視頻直播客戶端技術盤點：Native、HTML5、WebRTC、微信小程序》
《寫給小白的實時音視頻技術入門提綱》
《微信多媒體團隊訪談：音視頻開發(fā)的學習、微信的音視頻技術和挑戰(zhàn)等》
《騰訊技術分享：微信小程序音視頻技術背后的故事》
《微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術》
《新浪微博技術分享：微博短視頻服務的優(yōu)化實踐之路》
《實時音頻的混音在視頻直播應用中的技術原理和實踐總結》
《以網(wǎng)游服務端的網(wǎng)絡接入層設計為例，理解實時通信的技術挑戰(zhàn)》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-1988-1-1.html）