1、前言
2017 年 12 月，微信小程序向開發者開放了實時音視頻能力，給業內帶來廣闊的想象空間。連麥互動視頻直播技術在 2016 年直播風口中成為視頻直播的標配，然而只有在原生的 APP 上才能保障良好的用戶體驗。
那時候，在微信小程序中無法進行實時音視頻互動。微信小程序在去年 12 月宣布開放實時音視頻能力，再加上去年 6 月蘋果宣布即將支持 WebRTC，業內一下子千樹萬樹梨花開，前途一片光明。
連麥互動直播技術和微信小程序以及 WebRTC 能產生怎么樣的化學作用？開發者在微信小程序或者瀏覽器 WebRTC 上實現連麥互動直播技術的時候，需要知道什么和考慮什么？
連麥視頻直播的客戶端主要包括：原生 APP、瀏覽器 H5、瀏覽器 WebRTC、微信小程序。瀏覽器上的應用包括 H5 和 WebRTC，前者可以拉流觀看，后者可以實現推流和拉流。
學習交流：
- 即時通訊開發交流3群：185926912[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發布于：http://www.52im.net/thread-1564-1-1.html）
2、本文作者
冼牛：即構科技資深語音視頻專家，北京郵電大學計算機碩士，香港大學工商管理碩士，多年從事語音視頻云服務技術研究，專注互動直播技術、語音視頻社交和實時游戲語音。
作者的文章《近期大熱的實時直播答題系統的實現思路與技術難點分享》、《IM實時音視頻聊天時的回聲消除技術詳解》也已整理并發布于即時通訊網，有興趣的可以看看。
3、直播技術文章參考
《七牛云技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
《實時音視頻聊天中超低延遲架構的思考與技術實踐》
《理解實時音視頻聊天中的延時問題一篇就夠》
《淺談開發實時視頻直播平臺的技術要點》
《實現延遲低于500毫秒的1080P實時音視頻直播的實踐分享》
《移動端實時視頻直播技術實踐：如何做到實時秒開、流暢不卡》
《技術揭秘：支持百萬級粉絲互動的Facebook實時視頻直播》
《移動端實時音視頻直播技術詳解（一）：開篇》
《移動端實時音視頻直播技術詳解（二）：采集》
《移動端實時音視頻直播技術詳解（三）：處理》
《移動端實時音視頻直播技術詳解（四）：編碼和封裝》
《移動端實時音視頻直播技術詳解（五）：推流和傳輸》
《移動端實時音視頻直播技術詳解（六）：延遲優化》
《理論聯系實際：實現一個簡單地基于HTML5的實時視頻直播》
《淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標》
《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》
《Android直播入門實踐：動手搭建一套簡單的直播系統》
《網易云信實時視頻直播在TCP數據傳輸層的一些優化思路》
《P2P技術如何將實時視頻直播帶寬降低75%？》
>> 更多同類文章 ……
4、視頻直播客戶端技術之Native APP
原生 APP 終端音視頻引擎的結構框圖如下，基本包括了音頻引擎、視頻引擎和網絡傳輸，合稱實時語音視頻終端引擎。這里還包含底層的音視頻采集和渲染，還有網絡的輸入輸出能力，這是操作系統開放的能力。
原生 APP 有個天然的好處，它是直接和操作系統打交道的，操作系統開放的資源和能力它都可以直接用，比如說音視頻的采集渲染，還有網絡的輸入輸出。套用一句時髦的廣告語：“沒有中間商賺差價”，直接和操作系統對接，可以獲得比較好的用戶體驗。
在原生 APP 上實現連麥直播的優勢是，對上面所說的七個環節有較好的把控，可以獲得比較低的延遲，能自研實現語音前處理 3A 算法，包括回聲消除，還有對抖動緩沖策略和碼率自適應的策略都有比較好的把控。另外，可以自主選擇使用 RTMP 協議還是基于 UDP 的私有協議，對抗弱網環境更加有保障。
市面上比較流行的前處理技術，比如美顏、掛件、變聲等，原生 APP 都可以通過開放前處理接口讓開發者實現或者對接這些技術。為什么要強調這個呢？因為瀏覽器 WebRTC 和微信小程序都沒有開放前處理接口，開發者沒有辦法自行實現或者對接第三方的美顏或者掛件等技術模塊。
在原生 APP 上，開發者可以得到全面的把控能力，讓用戶可以獲得更好的體驗。主流的視頻直播平臺都有自己的原生 APP 平臺，而瀏覽器和微信小程序相對來說是輔助的。原生 APP 的用戶體驗是最好的，而且對開發者來說也是最可控的。
在原生 APP 上實現連麥直播的劣勢是什么呢？開發門檻高，開發周期長、人力成本高。另外，從獲取用戶和傳播的角度來講，也沒有瀏覽器和微信小程序那么便利。
5、視頻直播客戶端技術之瀏覽器（HTML5）
瀏覽器 H5 就像一個硬幣有兩面，有好處也有劣勢，好處是開發成本低，容易傳播，劣勢是只能拉流，不能推流，不能做到多個用戶連麥直播。另外，在瀏覽器 H5 上延遲也是比較大。如果使用 RTMP 或者 HTTP-FLV，延遲會在 1 秒到 3 秒之間，如果用 HLS 延遲會大于 8 秒甚至 10 秒，這么大的延遲就根本就不允許實現連麥直播。
使用這三種協議都是通過瀏覽器 H5 中的播放器來播放的。在多主播連麥互動的場景中，一個播放器里面只能播一路視頻流，三個主播就得三個播放器，因此看不到多個主播同框連麥互動的情形。如果要看到多個主播同框互動的畫面，就必須把多路流混合成一路流，在單個播放器里面播放。
另外，瀏覽器 H5 的源代碼是開放的。如果在瀏覽器上把音視頻終端引擎實現了，相當于對外公開了所有核心的源代碼。因此，還沒有見過哪個廠商在瀏覽器 H5 上完整地把音視頻引擎真正做出來。即使你愿意做出來，瀏覽器也不會允許你這樣做，開發者和操作系統之間隔著瀏覽器，如果瀏覽器不把操作系統的核心能力開放給開發者，開發者就不能自主采集和渲染，不能掌控網絡輸入輸出，類似流控碼控等功能無法實現。
在瀏覽器 H5 中也可以通過 websocket 來傳輸，用 jsmpeg 來播放，視頻編解碼的格式用 mpeg1。
mpeg1 是一個比較老的媒體格式，所有瀏覽器都支持。在瀏覽器中使用 jsmpeg 播放器播放 mpeg1，所有瀏覽器也可以支持。這么做可以獲得比較低的延遲，但是還是無法推流，沒辦法實現連麥直播。
6、視頻直播客戶端技術之瀏覽器（WebRTC）
大家可能會覺得很遺憾，瀏覽器 H5 雖然很容易傳播，開發簡單但是體驗欠佳，不能連麥直播。那么在瀏覽器上能不能推流，能不能實現連麥直播呢？答案是可以的，那就要用到 WebRTC。
這里說的 WebRTC 是指已經被內嵌到瀏覽器里面，被瀏覽器支持的 WebRTC，而不是 WebRTC 的源代碼。部分主流瀏覽器內嵌了 WebRTC，對開發者開放了瀏覽器的實時音視頻能力。
上圖是 WebRTC 的結構圖。我們可以看到 WebRTC 包括了音頻引擎，視頻引擎、傳輸引擎等，最底層的虛線框表示可以重載，也就是說瀏覽器把最底層的音視頻渲染和網絡傳輸的底層能力開放給開發者，開發者可以根據自己的需求選擇是否進行重載。音頻引擎中，包括了兩個編解碼器：iSAC 和 iLBC，前者針對寬帶和超寬帶的音頻編解碼，后者針對窄帶音頻編解碼。
音頻引擎還包括了音頻抖動緩沖，回聲消除和噪音抑制模塊等。抖動緩沖中的 NetEQ 算法可以說是 WebRTC 里面的精華之一。
視頻引擎中，包括了 VP8 和 VP9 的視頻編解碼器，甚至是即將到來的 AV1。視頻引擎還包括視頻抖動緩沖和圖像質量增強等模塊。傳輸引擎，WebRTC 使用的是 SRTP（Secured Realtime Transport Protocol）安全實時傳輸協議。
最后，WebRTC 采取 P2P 的通信方式，沒有媒體服務器等后端的實現。以上是 WebRTC 的簡單介紹。
瀏覽器 WebRTC 一般的優勢和劣勢這里就不再重復，請大家自行百度，這里只說重點。瀏覽器 WebRTC 的好處就是實現了相對完整的音視頻終端引擎，允許在瀏覽器上推流，可以實現連麥直播。
然而，瀏覽器 WebRTC 也有不足：
1）沒有開放前處理接口，美顏和掛件這些模塊沒辦法接入第三方的或者自研方案；
2）媒體服務器后端沒有實現，開發者要實現媒體服務器，然后通過開源 WebRTC 網關（比如說 janus）接入；
3）編解碼器、抖動緩沖和語音前處理 3A 等能力只能依靠 WebRTC，不能自行定制化；
4）部分主流瀏覽器是不支持 WebRTC 的，特別是蘋果的瀏覽器。雖然說去年蘋果宣布支持 WebRTC, 但是目前 iOS Safari 最新版本對 WebRTC 的支持并不好，iOS Safari 的主流版本并不支持 WebRTC，在 iOS 上面微信瀏覽器也是不支持 WebRTC 的。
由于 WebRTC 不提供媒體服務器的實現，因此需要把瀏覽器 WebRTC 接入到媒體服務器后端，這個可以是自研的，也可以是第三方的服務。瀏覽器 WebRTC 和媒體服務器后端之間的協議和媒體格式是不一樣的，因此要做協議和格式的轉換。WebRTC 用的基于 UDP 的 SRTP，需要把它轉換成媒體服務器的基于 UDP 的私有協議。另外，媒體格式也需要轉換，因為 WebRTC 中語音視頻格式默認用的是 VP8 或者 VP9。同時實時傳輸網絡中有關信令調度也需要做一些調整。瀏覽器 WebRTC 和媒體服務器后端之間的接入層也可以采用開源的 WebRTC Gateway（比如說 janus）來實現。
瀏覽器是類似操作系統的一種超級應用，它坐擁重要的流量入口，然而它也是開發者和操作系統之間的“中間商”。開發者通過 WebRTC 獲得瀏覽器開放的實時音視頻能力，然而也必須要承受 WebRTC 帶來的痛苦。
7、視頻直播客戶端技術之微信小程序
微信小程序是什么？是跑在微信上面的輕型應用。微信是什么？是類操作系統的超級應用。這些特征和瀏覽器以及 H5 是不是很接近？H5 是瀏覽器支持的輕型應用，而瀏覽器是類操作系統的超級應用。瀏覽器背后是各大國際科技巨頭，不像微信這樣背后只有騰訊一個互聯網巨頭。因此，從這個角度來看，微信小程序、瀏覽器 WebRTC 和 H5 是有相通之處的。
微信小程序可以類比為瀏覽器 H5 那樣的客戶端和服務器的結構。其中 HTML 對應微信小程序的 WXML，CSS 對應小程序的 WXSS，小程序的腳本語言和 JS 是一樣的，只是框架不一樣。微信小程序提供了兩個標簽，一個是，一個是。就是推流，就是拉流，可以實現單向直播或者連麥直播。小程序提供兩種模式：LIVE 和 RTC，LIVE 支持單向直播，RTC 支持低延遲的連麥直播。目前微信小程序推流采用 RTMP 協議，如果要和私有協議互通，需要進行協議轉換。
微信小程序開放了實時音視頻能力，對業界來說是重大利好。然而，根據上面的信息和邏輯，我們也看到采用微信小程序實現連麥互動直播的好處和不足。
好處有三點：
1）開發成本低，開發周期短，基本和 H5 的開發難度差不多；
2）很容易傳播和獲客，充分利用好微信的優質流量；
3）可以推流和拉流，允許實現連麥直播和實時語音視頻通話。
不足有四點：
1）你會受制于微信小程序的實時音視頻能力，比如說，如果它的回聲消除有某些問題，你只能等微信團隊按照自己的節奏來優化，而自己沒有任何辦法去優化；
2）小程序沒有開放前處理接口，只能使用小程序自帶的美顏或者變聲功能（如果有），不能對接自行研發或者第三方的美顏或者變聲模塊；
3）通過 RTMP 協議推流和拉流，不能和基于 UDP 的私有協議互通連麥。如果要實現和基于 UDP 的私有協議互通連麥，就必須要增加接入層來轉換協議格式甚至媒體格式；
4）沒有實現后端媒體服務器，開發者必須要自行實現媒體服務器，或者把微信小程序接入到第三方的實時通信網絡。
瀏覽器通過 WebRTC 開放了瀏覽器的實時音視頻能力，而微信通過小程序開放了微信的實時音視頻能力，在兩個類操作系統的平臺上允許開發者去實現連麥直播和實時音視頻通話。然而，無論 WebRTC 還是小程序只是在終端上帶你入門，對開發者來說，要真正實現整套系統，還有很多工作需要做的。
如果要將微信小程序接入實時音視頻傳輸網絡，中間得有接入服務器，我們叫接入層。在接入層我們需要做協議的轉換，比如說，如果實時音視頻傳輸網絡是使用基于 UDP 的私有協議，那么要把 RTMP 協議轉為基于 UDP 的私有協議。還有媒體格式的轉換，如果和實時傳輸網絡的媒體格式不一樣，還需要進行轉換。
8、視頻直播客戶端技術之WebRTC 通過WebView接入小程序
還有別的方法在小程序上做連麥直播互動嗎？必須要使用微信小程序開放的語音視頻能力嗎？也不一定。下圖展示了我在市面上看過的一個技術方案，它繞過了微信小程序實時語音視頻能力，通過微信小程序 WebView 組件實現了連麥直播的方案。這里和大家分享一下。
這個方案的基本思路是利用 WebView 的瀏覽器特點，在 WebView 內使用 WebRTC 的 Web API，從而在小程序上獲得實時音視頻能力。上圖是這個方案的架構圖。最底層是微信小程序的基礎能力。上一層是 WebView，微信小程序的 WebView 類似瀏覽器，那么就可能會支持 WebRTC。然而必須要注意到，微信小程序的 WebView 在安卓平臺上支持 WebRTC，但在 iOS 平臺上面不支持 WebRTC。
雖然這個方案理論上也能在微信小程序上實現連麥直播，但是它有以下的局限性：
1）在 iOS 平臺上，微信小程序不支持這個方案，上面已經說過；
2）小程序 WebView 不是完整的瀏覽器，要比普通瀏覽器表現差而且有很多的限制；
3）開發者和操作系統之間隔了好幾層：微信底層，小程序，WebView，WebRTC，然后才是開發者的小程序應用。每一層的抽象都會帶來性能上的消耗，都會影響到最終的體驗。
這個方案本質上還是一個基于 WebRTC 的解決方案，沒有用到微信小程序開放的實時音視頻能力，而是快速地借助 WebView 組件，劍走偏鋒，十分討巧地在微信小程序里使用了 WebRTC。
9、本文小結
連麥直播技術逐步在原生 APP, 瀏覽器 H5，瀏覽器 WebRTC，微信小程序上延伸，衍生出更加豐富的生態，提供更加便捷和良好的用戶體驗，對視頻直播平臺和用戶來說是好消息。然而，欲帶皇冠，必承其重。特別是在瀏覽器 WebRTC 和微信小程序上，開發者要充分理解這些類型終端的特點和局限，才能更好地在上面利用連麥直播技術進行創新，服務用戶。
附錄：更多實時音視頻技術文章匯總
[1] 開源實時音視頻技術WebRTC的文章：
《開源實時音視頻技術WebRTC的現狀》
《簡述開源實時音視頻技術WebRTC的優缺點》
《訪談WebRTC標準之父：WebRTC的過去、現在和未來》
《良心分享：WebRTC 零基礎開發者教程（中文）[附件下載]》
《WebRTC實時音視頻技術的整體架構介紹》
《新手入門：到底什么是WebRTC服務器，以及它是如何聯接通話的？》
《WebRTC實時音視頻技術基礎：基本架構和協議棧》
《淺談開發實時視頻直播平臺的技術要點》
《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》
《基于開源WebRTC開發實時音視頻靠譜嗎？第3方SDK有哪些？》
《開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《實時通信RTC技術棧之：視頻編解碼》
《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》
《網頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》
>> 更多同類文章 ……
[2] 實時音視頻開發的其它精華資料：
《即時通訊音視頻開發（一）：視頻編解碼之理論概述》
《即時通訊音視頻開發（二）：視頻編解碼之數字視頻介紹》
《即時通訊音視頻開發（三）：視頻編解碼之編碼基礎》
《即時通訊音視頻開發（四）：視頻編解碼之預測技術介紹》
《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》
《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》
《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》
《即時通訊音視頻開發（九）：實時語音通訊的回音及回音消除概述》
《即時通訊音視頻開發（十）：實時語音通訊的回音消除技術詳解》
《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》
《即時通訊音視頻開發（十二）：多人實時音視頻聊天架構探討》
《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》
《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》
《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》
《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
《即時通訊音視頻開發（十七）：視頻編碼H.264、VP8的前世今生》
《實時語音聊天中的音頻處理與編碼壓縮技術簡述》
《網易視頻云技術分享：音頻處理與壓縮技術快速入門》
《學習RFC3550：RTP/RTCP實時傳輸協議基礎知識》
《基于RTMP數據傳輸協議的實時流媒體技術研究（論文全文）》
《聲網架構師談實時音視頻云的實現難點(視頻采訪)》
《淺談開發實時視頻直播平臺的技術要點》
《還在靠“喂喂喂”測試實時語音通話質量？本文教你科學的評測方法！》
《實現延遲低于500毫秒的1080P實時音視頻直播的實踐分享》
《移動端實時視頻直播技術實踐：如何做到實時秒開、流暢不卡》
《如何用最簡單的方法測試你的實時音視頻方案》
《技術揭秘：支持百萬級粉絲互動的Facebook實時視頻直播》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《移動端實時音視頻直播技術詳解（一）：開篇》
《移動端實時音視頻直播技術詳解（二）：采集》
《移動端實時音視頻直播技術詳解（三）：處理》
《移動端實時音視頻直播技術詳解（四）：編碼和封裝》
《移動端實時音視頻直播技術詳解（五）：推流和傳輸》
《移動端實時音視頻直播技術詳解（六）：延遲優化》
《理論聯系實際：實現一個簡單地基于HTML5的實時視頻直播》
《IM實時音視頻聊天時的回聲消除技術詳解》
《淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標》
《如何優化傳輸機制來實現實時音視頻的超低延遲？》
《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》
《Android直播入門實踐：動手搭建一套簡單的直播系統》
《網易云信實時視頻直播在TCP數據傳輸層的一些優化思路》
《實時音視頻聊天技術分享：面向不可靠網絡的抗丟包編解碼器》
《P2P技術如何將實時視頻直播帶寬降低75%？》
《專訪微信視頻技術負責人：微信實時視頻聊天技術的演進》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密》
《近期大熱的實時直播答題系統的實現思路與技術難點分享》
《福利貼：最全實時音視頻開發要用到的開源工程匯總》
《七牛云技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
《實時音視頻聊天中超低延遲架構的思考與技術實踐》
《理解實時音視頻聊天中的延時問題一篇就夠》
《實時視頻直播客戶端技術盤點：Native、HTML5、WebRTC、微信小程序》
>> 更多同類文章 ……
（本文同步發布于：http://www.52im.net/thread-1564-1-1.html）