實時視頻直播客戶端技術盤點：Native、HTML五、WebRTC、微信小程序
一、前言
2017 年 12 月，微信小程序向開發者開放了實時音視頻能力，給業內帶來廣闊的想象空間。連麥互動視頻直播技術在 2016 年直播風口中成爲視頻直播的標配，然而只有在原生的 APP 上才能保障良好的用戶體驗。php
那時候，在微信小程序中沒法進行實時音視頻互動。微信小程序在去年 12 月宣佈開放實時音視頻能力，再加上去年 6 月蘋果宣佈即將支持 WebRTC，業內一會兒千樹萬樹梨花開，前途一片光明。html
連麥互動直播技術和微信小程序以及 WebRTC 能產生怎麼樣的化學做用？開發者在微信小程序或者瀏覽器 WebRTC 上實現連麥互動直播技術的時候，須要知道什麼和考慮什麼？web
連麥視頻直播的客戶端主要包括：原生 APP、瀏覽器 H五、瀏覽器 WebRTC、微信小程序。瀏覽器上的應用包括 H5 和 WebRTC，前者能夠拉流觀看，後者能夠實現推流和拉流。算法
學習交流：小程序
- 即時通信開發交流3羣：185926912[推薦]後端
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》微信小程序
（本文同步發佈於：http://www.52im.net/thread-1564-1-1.html）瀏覽器
二、本文做者
冼牛：即構科技資深語音視頻專家，北京郵電大學計算機碩士，香港大學工商管理碩士，多年從事語音視頻雲服務技術研究，專一互動直播技術、語音視頻社交和實時遊戲語音。安全
做者的文章《近期大熱的實時直播答題系統的實現思路與技術難點分享》、《IM實時音視頻聊天時的回聲消除技術詳解》也已整理併發佈於即時通信網，有興趣的能夠看看。服務器
三、直播技術文章參考
《七牛雲技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
《實現延遲低於500毫秒的1080P實時音視頻直播的實踐分享》
《技術揭祕：支持百萬級粉絲互動的Facebook實時視頻直播》
《理論聯繫實際：實現一個簡單地基於HTML5的實時視頻直播》
《首次披露：快手是如何作到百萬觀衆同場看直播仍能秒開且不卡頓的？》
>> 更多同類文章 ……
四、視頻直播客戶端技術之Native APP
原生 APP 終端音視頻引擎的結構框圖以下，基本包括了音頻引擎、視頻引擎和網絡傳輸，合稱實時語音視頻終端引擎。這裏還包含底層的音視頻採集和渲染，還有網絡的輸入輸出能力，這是操做系統開放的能力。
原生 APP 有個自然的好處，它是直接和操做系統打交道的，操做系統開放的資源和能力它均可以直接用，好比說音視頻的採集渲染，還有網絡的輸入輸出。套用一句時髦的廣告語：「沒有中間商賺差價」，直接和操做系統對接，能夠得到比較好的用戶體驗。
在原生 APP 上實現連麥直播的優點是，對上面所說的七個環節有較好的把控，能夠得到比較低的延遲，能自研實現語音前處理 3A 算法，包括回聲消除，還有對抖動緩衝策略和碼率自適應的策略都有比較好的把控。另外，能夠自主選擇使用 RTMP 協議仍是基於 UDP 的私有協議，對抗弱網環境更加有保障。
市面上比較流行的前處理技術，好比美顏、掛件、變聲等，原生 APP 均可以經過開放前處理接口讓開發者實現或者對接這些技術。爲何要強調這個呢？由於瀏覽器 WebRTC 和微信小程序都沒有開放前處理接口，開發者沒有辦法自行實現或者對接第三方的美顏或者掛件等技術模塊。
在原生 APP 上，開發者能夠獲得全面的把控能力，讓用戶能夠得到更好的體驗。主流的視頻直播平臺都有本身的原生 APP 平臺，而瀏覽器和微信小程序相對來講是輔助的。原生 APP 的用戶體驗是最好的，並且對開發者來講也是最可控的。
在原生 APP 上實現連麥直播的劣勢是什麼呢？開發門檻高，開發週期長、人力成本高。另外，從獲取用戶和傳播的角度來說，也沒有瀏覽器和微信小程序那麼便利。
五、視頻直播客戶端技術之瀏覽器（HTML5）
瀏覽器 H5 就像一個硬幣有兩面，有好處也有劣勢，好處是開發成本低，容易傳播，劣勢是隻能拉流，不能推流，不能作到多個用戶連麥直播。另外，在瀏覽器 H5 上延遲也是比較大。若是使用 RTMP 或者 HTTP-FLV，延遲會在 1 秒到 3 秒之間，若是用 HLS 延遲會大於 8 秒甚至 10 秒，這麼大的延遲就根本就不容許實現連麥直播。
使用這三種協議都是經過瀏覽器 H5 中的播放器來播放的。在多主播連麥互動的場景中，一個播放器裏面只能播一路視頻流，三個主播就得三個播放器，所以看不到多個主播同框連麥互動的情形。若是要看到多個主播同框互動的畫面，就必須把多路流混合成一路流，在單個播放器裏面播放。
另外，瀏覽器 H5 的源代碼是開放的。若是在瀏覽器上把音視頻終端引擎實現了，至關於對外公開了全部核心的源代碼。所以，尚未見過哪一個廠商在瀏覽器 H5 上完整地把音視頻引擎真正作出來。即便你願意作出來，瀏覽器也不會容許你這樣作，開發者和操做系統之間隔着瀏覽器，若是瀏覽器不把操做系統的核心能力開放給開發者，開發者就不能自主採集和渲染，不能掌控網絡輸入輸出，相似流控碼控等功能沒法實現。
在瀏覽器 H5 中也能夠經過 websocket 來傳輸，用 jsmpeg 來播放，視頻編解碼的格式用 mpeg1。
mpeg1 是一個比較老的媒體格式，全部瀏覽器都支持。在瀏覽器中使用 jsmpeg 播放器播放 mpeg1，全部瀏覽器也能夠支持。這麼作能夠得到比較低的延遲，可是仍是沒法推流，沒辦法實現連麥直播。
六、視頻直播客戶端技術之瀏覽器（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 帶來的痛苦。
七、視頻直播客戶端技術之微信小程序
微信小程序是什麼？是跑在微信上面的輕型應用。微信是什麼？是類操做系統的超級應用。這些特徵和瀏覽器以及 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 的私有協議。還有媒體格式的轉換，若是和實時傳輸網絡的媒體格式不同，還須要進行轉換。
八、視頻直播客戶端技術之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。
九、本文小結
連麥直播技術逐步在原生 APP, 瀏覽器 H5，瀏覽器 WebRTC，微信小程序上延伸，衍生出更加豐富的生態，提供更加便捷和良好的用戶體驗，對視頻直播平臺和用戶來講是好消息。然而，欲帶皇冠，必承其重。特別是在瀏覽器 WebRTC 和微信小程序上，開發者要充分理解這些類型終端的特色和侷限，才能更好地在上面利用連麥直播技術進行創新，服務用戶。
附錄：更多實時音視頻技術文章彙總
[1] 開源實時音視頻技術WebRTC的文章：
《訪談WebRTC標準之父：WebRTC的過去、如今和將來》
《良心分享：WebRTC 零基礎開發者教程（中文）[附件下載]》
《新手入門：到底什麼是WebRTC服務器，以及它是如何聯接通話的？》
《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》
《基於開源WebRTC開發實時音視頻靠譜嗎？第3方SDK有哪些？》
《開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用》
《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》
《網頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》
>> 更多同類文章 ……
[2] 實時音視頻開發的其它精華資料：
《即時通信音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通信音視頻開發（九）：實時語音通信的迴音及迴音消除概述》
《即時通信音視頻開發（十）：實時語音通信的迴音消除技術詳解》
《即時通信音視頻開發（十一）：實時語音通信丟包補償技術詳解》
《即時通信音視頻開發（十三）：實時視頻編碼H.264的特色與優點》
《即時通信音視頻開發（十五）：聊聊P2P與實時音視頻的應用狀況》
《即時通信音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
《即時通信音視頻開發（十七）：視頻編碼H.26四、VP8的前世此生》
《學習RFC3550：RTP/RTCP實時傳輸協議基礎知識》
《基於RTMP數據傳輸協議的實時流媒體技術研究（論文全文）》
《還在靠「喂喂喂」測試實時語音通話質量？本文教你科學的評測方法！》
《實現延遲低於500毫秒的1080P實時音視頻直播的實踐分享》
《技術揭祕：支持百萬級粉絲互動的Facebook實時視頻直播》
《理論聯繫實際：實現一個簡單地基於HTML5的實時視頻直播》
《首次披露：快手是如何作到百萬觀衆同場看直播仍能秒開且不卡頓的？》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《七牛雲技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
《實時視頻直播客戶端技術盤點：Native、HTML五、WebRTC、微信小程序》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-1564-1-1.html）
- 1. 實時視頻直播客戶端技術盤點：Native、HTML五、WebRTC、微信小程序
- 2. 實時視頻直播客戶端技術盤點：Native、HTML5、WebRTC、微信小程序
- 3. 微信小程序視頻直播開發實現流程
- 4. WebRTC視頻Android客戶端
- 5. WebRTC視頻直播
- 6. 直播終端技術比較：Native vs H5 vs WebRTC vs 小程序
- 7. 微信小程序直播，騰訊雲直播+微信小程序實現實時直播
- 8. 微信如何實現小程序實時視頻直播點播？有哪些難點？
- 9. 微信小程序+騰訊雲直播的實時音視頻實戰筆記
- 10. 基於微信小程序做直播的截圖（微信小程序發起視頻直播）
- 更多相關文章...
- • XSLT - 在客戶端 - XSLT 教程
- • XML 相關技術 - XML 教程
- • Docker容器實戰(一) - 封神Server端技術
- • Git五分鐘教程
-
每一个你不满意的现在，都有一个你没有努力的曾经。