目前，連麥直播的終端主要包括：原生APP、瀏覽器H5、瀏覽器WebRTC、微信小程序。瀏覽器上的應用包括H5和WebRTC，前者可以拉流觀看，后者可以實現推流和拉流。
1.連麥直播移動終端-Native APP 原生APP終端音視頻引擎的結構基本包括了音頻引擎、視頻引擎和網絡傳輸，合稱實時語音視頻終端引擎。這里還包含底層的音視頻采集和渲染，還有網絡的輸入輸出能力，這是操作系統開放的能力。
原生APP有個天然的好處，它是直接和操作系統打交道的，操作系統開放的資源和能力它都可以直接用，比如說音視頻的采集渲染，還有網絡的輸入輸出。套用一句時髦的廣告語：“沒有中間商賺差價”，直接和操作系統對接，可以獲得比較好的用戶體驗。在原生APP上實現連麥直播的優勢是，對上面所說的七個環節有較好的把控，可以獲得比較低的延遲，能自研實現語音前處理3A算法，包括回聲消除，還有對抖動緩沖策略和碼率自適應的策略都有比較好的把控。另外，可以自主選擇使用RTMP協議還是基于UDP的私有協議，對抗弱網環境更加有保障。
市面上比較流行的前處理技術，比如美顏、掛件、變聲等，原生APP都可以通過開放前處理接口讓開發者實現或者對接這些技術。為什么要強調這個呢？因為瀏覽器WebRTC和微信小程序都沒有開放前處理接口，開發者沒有辦法自行實現或者對接第三方的美顏或者掛件等技術模塊。在原生APP上，開發者可以得到全面的把控能力，讓用戶可以獲得更好的體驗。主流的視頻直播平臺都有自己的原生APP平臺，而瀏覽器和微信小程序相對來說是輔助的。原生APP的用戶體驗是最好的，而且對開發者來說也是最可控的。
在原生APP上實現連麥直播的劣勢是什么呢？開發門檻高，開發周期長、人力成本高。另外，從獲取用戶和傳播的角度來講，也沒有瀏覽器和微信小程序那么便利。
2.連麥直播移動終端-瀏覽器（H5） 瀏覽器H5就像一個硬幣有兩面，有好處也有劣勢，好處是開發成本低，容易傳播，劣勢是只能拉流，不能推流，不能做到多個用戶連麥直播。另外，在瀏覽器H5上延遲也是比較大。如果使用RTMP或者HTTP-FLV，延遲會在1秒到3秒之間，如果用HLS延遲會大于8秒甚至10秒，這么大的延遲就根本就不允許實現連麥直播。
使用這三種協議都是通過瀏覽器H5中的播放器來播放的。在多主播連麥互動的場景中，一個播放器里面只能播一路視頻流，三個主播就得三個播放器，因此看不到多個主播同框連麥互動的情形。如果要看到多個主播同框互動的畫面，就必須把多路流混合成一路流，在單個播放器里面播放。另外，瀏覽器H5的源代碼是開放的。如果在瀏覽器上把音視頻終端引擎實現了，相當于對外公開了所有核心的源代碼。因此，還沒有見過哪個廠商在瀏覽器H5上完整地把音視頻引擎真正做出來。即使你愿意做出來，瀏覽器也不會允許你這樣做，開發者和操作系統之間隔著瀏覽器，如果瀏覽器不把操作系統的核心能力開放給開發者，開發者就不能自主采集和渲染，不能掌控網絡輸入輸出，類似流控碼控等功能無法實現。
在瀏覽器H5中也可以通過websocket來傳輸，用jsmpeg來播放，視頻編解碼的格式用mpeg1。mpeg1是一個比較老的媒體格式，所有瀏覽器都支持。在瀏覽器中使用jsmpeg播放器播放mpeg1，所有瀏覽器也可以支持。這么做可以獲得比較低的延遲，但是還是無法推流，沒辦法實現連麥直播。
3.連麥直播移動終端-瀏覽器（WebRTC） 大家可能會覺得很遺憾，瀏覽器H5雖然很容易傳播，開發簡單但是體驗欠佳，不能連麥直播。那么在瀏覽器上能不能推流，能不能實現連麥直播呢？答案是可以的，那就要用到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的。 5）由于WebRTC不提供媒體服務器的實現，因此需要把瀏覽器WebRTC接入到媒體服務器后端，這個可以是自研的，也可以是第三方的服務。瀏覽器WebRTC和媒體服務器后端之間的協議和媒體格式是不一樣的，因此要做協議和格式的轉換。WebRTC用的基于UDP的SRTP，需要把它轉換成媒體服務器的基于UDP的私有協議。另外，媒體格式也需要轉換，因為WebRTC中語音視頻格式默認用的是VP8或者VP9。同時實時傳輸網絡中有關信令調度也需要做一些調整。瀏覽器WebRTC和媒體服務器后端之間的接入層也可以采用開源的WebRTC Gateway（比如說janus）來實現。
瀏覽器是類似操作系統的一種超級應用，它坐擁重要的流量入口，然而它也是開發者和操作系統之間的“中間商”。開發者通過WebRTC獲得瀏覽器開放的實時音視頻能力，然而也必須要承受WebRTC帶來的痛苦。
4.連麥直播移動終端-微信小程序 微信小程序是什么？是跑在微信上面的輕型應用。微信是什么？是類操作系統的超級應用。這些特征和瀏覽器以及H5是不是很接近？H5是瀏覽器支持的輕型應用，而瀏覽器是類操作系統的超級應用。瀏覽器背后是各大國際科技巨頭，不像微信這樣背后只有騰訊一個互聯網巨頭。因此，從這個角度來看，微信小程序、瀏覽器WebRTC和H5是有相通之處的。
微信小程序可以類比為瀏覽器H5那樣的客戶端和服務器的結構。其中HTML對應微信小程序的WXML，CSS對應小程序的WXSS，小程序的腳本語言和JS是一樣的，只是框架不一樣。微信小程序提供了兩個標簽，一個是<live-pusher>，一個是<live-player>。<live-pusher>就是推流，<live-player>就是拉流，可以實現單向直播或者連麥直播。小程序提供兩種模式：LIVE和RTC，LIVE支持單向直播，RTC支持低延遲的連麥直播。目前微信小程序推流采用RTMP協議，如果要和私有協議互通，需要進行協議轉換。
微信小程序開放了實時音視頻能力，對業界來說是重大利好。然而，根據上面的信息和邏輯，我們也看到采用微信小程序實現連麥互動直播的好處和不足。好處有三點： 1）開發成本低，開發周期短，基本和H5的開發難度差不多； 2）很容易傳播和獲客，充分利用好微信的優質流量； 3）可以推流和拉流，允許實現連麥直播和實時語音視頻通話。 另外，不足有四點： 1）你會受制于微信小程序的實時音視頻能力，比如說，如果它的回聲消除有某些問題，你只能等微信團隊按照自己的節奏來優化，而自己沒有任何辦法去優化。 2）小程序沒有開放前處理接口，只能使用小程序自帶的美顏或者變聲功能（如果有），不能對接自行研發或者第三方的美顏或者變聲模塊。 3）通過RTMP協議推流和拉流，不能和基于UDP的私有協議互通連麥。如果要實現和基于UDP的私有協議互通連麥，就必須要增加接入層來轉換協議格式甚至媒體格式。 4）沒有實現后端媒體服務器，開發者必須要自行實現媒體服務器，或者把微信小程序接入到第三方的實時通信網絡。
瀏覽器通過WebRTC開放了瀏覽器的實時音視頻能力，而微信通過小程序開放了微信的實時音視頻能力，在兩個類操作系統的平臺上允許開發者去實現連麥直播和實時音視頻通話。然而，無論WebRTC還是小程序只是在終端上帶你入門，對開發者來說，要真正實現整套系統，還有很多工作需要做的。如果要將微信小程序接入實時音視頻傳輸網絡，中間得有接入服務器，我們叫接入層。在接入層我們需要做協議的轉換，比如說，如果實時音視頻傳輸網絡是使用基于UDP的私有協議，那么要把RTMP協議轉為基于UDP的私有協議。還有媒體格式的轉換，如果和實時傳輸網絡的媒體格式不一樣，還需要進行轉換。
5.連麥直播移動終端-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和微信小程序上，開發者要充分理解這些類型終端的特點和局限，才能更好地在上面利用連麥直播技術進行創新，服務用戶。
引用：冼牛的《直播終端技術比較：Native vs H5 vs WebRTC vs 小程序》 超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的直播终端技术比较的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。