目前，連麥直播的終端主要包括：原生APP、瀏覽器H5、瀏覽器WebRTC、微信小程序。瀏覽器上的應(yīng)用包括H5和WebRTC，前者可以拉流觀看，后者可以實現(xiàn)推流和拉流。
1.連麥直播移動終端-Native APP 原生APP終端音視頻引擎的結(jié)構(gòu)基本包括了音頻引擎、視頻引擎和網(wǎng)絡(luò)傳輸，合稱實時語音視頻終端引擎。這里還包含底層的音視頻采集和渲染，還有網(wǎng)絡(luò)的輸入輸出能力，這是操作系統(tǒng)開放的能力。
原生APP有個天然的好處，它是直接和操作系統(tǒng)打交道的，操作系統(tǒng)開放的資源和能力它都可以直接用，比如說音視頻的采集渲染，還有網(wǎng)絡(luò)的輸入輸出。套用一句時髦的廣告語：“沒有中間商賺差價”，直接和操作系統(tǒng)對接，可以獲得比較好的用戶體驗。在原生APP上實現(xiàn)連麥直播的優(yōu)勢是，對上面所說的七個環(huán)節(jié)有較好的把控，可以獲得比較低的延遲，能自研實現(xiàn)語音前處理3A算法，包括回聲消除，還有對抖動緩沖策略和碼率自適應(yīng)的策略都有比較好的把控。另外，可以自主選擇使用RTMP協(xié)議還是基于UDP的私有協(xié)議，對抗弱網(wǎng)環(huán)境更加有保障。
市面上比較流行的前處理技術(shù)，比如美顏、掛件、變聲等，原生APP都可以通過開放前處理接口讓開發(fā)者實現(xiàn)或者對接這些技術(shù)。為什么要強調(diào)這個呢？因為瀏覽器WebRTC和微信小程序都沒有開放前處理接口，開發(fā)者沒有辦法自行實現(xiàn)或者對接第三方的美顏或者掛件等技術(shù)模塊。在原生APP上，開發(fā)者可以得到全面的把控能力，讓用戶可以獲得更好的體驗。主流的視頻直播平臺都有自己的原生APP平臺，而瀏覽器和微信小程序相對來說是輔助的。原生APP的用戶體驗是最好的，而且對開發(fā)者來說也是最可控的。
在原生APP上實現(xiàn)連麥直播的劣勢是什么呢？開發(fā)門檻高，開發(fā)周期長、人力成本高。另外，從獲取用戶和傳播的角度來講，也沒有瀏覽器和微信小程序那么便利。
2.連麥直播移動終端-瀏覽器（H5） 瀏覽器H5就像一個硬幣有兩面，有好處也有劣勢，好處是開發(fā)成本低，容易傳播，劣勢是只能拉流，不能推流，不能做到多個用戶連麥直播。另外，在瀏覽器H5上延遲也是比較大。如果使用RTMP或者HTTP-FLV，延遲會在1秒到3秒之間，如果用HLS延遲會大于8秒甚至10秒，這么大的延遲就根本就不允許實現(xiàn)連麥直播。
使用這三種協(xié)議都是通過瀏覽器H5中的播放器來播放的。在多主播連麥互動的場景中，一個播放器里面只能播一路視頻流，三個主播就得三個播放器，因此看不到多個主播同框連麥互動的情形。如果要看到多個主播同框互動的畫面，就必須把多路流混合成一路流，在單個播放器里面播放。另外，瀏覽器H5的源代碼是開放的。如果在瀏覽器上把音視頻終端引擎實現(xiàn)了，相當于對外公開了所有核心的源代碼。因此，還沒有見過哪個廠商在瀏覽器H5上完整地把音視頻引擎真正做出來。即使你愿意做出來，瀏覽器也不會允許你這樣做，開發(fā)者和操作系統(tǒng)之間隔著瀏覽器，如果瀏覽器不把操作系統(tǒng)的核心能力開放給開發(fā)者，開發(fā)者就不能自主采集和渲染，不能掌控網(wǎng)絡(luò)輸入輸出，類似流控碼控等功能無法實現(xiàn)。
在瀏覽器H5中也可以通過websocket來傳輸，用jsmpeg來播放，視頻編解碼的格式用mpeg1。mpeg1是一個比較老的媒體格式，所有瀏覽器都支持。在瀏覽器中使用jsmpeg播放器播放mpeg1，所有瀏覽器也可以支持。這么做可以獲得比較低的延遲，但是還是無法推流，沒辦法實現(xiàn)連麥直播。
3.連麥直播移動終端-瀏覽器（WebRTC） 大家可能會覺得很遺憾，瀏覽器H5雖然很容易傳播，開發(fā)簡單但是體驗欠佳，不能連麥直播。那么在瀏覽器上能不能推流，能不能實現(xiàn)連麥直播呢？答案是可以的，那就要用到WebRTC。這里說的WebRTC是指已經(jīng)被內(nèi)嵌到瀏覽器里面，被瀏覽器支持的WebRTC，而不是WebRTC的源代碼。部分主流瀏覽器內(nèi)嵌了WebRTC，對開發(fā)者開放了瀏覽器的實時音視頻能力。
WebRTC包括了音頻引擎，視頻引擎、傳輸引擎等，最底層的虛線框表示可以重載，也就是說瀏覽器把最底層的音視頻渲染和網(wǎng)絡(luò)傳輸?shù)牡讓幽芰﹂_放給開發(fā)者，開發(fā)者可以根據(jù)自己的需求選擇是否進行重載。音頻引擎中，包括了兩個編解碼器：iSAC和iLBC，前者針對寬帶和超寬帶的音頻編解碼，后者針對窄帶音頻編解碼。音頻引擎還包括了音頻抖動緩沖，回聲消除和噪音抑制模塊等。抖動緩沖中的NetEQ算法可以說是WebRTC里面的精華之一。視頻引擎中，包括了VP8和VP9的視頻編解碼器，甚至是即將到來的AV1。視頻引擎還包括視頻抖動緩沖和圖像質(zhì)量增強等模塊。傳輸引擎，WebRTC使用的是SRTP（Secured Realtime Transport Protocol）安全實時傳輸協(xié)議。
最后，WebRTC采取P2P的通信方式，沒有媒體服務(wù)器等后端的實現(xiàn)。以上是WebRTC的簡單介紹。瀏覽器WebRTC一般的優(yōu)勢和劣勢這里就不再重復(fù)，請大家自行百度，這里只說重點。瀏覽器WebRTC的好處就是實現(xiàn)了相對完整的音視頻終端引擎，允許在瀏覽器上推流，可以實現(xiàn)連麥直播。然而，瀏覽器WebRTC也有不足： 1）沒有開放前處理接口，美顏和掛件這些模塊沒辦法接入第三方的或者自研方案。 2）媒體服務(wù)器后端沒有實現(xiàn)，開發(fā)者要實現(xiàn)媒體服務(wù)器，然后通過開源WebRTC網(wǎng)關(guān)（比如說janus）接入。 3）編解碼器、抖動緩沖和語音前處理3A等能力只能依靠WebRTC，不能自行定制化。 4）部分主流瀏覽器是不支持WebRTC的，特別是蘋果的瀏覽器。雖然說去年蘋果宣布支持WebRTC,但是目前iOS Safari最新版本對WebRTC的支持并不好，iOS Safari的主流版本并不支持WebRTC，在iOS上面微信瀏覽器也是不支持WebRTC的。 5）由于WebRTC不提供媒體服務(wù)器的實現(xiàn)，因此需要把瀏覽器WebRTC接入到媒體服務(wù)器后端，這個可以是自研的，也可以是第三方的服務(wù)。瀏覽器WebRTC和媒體服務(wù)器后端之間的協(xié)議和媒體格式是不一樣的，因此要做協(xié)議和格式的轉(zhuǎn)換。WebRTC用的基于UDP的SRTP，需要把它轉(zhuǎn)換成媒體服務(wù)器的基于UDP的私有協(xié)議。另外，媒體格式也需要轉(zhuǎn)換，因為WebRTC中語音視頻格式默認用的是VP8或者VP9。同時實時傳輸網(wǎng)絡(luò)中有關(guān)信令調(diào)度也需要做一些調(diào)整。瀏覽器WebRTC和媒體服務(wù)器后端之間的接入層也可以采用開源的WebRTC Gateway（比如說janus）來實現(xiàn)。
瀏覽器是類似操作系統(tǒng)的一種超級應(yīng)用，它坐擁重要的流量入口，然而它也是開發(fā)者和操作系統(tǒng)之間的“中間商”。開發(fā)者通過WebRTC獲得瀏覽器開放的實時音視頻能力，然而也必須要承受WebRTC帶來的痛苦。
4.連麥直播移動終端-微信小程序 微信小程序是什么？是跑在微信上面的輕型應(yīng)用。微信是什么？是類操作系統(tǒng)的超級應(yīng)用。這些特征和瀏覽器以及H5是不是很接近？H5是瀏覽器支持的輕型應(yīng)用，而瀏覽器是類操作系統(tǒng)的超級應(yīng)用。瀏覽器背后是各大國際科技巨頭，不像微信這樣背后只有騰訊一個互聯(lián)網(wǎng)巨頭。因此，從這個角度來看，微信小程序、瀏覽器WebRTC和H5是有相通之處的。
微信小程序可以類比為瀏覽器H5那樣的客戶端和服務(wù)器的結(jié)構(gòu)。其中HTML對應(yīng)微信小程序的WXML，CSS對應(yīng)小程序的WXSS，小程序的腳本語言和JS是一樣的，只是框架不一樣。微信小程序提供了兩個標簽，一個是<live-pusher>，一個是<live-player>。<live-pusher>就是推流，<live-player>就是拉流，可以實現(xiàn)單向直播或者連麥直播。小程序提供兩種模式：LIVE和RTC，LIVE支持單向直播，RTC支持低延遲的連麥直播。目前微信小程序推流采用RTMP協(xié)議，如果要和私有協(xié)議互通，需要進行協(xié)議轉(zhuǎn)換。
微信小程序開放了實時音視頻能力，對業(yè)界來說是重大利好。然而，根據(jù)上面的信息和邏輯，我們也看到采用微信小程序?qū)崿F(xiàn)連麥互動直播的好處和不足。好處有三點： 1）開發(fā)成本低，開發(fā)周期短，基本和H5的開發(fā)難度差不多； 2）很容易傳播和獲客，充分利用好微信的優(yōu)質(zhì)流量； 3）可以推流和拉流，允許實現(xiàn)連麥直播和實時語音視頻通話。 另外，不足有四點： 1）你會受制于微信小程序的實時音視頻能力，比如說，如果它的回聲消除有某些問題，你只能等微信團隊按照自己的節(jié)奏來優(yōu)化，而自己沒有任何辦法去優(yōu)化。 2）小程序沒有開放前處理接口，只能使用小程序自帶的美顏或者變聲功能（如果有），不能對接自行研發(fā)或者第三方的美顏或者變聲模塊。 3）通過RTMP協(xié)議推流和拉流，不能和基于UDP的私有協(xié)議互通連麥。如果要實現(xiàn)和基于UDP的私有協(xié)議互通連麥，就必須要增加接入層來轉(zhuǎn)換協(xié)議格式甚至媒體格式。 4）沒有實現(xiàn)后端媒體服務(wù)器，開發(fā)者必須要自行實現(xiàn)媒體服務(wù)器，或者把微信小程序接入到第三方的實時通信網(wǎng)絡(luò)。
瀏覽器通過WebRTC開放了瀏覽器的實時音視頻能力，而微信通過小程序開放了微信的實時音視頻能力，在兩個類操作系統(tǒng)的平臺上允許開發(fā)者去實現(xiàn)連麥直播和實時音視頻通話。然而，無論WebRTC還是小程序只是在終端上帶你入門，對開發(fā)者來說，要真正實現(xiàn)整套系統(tǒng)，還有很多工作需要做的。如果要將微信小程序接入實時音視頻傳輸網(wǎng)絡(luò)，中間得有接入服務(wù)器，我們叫接入層。在接入層我們需要做協(xié)議的轉(zhuǎn)換，比如說，如果實時音視頻傳輸網(wǎng)絡(luò)是使用基于UDP的私有協(xié)議，那么要把RTMP協(xié)議轉(zhuǎn)為基于UDP的私有協(xié)議。還有媒體格式的轉(zhuǎn)換，如果和實時傳輸網(wǎng)絡(luò)的媒體格式不一樣，還需要進行轉(zhuǎn)換。
5.連麥直播移動終端-WebRTC通過WebView接入小程序 還有別的方法在小程序上做連麥直播互動嗎？必須要使用微信小程序開放的語音視頻能力嗎？也不一定。下圖展示了我在市面上看過的一個技術(shù)方案，它繞過了微信小程序?qū)崟r語音視頻能力，通過微信小程序WebView組件實現(xiàn)了連麥直播的方案。這里和大家分享一下。
這個方案的基本思路是利用WebView的瀏覽器特點，在WebView內(nèi)使用WebRTC的Web API，從而在小程序上獲得實時音視頻能力。最底層是微信小程序的基礎(chǔ)能力。上一層是WebView，微信小程序的WebView類似瀏覽器，那么就可能會支持WebRTC。然而必須要注意到，微信小程序的WebView在安卓平臺上支持WebRTC，但在iOS平臺上面不支持WebRTC。雖然這個方案理論上也能在微信小程序上實現(xiàn)連麥直播，但是它有以下的局限性： 1）在iOS平臺上，微信小程序不支持這個方案，上面已經(jīng)說過。 2）小程序WebView不是完整的瀏覽器，要比普通瀏覽器表現(xiàn)差而且有很多的限制。 3）開發(fā)者和操作系統(tǒng)之間隔了好幾層：微信底層，小程序，WebView，WebRTC，然后才是開發(fā)者的小程序應(yīng)用。每一層的抽象都會帶來性能上的消耗，都會影響到最終的體驗。 這個方案本質(zhì)上還是一個基于WebRTC的解決方案，沒有用到微信小程序開放的實時音視頻能力，而是快速地借助WebView組件，劍走偏鋒，十分討巧地在微信小程序里使用了WebRTC。
連麥直播技術(shù)逐步在原生APP, 瀏覽器H5，瀏覽器WebRTC，微信小程序上延伸，衍生出更加豐富的生態(tài)，提供更加便捷和良好的用戶體驗，對視頻直播平臺和用戶來說是好消息。然而，欲帶皇冠，必承其重。特別是在瀏覽器WebRTC和微信小程序上，開發(fā)者要充分理解這些類型終端的特點和局限，才能更好地在上面利用連麥直播技術(shù)進行創(chuàng)新，服務(wù)用戶。
引用：冼牛的《直播終端技術(shù)比較：Native vs H5 vs WebRTC vs 小程序》 超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術(shù)人生

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。