1、前言
2017 年 12 月，微信小程序向開發者開放了實時音視頻能力，給業內帶來廣闊的想象空間。連麥互動視頻直播技術在 2016 年直播風口中成為視頻直播的標配，然而只有在原生的 APP 上才能保障良好的用戶體驗。
那時候，在微信小程序中無法進行實時音視頻互動。微信小程序在去年 12 月宣佈開放實時音視頻能力，再加上去年 6 月蘋果宣佈即將支持 WebRTC，業內一下子千樹萬樹梨花開，前途一片光明。
連麥互動直播技術和微信小程序以及 WebRTC 能產生怎麼樣的化學作用？開發者在微信小程序或者瀏覽器 WebRTC 上實現連麥互動直播技術的時候，需要知道什麼和考慮什麼？
連麥視頻直播的客戶端主要包括：原生 APP、瀏覽器 H5、瀏覽器 WebRTC、微信小程序。瀏覽器上的應用包括 H5 和 WebRTC，前者可以拉流觀看，後者可以實現推流和拉流。
2、視頻直播客戶端技術之Native APP
原生 APP 終端音視頻引擎的結構框圖如下，基本包括了音頻引擎、視頻引擎和網絡傳輸，合稱實時語音視頻終端引擎。這裡還包含底層的音視頻採集和渲染，還有網絡的輸入輸出能力，這是操作系統開放的能力。
原生 APP 有個天然的好處，它是直接和操作系統打交道的，操作系統開放的資源和能力它都可以直接用，比如說音視頻的採集渲染，還有網絡的輸入輸出。套用一句時髦的廣告語：“沒有中間商賺差價”，直接和操作系統對接，可以獲得比較好的用戶體驗。
在原生 APP 上實現連麥直播的優勢是，對上面所說的七個環節有較好的把控，可以獲得比較低的延遲，能自研實現語音前處理 3A 算法，包括回聲消除，還有對抖動緩衝策略和碼率自適應的策略都有比較好的把控。另外，可以自主選擇使用 RTMP 協議還是基於 UDP 的私有協議，對抗弱網環境更加有保障。
市面上比較流行的前處理技術，比如美顏、掛件、變聲等，原生 APP 都可以通過開放前處理接口讓開發者實現或者對接這些技術。為什麼要強調這個呢？因為瀏覽器 WebRTC 和微信小程序都沒有開放前處理接口，開發者沒有辦法自行實現或者對接第三方的美顏或者掛件等技術模塊。
在原生 APP 上，開發者可以得到全面的把控能力，讓用戶可以獲得更好的體驗。主流的視頻直播平臺都有自己的原生 APP 平臺，而瀏覽器和微信小程序相對來說是輔助的。原生 APP 的用戶體驗是最好的，而且對開發者來說也是最可控的。
在原生 APP 上實現連麥直播的劣勢是什麼呢？開發門檻高，開發週期長、人力成本高。另外，從獲取用戶和傳播的角度來講，也沒有瀏覽器和微信小程序那麼便利。
3、視頻直播客戶端技術之瀏覽器（HTML5）
瀏覽器 H5 就像一個硬幣有兩面，有好處也有劣勢，好處是開發成本低，容易傳播，劣勢是隻能拉流，不能推流，不能做到多個用戶連麥直播。另外，在瀏覽器 H5 上延遲也是比較大。如果使用 RTMP 或者 HTTP-FLV，延遲會在 1 秒到 3 秒之間，如果用 HLS 延遲會大於 8 秒甚至 10 秒，這麼大的延遲就根本就不允許實現連麥直播。
使用這三種協議都是通過瀏覽器 H5 中的播放器來播放的。在多主播連麥互動的場景中，一個播放器裡面只能播一路視頻流，三個主播就得三個播放器，因此看不到多個主播同框連麥互動的情形。如果要看到多個主播同框互動的畫面，就必須把多路流混合成一路流，在單個播放器裡面播放。
另外，瀏覽器 H5 的源代碼是開放的。如果在瀏覽器上把音視頻終端引擎實現了，相當於對外公開了所有核心的源代碼。因此，還沒有見過哪個廠商在瀏覽器 H5 上完整地把音視頻引擎真正做出來。即使你願意做出來，瀏覽器也不會允許你這樣做，開發者和操作系統之間隔著瀏覽器，如果瀏覽器不把操作系統的核心能力開放給開發者，開發者就不能自主採集和渲染，不能掌控網絡輸入輸出，類似流控碼控等功能無法實現。
在瀏覽器 H5 中也可以通過 websocket 來傳輸，用 jsmpeg 來播放，視頻編解碼的格式用 mpeg1。
mpeg1 是一個比較老的媒體格式，所有瀏覽器都支持。在瀏覽器中使用 jsmpeg 播放器播放 mpeg1，所有瀏覽器也可以支持。這麼做可以獲得比較低的延遲，但是還是無法推流，沒辦法實現連麥直播。
4、視頻直播客戶端技術之瀏覽器（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 也有不足：
- 沒有開放前處理接口，美顏和掛件這些模塊沒辦法接入第三方的或者自研方案；
- 媒體服務器後端沒有實現，開發者要實現媒體服務器，然後通過開源 WebRTC 網關（比如說 janus）接入；
- 編解碼器、抖動緩衝和語音前處理 3A 等能力只能依靠 WebRTC，不能自行定製化；
- 部分主流瀏覽器是不支持 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 帶來的痛苦。
微信小程序是什麼？是跑在微信上面的輕型應用。微信是什麼？是類操作系統的超級應用。這些特徵和瀏覽器以及 H5 是不是很接近？H5 是瀏覽器支持的輕型應用，而瀏覽器是類操作系統的超級應用。瀏覽器背後是各大國際科技巨頭，不像微信這樣背後只有騰訊一個互聯網巨頭。因此，從這個角度來看，微信小程序、瀏覽器 WebRTC 和 H5 是有相通之處的。
微信小程序可以類比為瀏覽器 H5 那樣的客戶端和服務器的結構。其中 HTML 對應微信小程序的 WXML，CSS 對應小程序的 WXSS，小程序的腳本語言和 JS 是一樣的，只是框架不一樣。微信小程序提供了兩個標籤，一個是<live-pusher>，一個是<live-player>。<live-pusher>就是推流，<live-player>就是拉流，可以實現單向直播或者連麥直播。小程序提供兩種模式：LIVE 和 RTC，LIVE 支持單向直播，RTC 支持低延遲的連麥直播。目前微信小程序推流採用 RTMP 協議，如果要和私有協議互通，需要進行協議轉換。
/<live-player>/<live-pusher>/<live-player>/<live-pusher>
微信小程序開放了實時音視頻能力，對業界來說是重大利好。然而，根據上面的信息和邏輯，我們也看到採用微信小程序實現連麥互動直播的好處和不足。
好處有三點：
- 1）開發成本低，開發週期短，基本和 H5 的開發難度差不多；
- 2）很容易傳播和獲客，充分利用好微信的優質流量；
- 3）可以推流和拉流，允許實現連麥直播和實時語音視頻通話。
不足有四點：
- 1）你會受制於微信小程序的實時音視頻能力，比如說，如果它的回聲消除有某些問題，你只能等微信團隊按照自己的節奏來優化，而自己沒有任何辦法去優化；
- 2）小程序沒有開放前處理接口，只能使用小程序自帶的美顏或者變聲功能（如果有），不能對接自行研發或者第三方的美顏或者變聲模塊；
- 3）通過 RTMP 協議推流和拉流，不能和基於 UDP 的私有協議互通連麥。如果要實現和基於 UDP 的私有協議互通連麥，就必須要增加接入層來轉換協議格式甚至媒體格式；
- 4）沒有實現後端媒體服務器，開發者必須要自行實現媒體服務器，或者把微信小程序接入到第三方的實時通信網絡。
瀏覽器通過 WebRTC 開放了瀏覽器的實時音視頻能力，而微信通過小程序開放了微信的實時音視頻能力，在兩個類操作系統的平臺上允許開發者去實現連麥直播和實時音視頻通話。然而，無論 WebRTC 還是小程序只是在終端上帶你入門，對開發者來說，要真正實現整套系統，還有很多工作需要做的。
如果要將微信小程序接入實時音視頻傳輸網絡，中間得有接入服務器，我們叫接入層。在接入層我們需要做協議的轉換，比如說，如果實時音視頻傳輸網絡是使用基於 UDP 的私有協議，那麼要把 RTMP 協議轉為基於 UDP 的私有協議。還有媒體格式的轉換，如果和實時傳輸網絡的媒體格式不一樣，還需要進行轉換。
6、視頻直播客戶端技術之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。
7、本文小結
連麥直播技術逐步在原生 APP, 瀏覽器 H5，瀏覽器 WebRTC，微信小程序上延伸，衍生出更加豐富的生態，提供更加便捷和良好的用戶體驗，對視頻直播平臺和用戶來說是好消息。然而，欲帶皇冠，必承其重。特別是在瀏覽器 WebRTC 和微信小程序上，開發者要充分理解這些類型終端的特點和侷限，才能更好地在上面利用連麥直播技術進行創新，服務用戶。
喜歡的朋友可以後臺私信【1】獲取學習視頻
附上一份音視頻學習課程大綱給大家
閱讀更多 開心玩技術 的文章
