2017年12月，微信小程序向開(kāi)發(fā)者開(kāi)放了實(shí)時(shí)音視頻能力，給業(yè)內(nèi)帶來(lái)廣闊的想象空間。連麥互動(dòng)直播技術(shù)在2016年直播風(fēng)口中成為視頻直播的標(biāo)配，然而只有在原生的APP上才能保障良好的用戶體驗(yàn)。那時(shí)候，在微信小程序中無(wú)法進(jìn)行實(shí)時(shí)音視頻互動(dòng)。微信小程序在去年12月宣布開(kāi)放實(shí)時(shí)音視頻能力，再加上去年6月蘋(píng)果宣布即將支持WebRTC，業(yè)內(nèi)一下子千樹(shù)萬(wàn)樹(shù)梨花開(kāi)，前途一片光明。連麥互動(dòng)直播技術(shù)和微信小程序以及WebRTC能產(chǎn)生怎么樣的化學(xué)作用？開(kāi)發(fā)者在微信小程序或者瀏覽器WebRTC上實(shí)現(xiàn)連麥互動(dòng)直播技術(shù)的時(shí)候，需要知道什么和考慮什么？

2018年3月17日星期六，在由即構(gòu)科技主辦的技術(shù)**Zego Meetup北京站中，即構(gòu)科技資深技術(shù)專家、架構(gòu)師冼牛向參會(huì)者分享了即構(gòu)團(tuán)隊(duì)在連麥直播技術(shù)和微信小程序結(jié)合的思考和實(shí)踐。

當(dāng)日，北京一早就下起來(lái)漫天紛飛的鵝毛大雪，卻擋不住參會(huì)者學(xué)習(xí)和交流的熱情，活動(dòng)現(xiàn)場(chǎng)擠得滿滿一堂。瑞雪兆豐年，2018年對(duì)創(chuàng)業(yè)者來(lái)說(shuō)，將會(huì)是一個(gè)豐收的好年頭。

連麥直播的技術(shù)難點(diǎn)和解決思路

我們先回顧一下連麥互動(dòng)直播技術(shù)，這個(gè)要從應(yīng)用場(chǎng)景說(shuō)起。

第一類應(yīng)用場(chǎng)景就是最常見(jiàn)的視頻直播中的多主播連麥場(chǎng)景。從2016年開(kāi)始，從單向直播發(fā)展到兩人連麥、三人連麥，逐漸到多人連麥。兩人連麥?zhǔn)侵敢曨l直播場(chǎng)景里面的兩個(gè)主播進(jìn)行連麥互動(dòng)，具體的節(jié)目形式有談話、脫口秀、K歌或者合唱。在視頻直播中，兩個(gè)到三個(gè)主播連麥?zhǔn)呛艹Ｒ?jiàn)的形式，有時(shí)候會(huì)允許觀眾進(jìn)行連麥。多人連麥的應(yīng)用場(chǎng)景包括狼人殺、多人視頻群聊和組團(tuán)直播答題等，在移動(dòng)端同一個(gè)房間連麥互動(dòng)的用戶往往達(dá)到十幾二十個(gè)。

第二類應(yīng)用場(chǎng)景是線上抓娃娃，或者叫直播抓娃娃，也是視頻直播的一個(gè)產(chǎn)品形態(tài)，視頻直播和物聯(lián)網(wǎng)的結(jié)合。線上抓娃娃技術(shù)除了包含視頻直播以外，還加上了信令的控制，可以實(shí)現(xiàn)遠(yuǎn)程看著娃娃機(jī)并且控制抓娃娃的天車，同時(shí)主播和觀眾之間可以通過(guò)文字互動(dòng)，還有語(yǔ)音視頻連麥互動(dòng)。這是2017年年末的一個(gè)風(fēng)口，把連麥互動(dòng)直播技術(shù)帶到視頻直播和物聯(lián)網(wǎng)結(jié)合的場(chǎng)景中，相信今年會(huì)有更多視頻直播和物聯(lián)網(wǎng)結(jié)合的應(yīng)用場(chǎng)景涌現(xiàn)。

第三類應(yīng)用場(chǎng)景是直播答題，這是2018年1月份涌現(xiàn)的一股熱潮，是答題節(jié)目類在視頻直播場(chǎng)景中的探索。在低延遲、流暢和高清的基礎(chǔ)需求上，這個(gè)應(yīng)用場(chǎng)景還要求答題題目和視頻畫(huà)面必須要同步。另外，花椒直播的直播答題房間內(nèi)的用戶數(shù)量一度超過(guò)五百萬(wàn)，因此直播答題技術(shù)必須要支持百萬(wàn)級(jí)別的并發(fā)。雖然春節(jié)期間因?yàn)楸O(jiān)管的原因增加了準(zhǔn)入門檻，但是我相信后面還會(huì)有別的新的玩法出現(xiàn)。行業(yè)里討論的一些新玩法在這里也和大家分享一下：主持人可以邀請(qǐng)嘉賓連麥進(jìn)行答題，參加直播答題的用戶可以建子房間組團(tuán)答題。這些創(chuàng)新的玩法在技術(shù)上都是可以做到的，本質(zhì)上這就是直播答題技術(shù)和連麥互動(dòng)直播技術(shù)的結(jié)合。

這三個(gè)應(yīng)用場(chǎng)景對(duì)視頻直播技術(shù)有什么要求呢？第一個(gè)是延遲要足夠低，如果單向延遲不能低于500毫秒的話，視頻通話的互動(dòng)體驗(yàn)就無(wú)法保障。第二個(gè)是回聲消除，因?yàn)橛脩鬉和用戶B之間進(jìn)行視頻通話時(shí)，用戶A的聲音在傳到用戶B端時(shí)被采集并反饋回來(lái)，用戶A在一定的延遲后會(huì)聽(tīng)到回聲，這個(gè)對(duì)通話的體驗(yàn)是十分有影響的，因此必須做回聲消除。第三個(gè)是要流暢不卡頓，為什么流暢性很必要呢？因?yàn)橛谐脱舆t的要求，流暢和延遲本身就是一對(duì)相互矛盾的技術(shù)要求，如果延遲足夠低的話就要求抖動(dòng)緩沖區(qū)足夠的小，這樣網(wǎng)絡(luò)抖動(dòng)就很容易顯現(xiàn)出來(lái)，導(dǎo)致出現(xiàn)畫(huà)面過(guò)快、過(guò)慢，或者卡頓的情況。

下面我們來(lái)具體看看怎么解決這三個(gè)視頻直播的核心技術(shù)要求。

一、超低延遲架構(gòu)

市面上做連麥直播解決方案的系統(tǒng)架構(gòu)普遍大概這個(gè)樣子，左邊是低延遲網(wǎng)絡(luò)，為需要低延遲的用戶提供連麥互動(dòng)直播服務(wù)，成本較高。右邊是內(nèi)容分發(fā)網(wǎng)絡(luò)，為圍觀用戶提供視頻直播服務(wù)，雖然延遲稍微高一點(diǎn)，但是成本比較低而且支持更高的并發(fā)。中間通過(guò)一個(gè)旁路服務(wù)連接。旁路服務(wù)器從低延遲的實(shí)時(shí)網(wǎng)絡(luò)中把音頻流和視頻流拉出來(lái)，有選擇地進(jìn)行混流、格式轉(zhuǎn)換或者協(xié)議轉(zhuǎn)換等處理，然后轉(zhuǎn)推到內(nèi)容分發(fā)網(wǎng)絡(luò)，然后通過(guò)內(nèi)容分發(fā)網(wǎng)絡(luò)分發(fā)給圍觀用戶。

要構(gòu)建超低延遲的實(shí)時(shí)系統(tǒng)架構(gòu)，需要考慮以下幾個(gè)要點(diǎn)：

1. 負(fù)載均衡 - 超低延遲架構(gòu)必須要做到負(fù)載均衡，也就是說(shuō)任何一個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)都必須均衡地負(fù)載用戶。如果某一個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)的用戶訪問(wèn)量超過(guò)了它能夠承載的上限，容易出現(xiàn)大量丟包的情況，這樣會(huì)觸發(fā)網(wǎng)絡(luò)擁塞，從而引起更多的丟包，導(dǎo)致用戶體驗(yàn)不好。
2. 就近接入 - 網(wǎng)絡(luò)上的“近”和我們理解的直線上的近是不一樣的。這個(gè)可以類比為交通網(wǎng)絡(luò)，假設(shè)開(kāi)車的時(shí)候看到另外一個(gè)點(diǎn)離你近，但實(shí)際上可能不一定近，要考慮一下兩點(diǎn)：第一點(diǎn)是連通性，盡管A、B兩點(diǎn)看起來(lái)很近，但是從A點(diǎn)到B點(diǎn)是沒(méi)有直通的道路，這就相當(dāng)于網(wǎng)絡(luò)的不連通。第二點(diǎn)是擁堵?tīng)顩r，如果道路很短，但出現(xiàn)擁堵，那也不見(jiàn)得近。比如說(shuō)，迪拜用戶和北京的用戶連麥，看起來(lái)直接從迪拜推流到北京是最近的，可是實(shí)際上這個(gè)直接的路徑可能是不通的，那么需要繞道香港進(jìn)行中繼續(xù)傳，走一個(gè)彎路，在網(wǎng)絡(luò)上的距離可能會(huì)“更近”。
3. 質(zhì)量評(píng)估 - 質(zhì)量評(píng)估中的靜態(tài)方法是事后評(píng)估，具體是回顧過(guò)去的數(shù)據(jù)，分析某一個(gè)地區(qū)的用戶在各個(gè)時(shí)間點(diǎn)推流到某個(gè)地區(qū)的數(shù)據(jù)，總結(jié)出哪個(gè)時(shí)間點(diǎn)走哪個(gè)路徑比較好的方案，然后人為地將相關(guān)數(shù)據(jù)配置到實(shí)時(shí)傳輸?shù)骄W(wǎng)絡(luò)，可以提高傳輸質(zhì)量。
4. 動(dòng)態(tài)路由 - 質(zhì)量評(píng)估的另外一個(gè)方法是動(dòng)態(tài)評(píng)估，也就是根據(jù)歷史數(shù)據(jù)動(dòng)態(tài)地進(jìn)行質(zhì)量評(píng)估。傳輸網(wǎng)絡(luò)在運(yùn)作一段時(shí)間后會(huì)積累很多用戶數(shù)據(jù)，比如說(shuō)深圳的用戶在早上、中午、晚上不同的網(wǎng)絡(luò)情況下推流到北京的最優(yōu)路徑，這些數(shù)據(jù)積累下來(lái)，可以為動(dòng)態(tài)地制定路由策略作依據(jù)，這就是動(dòng)態(tài)路由。
5. 算法流控 - 在實(shí)時(shí)傳輸網(wǎng)絡(luò)中，我們要選出一條最優(yōu)的路徑進(jìn)行推流。如果這個(gè)最優(yōu)路徑還達(dá)不到超低延遲的要求，這個(gè)時(shí)候我們要在算法上做一些補(bǔ)償，例如信道的保護(hù)，通過(guò)增加冗余，保護(hù)信道里的數(shù)據(jù)。還有在推流時(shí)做一些流控策略，上行網(wǎng)絡(luò)中，如果檢測(cè)到網(wǎng)絡(luò)抖動(dòng)，或者說(shuō)弱網(wǎng)情況的話，就降低碼率，網(wǎng)絡(luò)情況變好的話，就把碼率提高。下行網(wǎng)絡(luò)中，可以通過(guò)分層編碼為不同網(wǎng)絡(luò)環(huán)境的用戶選擇不同碼率的視頻流。

二、回聲消除

什么是回聲？舉個(gè)例子，假如你是近端的用戶，接收到遠(yuǎn)端用戶的聲音，這個(gè)聲音通過(guò)喇叭播放出來(lái)，會(huì)在房間里面發(fā)生傳播，被天花板、地面和窗戶等反射后，連同你的聲音一起被麥克風(fēng)采集進(jìn)去，再傳到遠(yuǎn)端。遠(yuǎn)端用戶在一兩秒的延遲后，會(huì)再次聽(tīng)到自己的聲音，這對(duì)遠(yuǎn)端用戶來(lái)說(shuō)就是回聲。為了保障用戶體驗(yàn)，必須要做回聲消除。對(duì)于音視頻引擎來(lái)講，麥克風(fēng)采集進(jìn)來(lái)的聲音里包含了遠(yuǎn)端用戶的回聲和近端用戶真實(shí)的聲音是很難區(qū)分的：這兩個(gè)聲波都是從空氣中采集進(jìn)來(lái)的沒(méi)有差別的聲音，有點(diǎn)像藍(lán)墨水和紅墨水混在一起，很難分開(kāi)一樣。

那就沒(méi)辦法了嗎？其實(shí)我們還是有一些辦法的。遠(yuǎn)端傳過(guò)來(lái)的原音是參考信號(hào)，它和回聲信號(hào)雖然相關(guān)，但是并不完全一樣。如果直接把麥克風(fēng)采集進(jìn)來(lái)的聲音減去原音是不對(duì)的。因?yàn)榛芈暿菂⒖夹盘?hào)播放出來(lái)以后，在空氣中經(jīng)過(guò)反彈和疊加以后形成的，和參考信號(hào)有相關(guān)性，但不等同。我們可以理解為回聲信號(hào)和參考信號(hào)有一定函數(shù)關(guān)系，而我們需要做的就是把這個(gè)函數(shù)關(guān)系求解出來(lái)。通過(guò)參考信號(hào)作為函數(shù)的輸入，模擬出回聲信號(hào)，再把麥克風(fēng)采集到的聲音信號(hào)減去模擬回聲信號(hào)，最終達(dá)到回聲消除的目的。我們是通過(guò)濾波器來(lái)實(shí)現(xiàn)這個(gè)函數(shù)，濾波器會(huì)不斷的學(xué)習(xí)和收斂，模擬回聲信號(hào)，使模擬回聲盡量逼近回聲信號(hào)，然后將麥克風(fēng)采集進(jìn)來(lái)的聲音信號(hào)減去模擬回聲信號(hào)，達(dá)到回聲消除的目的。這個(gè)步驟也稱為線性處理。

回聲有三種場(chǎng)景類型：靜音，單講和雙講。對(duì)于單講（也就是一個(gè)人講話）來(lái)說(shuō)，線性處理后抑制的效果會(huì)比較好，回聲消除得比較干凈。對(duì)于雙講（也就是多人同時(shí)講話）來(lái)說(shuō)，線性處理后抑制的效果就不是那么好，這時(shí)就需要采取第二個(gè)步驟：非線性處理，把剩余的回聲消除干凈。非線性處理沒(méi)有太多開(kāi)源的東西作為參考，要靠各家廠商自己去研究，十分能體現(xiàn)各家廠商的技術(shù)積累。

三、抖動(dòng)緩沖

網(wǎng)絡(luò)存在擁塞、丟包、亂序和抖動(dòng)，因此網(wǎng)絡(luò)傳輸會(huì)帶來(lái)數(shù)據(jù)損傷。特別是使用基于UDP的私有協(xié)議來(lái)傳輸語(yǔ)音視頻數(shù)據(jù)的時(shí)候，需要做抖動(dòng)緩沖。以WebRTC為例，對(duì)音頻數(shù)據(jù)的抖動(dòng)緩沖叫NetEQ，對(duì)視頻數(shù)據(jù)的緩沖叫做JitterBuffer，都是WebRTC開(kāi)源項(xiàng)目中十分有價(jià)值的部分。抖動(dòng)緩沖就是對(duì)數(shù)據(jù)包進(jìn)行緩沖排序，對(duì)丟包和亂序這些網(wǎng)絡(luò)情況進(jìn)行補(bǔ)償，來(lái)保障流暢性。抖動(dòng)緩沖的隊(duì)列長(zhǎng)度本質(zhì)上就是隊(duì)列延遲時(shí)間，如果太長(zhǎng)的話延遲就很大，太短的話抖動(dòng)就會(huì)被顯現(xiàn)出來(lái)，用戶體驗(yàn)就不好。有關(guān)抖動(dòng)緩沖區(qū)長(zhǎng)度的設(shè)置，每一個(gè)廠商做法不一樣，有的是將網(wǎng)絡(luò)報(bào)文的抖動(dòng)時(shí)間的最大方程作為緩沖隊(duì)列的長(zhǎng)度。這是一個(gè)開(kāi)放的話題，需要各家廠商自己去思考。

我們?cè)谶@里做一個(gè)階段小結(jié)，從推流端到拉流端，整個(gè)流程包括了七個(gè)環(huán)節(jié)：采集、前處理、編碼、推流、拉流、解碼和渲染。那我們一起來(lái)看看上面三個(gè)技術(shù)難點(diǎn)分別在哪些環(huán)節(jié)？

1) 低延遲，基本上引入延遲的有三類環(huán)節(jié)：采集和渲染、編解碼、網(wǎng)絡(luò)傳輸。第一類是采集和渲染環(huán)節(jié)，帶來(lái)的延遲比較大，尤其是渲染，幾乎沒(méi)有任何移動(dòng)端系統(tǒng)可以保證百分之百做到50毫秒的延遲，這是一些硬件上的限制造成的。第二類是編解碼環(huán)節(jié)，特別是音頻編解碼器是往前編碼的，這個(gè)本身就會(huì)帶來(lái)延遲，甚至有些音頻編解碼器能帶來(lái)200毫秒的延遲。第三類是網(wǎng)絡(luò)傳輸，在即構(gòu)科技的實(shí)時(shí)傳輸網(wǎng)絡(luò)里，往返的傳輸延遲分別都可以做到50毫秒以下。其中，采集和渲染、編解碼都是在終端實(shí)現(xiàn)的。

2) 回聲消除，屬于語(yǔ)音前處理3A，需要在前處理環(huán)節(jié)進(jìn)行，也就是在終端實(shí)現(xiàn)的。

3) 抖動(dòng)緩沖，是在接收端實(shí)現(xiàn)的，通過(guò)接收端的抖動(dòng)緩沖來(lái)決定發(fā)送端要以多大的時(shí)間間隔來(lái)發(fā)送數(shù)據(jù)包。

綜上所述，剛才說(shuō)的三個(gè)技術(shù)難點(diǎn)都是在終端實(shí)現(xiàn)的，因此終端非常重要。下面我們重點(diǎn)比較連麥直播技術(shù)在各種終端上的實(shí)現(xiàn)。

連麥直播在各種終端的比較

連麥直播的終端主要包括：原生APP、瀏覽器H5、瀏覽器WebRTC、微信小程序。瀏覽器上的應(yīng)用包括H5和WebRTC，前者可以拉流觀看，后者可以實(shí)現(xiàn)推流和拉流。

連麥直播移動(dòng)終端-Native APP

原生APP終端音視頻引擎畫(huà)的結(jié)構(gòu)框圖如下，基本包括了音頻引擎、視頻引擎和網(wǎng)絡(luò)傳輸，合稱實(shí)時(shí)語(yǔ)音視頻終端引擎。這里還包含底層的音視頻采集和渲染，還有網(wǎng)絡(luò)的輸入輸出能力，這是操作系統(tǒng)開(kāi)放的能力。

原生APP有個(gè)天然的好處，它是直接和操作系統(tǒng)打交道的，操作系統(tǒng)開(kāi)放的資源和能力它都可以直接用，比如說(shuō)音視頻的采集渲染，還有網(wǎng)絡(luò)的輸入輸出。套用一句時(shí)髦的廣告語(yǔ)：“沒(méi)有中間商賺差價(jià)”，直接和操作系統(tǒng)對(duì)接，可以獲得比較好的用戶體驗(yàn)。

在原生APP上實(shí)現(xiàn)連麥直播的優(yōu)勢(shì)是，對(duì)上面所說(shuō)的七個(gè)環(huán)節(jié)有較好的把控，可以獲得比較低的延遲，能自研實(shí)現(xiàn)語(yǔ)音前處理3A算法，包括回聲消除，還有對(duì)抖動(dòng)緩沖策略和碼率自適應(yīng)的策略都有比較好的把控。另外，可以自主選擇使用RTMP協(xié)議還是基于UDP的私有協(xié)議，對(duì)抗弱網(wǎng)環(huán)境更加有保障。

市面上比較流行的前處理技術(shù)，比如美顏、掛件、變聲等，原生APP都可以通過(guò)開(kāi)放前處理接口讓開(kāi)發(fā)者實(shí)現(xiàn)或者對(duì)接這些技術(shù)。為什么要強(qiáng)調(diào)這個(gè)呢？因?yàn)闉g覽器WebRTC和微信小程序都沒(méi)有開(kāi)放前處理接口，開(kāi)發(fā)者沒(méi)有辦法自行實(shí)現(xiàn)或者對(duì)接第三方的美顏或者掛件等技術(shù)模塊。

在原生APP上，開(kāi)發(fā)者可以得到全面的把控能力，讓用戶可以獲得更好的體驗(yàn)。主流的視頻直播平臺(tái)都有自己的原生APP平臺(tái)，而瀏覽器和微信小程序相對(duì)來(lái)說(shuō)是輔助的。原生APP的用戶體驗(yàn)是最好的，而且對(duì)開(kāi)發(fā)者來(lái)說(shuō)也是最可控的。

在原生APP上實(shí)現(xiàn)連麥直播的劣勢(shì)是什么呢？開(kāi)發(fā)門檻高，開(kāi)發(fā)周期長(zhǎng)、人力成本高。另外，從獲取用戶和傳播的角度來(lái)講，也沒(méi)有瀏覽器和微信小程序那么便利。

連麥直播移動(dòng)終端-瀏覽器（H5）

瀏覽器H5就像一個(gè)硬幣有兩面，有好處也有劣勢(shì)，好處是開(kāi)發(fā)成本低，容易傳播，劣勢(shì)是只能拉流，不能推流，不能做到多個(gè)用戶連麥直播。另外，在瀏覽器H5上延遲也是比較大。如果使用RTMP或者HTTP-FLV，延遲會(huì)在1秒到3秒之間，如果用HLS延遲會(huì)大于8秒甚至10秒，這么大的延遲就根本就不允許實(shí)現(xiàn)連麥直播。

使用這三種協(xié)議都是通過(guò)瀏覽器H5中的播放器來(lái)播放的。在多主播連麥互動(dòng)的場(chǎng)景中，一個(gè)播放器里面只能播一路視頻流，三個(gè)主播就得三個(gè)播放器，因此看不到多個(gè)主播同框連麥互動(dòng)的情形。如果要看到多個(gè)主播同框互動(dòng)的畫(huà)面，就必須把多路流混合成一路流，在單個(gè)播放器里面播放。

另外，瀏覽器H5的源代碼是開(kāi)放的。如果在瀏覽器上把音視頻終端引擎實(shí)現(xiàn)了，相當(dāng)于對(duì)外公開(kāi)了所有核心的源代碼。因此，還沒(méi)有見(jiàn)過(guò)哪個(gè)廠商在瀏覽器H5上完整地把音視頻引擎真正做出來(lái)。即使你愿意做出來(lái)，瀏覽器也不會(huì)允許你這樣做，開(kāi)發(fā)者和操作系統(tǒng)之間隔著瀏覽器，如果瀏覽器不把操作系統(tǒng)的核心能力開(kāi)放給開(kāi)發(fā)者，開(kāi)發(fā)者就不能自主采集和渲染，不能掌控網(wǎng)絡(luò)輸入輸出，類似流控碼控等功能無(wú)法實(shí)現(xiàn)。

在瀏覽器H5中也可以通過(guò)websocket來(lái)傳輸，用jsmpeg來(lái)播放，視頻編解碼的格式用mpeg1。

mpeg1是一個(gè)比較老的媒體格式，所有瀏覽器都支持。在瀏覽器中使用jsmpeg播放器播放mpeg1，所有瀏覽器也可以支持。這么做可以獲得比較低的延遲，但是還是無(wú)法推流，沒(méi)辦法實(shí)現(xiàn)連麥直播。

例子：線上抓娃娃H5版

下面使用即構(gòu)線上抓娃娃H5版本為例，簡(jiǎn)單介紹一下websocket在瀏覽器H5上的應(yīng)用。從下圖左上角可以看到，在瀏覽器H5終端接入即構(gòu)實(shí)時(shí)傳輸網(wǎng)絡(luò)時(shí)，我們加入了一個(gè)視頻接入服務(wù)器，右邊是即構(gòu)實(shí)時(shí)傳輸網(wǎng)絡(luò)，使用基于UDP的私有協(xié)議。通過(guò)接入服務(wù)器實(shí)現(xiàn)協(xié)議的轉(zhuǎn)換和媒體格式的轉(zhuǎn)換：websocket和基于UDP的私有協(xié)議的轉(zhuǎn)換，mpeg1和H.264的轉(zhuǎn)換。如果原生APP接入就不需要做轉(zhuǎn)換，雖然有接入服務(wù)器，但是不會(huì)做轉(zhuǎn)換。

另外，線上抓娃娃的H5版本是沒(méi)有聲音的，除了應(yīng)用場(chǎng)景的特點(diǎn)要求外，也要用H5實(shí)現(xiàn)了音頻引擎才能有聲音。如果在瀏覽器H5上實(shí)現(xiàn)了音頻引擎，就相當(dāng)于把技術(shù)開(kāi)源了，目前還沒(méi)有看到哪個(gè)廠商這么做。

連麥直播移動(dòng)終端-瀏覽器（WebRTC）

大家可能會(huì)覺(jué)得很遺憾，瀏覽器H5雖然很容易傳播，開(kāi)發(fā)簡(jiǎn)單但是體驗(yàn)欠佳，不能連麥直播。那么在瀏覽器上能不能推流，能不能實(shí)現(xiàn)連麥直播呢？答案是可以的，那就要用到WebRTC。

這里說(shuō)的WebRTC是指已經(jīng)被內(nèi)嵌到瀏覽器里面，被瀏覽器支持的WebRTC，而不是WebRTC的源代碼。部分主流瀏覽器內(nèi)嵌了WebRTC，對(duì)開(kāi)發(fā)者開(kāi)放了瀏覽器的實(shí)時(shí)音視頻能力。

上圖是WebRTC的結(jié)構(gòu)圖。我們可以看到WebRTC包括了音頻引擎，視頻引擎、傳輸引擎等，最底層的虛線框表示可以重載，也就是說(shuō)瀏覽器把最底層的音視頻渲染和網(wǎng)絡(luò)傳輸?shù)牡讓幽芰﹂_(kāi)放給開(kāi)發(fā)者，開(kāi)發(fā)者可以根據(jù)自己的需求選擇是否進(jìn)行重載。音頻引擎中，包括了兩個(gè)編解碼器：iSAC和iLBC，前者針對(duì)寬帶和超寬帶的音頻編解碼，后者針對(duì)窄帶音頻編解碼。音頻引擎還包括了音頻抖動(dòng)緩沖，回聲消除和噪音抑制模塊等。抖動(dòng)緩沖中的NetEQ算法可以說(shuō)是WebRTC里面的精華之一。視頻引擎中，包括了VP8和VP9的視頻編解碼器，甚至是即將到來(lái)的AV1。視頻引擎還包括視頻抖動(dòng)緩沖和圖像質(zhì)量增強(qiáng)等模塊。傳輸引擎，WebRTC使用的是SRTP（Secured Realtime Transport Protocol）安全實(shí)時(shí)傳輸協(xié)議。最后，WebRTC采取P2P的通信方式，沒(méi)有媒體服務(wù)器等后端的實(shí)現(xiàn)。以上是WebRTC的簡(jiǎn)單介紹。

瀏覽器WebRTC一般的優(yōu)勢(shì)和劣勢(shì)這里就不再重復(fù)，請(qǐng)大家自行百度，這里只說(shuō)重點(diǎn)。瀏覽器WebRTC的好處就是實(shí)現(xiàn)了相對(duì)完整的音視頻終端引擎，允許在瀏覽器上推流，可以實(shí)現(xiàn)連麥直播。然而，瀏覽器WebRTC也有不足：

1. 沒(méi)有開(kāi)放前處理接口，美顏和掛件這些模塊沒(méi)辦法接入第三方的或者自研方案。
2. 媒體服務(wù)器后端沒(méi)有實(shí)現(xiàn)，開(kāi)發(fā)者要實(shí)現(xiàn)媒體服務(wù)器，然后通過(guò)開(kāi)源WebRTC網(wǎng)關(guān)（比如說(shuō)janus）接入。
3. 編解碼器、抖動(dòng)緩沖和語(yǔ)音前處理3A等能力只能依靠WebRTC，不能自行定制化。
4. 部分主流瀏覽器是不支持WebRTC的，特別是蘋(píng)果的瀏覽器。雖然說(shuō)去年蘋(píng)果宣布支持WebRTC,但是目前iOS Safari最新版本對(duì)WebRTC的支持并不好，iOS Safari的主流版本并不支持WebRTC，在iOS上面微信瀏覽器也是不支持WebRTC的。

如上圖所示，由于WebRTC不提供媒體服務(wù)器的實(shí)現(xiàn)，因此需要把瀏覽器WebRTC接入到媒體服務(wù)器后端，這個(gè)可以是自研的，也可以是第三方的服務(wù)。瀏覽器WebRTC和媒體服務(wù)器后端之間的協(xié)議和媒體格式是不一樣的，因此要做協(xié)議和格式的轉(zhuǎn)換。WebRTC用的基于UDP的SRTP，需要把它轉(zhuǎn)換成媒體服務(wù)器的基于UDP的私有協(xié)議。另外，媒體格式也需要轉(zhuǎn)換，因?yàn)閃ebRTC中語(yǔ)音視頻格式默認(rèn)用的是VP8或者VP9。同時(shí)實(shí)時(shí)傳輸網(wǎng)絡(luò)中有關(guān)信令調(diào)度也需要做一些調(diào)整。瀏覽器WebRTC和媒體服務(wù)器后端之間的接入層也可以采用開(kāi)源的WebRTC Gateway（比如說(shuō)janus）來(lái)實(shí)現(xiàn)。

瀏覽器是類似操作系統(tǒng)的一種超級(jí)應(yīng)用，它坐擁重要的流量入口，然而它也是開(kāi)發(fā)者和操作系統(tǒng)之間的“中間商”。開(kāi)發(fā)者通過(guò)WebRTC獲得瀏覽器開(kāi)放的實(shí)時(shí)音視頻能力，然而也必須要承受WebRTC帶來(lái)的痛苦。

連麥直播移動(dòng)終端-微信小程序

這次演講的標(biāo)題是《連麥互動(dòng)直播X微信小程序》, 為什么直到這里才開(kāi)始討論小程序？請(qǐng)?jiān)试S我解釋一下原因。微信小程序是什么？是跑在微信上面的輕型應(yīng)用。微信是什么？是類操作系統(tǒng)的超級(jí)應(yīng)用。這些特征和瀏覽器以及H5是不是很接近？H5是瀏覽器支持的輕型應(yīng)用，而瀏覽器是類操作系統(tǒng)的超級(jí)應(yīng)用。瀏覽器背后是各大國(guó)際科技巨頭，不像微信這樣背后只有騰訊一個(gè)互聯(lián)網(wǎng)巨頭。因此，從這個(gè)角度來(lái)看，微信小程序、瀏覽器WebRTC和H5是有相通之處的。

微信小程序可以類比為瀏覽器H5那樣的客戶端和服務(wù)器的結(jié)構(gòu)。其中HTML對(duì)應(yīng)微信小程序的WXML，CSS對(duì)應(yīng)小程序的WXSS，小程序的腳本語(yǔ)言和JS是一樣的，只是框架不一樣。微信小程序提供了兩個(gè)標(biāo)簽，一個(gè)是<live-pusher>，一個(gè)是<live-player>。<live-pusher>就是推流，<live-player>就是拉流，可以實(shí)現(xiàn)單向直播或者連麥直播。小程序提供兩種模式：LIVE和RTC，LIVE支持單向直播，RTC支持低延遲的連麥直播。目前微信小程序推流采用RTMP協(xié)議，如果要和私有協(xié)議互通，需要進(jìn)行協(xié)議轉(zhuǎn)換。

微信小程序開(kāi)放了實(shí)時(shí)音視頻能力，對(duì)業(yè)界來(lái)說(shuō)是重大利好。然而，根據(jù)上面的信息和邏輯，我們也看到采用微信小程序?qū)崿F(xiàn)連麥互動(dòng)直播的好處和不足。

好處有三點(diǎn)：

1）開(kāi)發(fā)成本低，開(kāi)發(fā)周期短，基本和H5的開(kāi)發(fā)難度差不多；

2）很容易傳播和獲客，充分利用好微信的優(yōu)質(zhì)流量；

3）可以推流和拉流，允許實(shí)現(xiàn)連麥直播和實(shí)時(shí)語(yǔ)音視頻通話。

不足有四點(diǎn)：

1. 你會(huì)受制于微信小程序的實(shí)時(shí)音視頻能力，比如說(shuō)，如果它的回聲消除有某些問(wèn)題，你只能等微信團(tuán)隊(duì)按照自己的節(jié)奏來(lái)優(yōu)化，而自己沒(méi)有任何辦法去優(yōu)化。
2. 小程序沒(méi)有開(kāi)放前處理接口，只能使用小程序自帶的美顏或者變聲功能（如果有），不能對(duì)接自行研發(fā)或者第三方的美顏或者變聲模塊。
3. 通過(guò)RTMP協(xié)議推流和拉流，不能和基于UDP的私有協(xié)議互通連麥。如果要實(shí)現(xiàn)和基于UDP的私有協(xié)議互通連麥，就必須要增加接入層來(lái)轉(zhuǎn)換協(xié)議格式甚至媒體格式。
4. 沒(méi)有實(shí)現(xiàn)后端媒體服務(wù)器，開(kāi)發(fā)者必須要自行實(shí)現(xiàn)媒體服務(wù)器，或者把微信小程序接入到第三方的實(shí)時(shí)通信網(wǎng)絡(luò)。

瀏覽器通過(guò)WebRTC開(kāi)放了瀏覽器的實(shí)時(shí)音視頻能力，而微信通過(guò)小程序開(kāi)放了微信的實(shí)時(shí)音視頻能力，在兩個(gè)類操作系統(tǒng)的平臺(tái)上允許開(kāi)發(fā)者去實(shí)現(xiàn)連麥直播和實(shí)時(shí)音視頻通話。然而，無(wú)論WebRTC還是小程序只是在終端上帶你入門，對(duì)開(kāi)發(fā)者來(lái)說(shuō)，要真正實(shí)現(xiàn)整套系統(tǒng)，還有很多工作需要做的。

下圖展示了微信小程序如何接入到實(shí)時(shí)音視頻傳輸網(wǎng)絡(luò)。微信小程序的音視頻終端引擎也包含了音頻引擎，視頻引擎還有傳輸引擎。音頻引擎要負(fù)責(zé)采集和渲染，音頻抖動(dòng)緩沖，語(yǔ)音前處理和編解碼。視頻引擎要負(fù)責(zé)采集和渲染、視頻抖動(dòng)緩沖，視頻前處理和編解碼。關(guān)于傳輸引擎，微信小程序采用RTMP協(xié)議來(lái)推拉流，尚不清楚它的RTMP協(xié)議下層是TCP協(xié)議，還是通過(guò)QUIC來(lái)使用基于UDP的私有協(xié)議。如果RTMP的下層是基于UDP的私有協(xié)議，那么在弱網(wǎng)環(huán)境下的抗性會(huì)相對(duì)比較好一些，而TCP協(xié)議是一種面對(duì)公平的協(xié)議，對(duì)各個(gè)環(huán)節(jié)的可控性不強(qiáng)，在弱網(wǎng)環(huán)境下體驗(yàn)就相對(duì)差一些。

如果要將微信小程序接入實(shí)時(shí)音視頻傳輸網(wǎng)絡(luò)，中間得有接入服務(wù)器，我們叫接入層。在接入層我們需要做協(xié)議的轉(zhuǎn)換，比如說(shuō)，如果實(shí)時(shí)音視頻傳輸網(wǎng)絡(luò)是使用基于UDP的私有協(xié)議，那么要把RTMP協(xié)議轉(zhuǎn)為基于UDP的私有協(xié)議。還有媒體格式的轉(zhuǎn)換，如果和實(shí)時(shí)傳輸網(wǎng)絡(luò)的媒體格式不一樣，還需要進(jìn)行轉(zhuǎn)換。

連麥直播移動(dòng)終端-WebRTC通過(guò)WebView接入小程序

還有別的方法在小程序上做連麥直播互動(dòng)嗎？必須要使用微信小程序開(kāi)放的語(yǔ)音視頻能力嗎？也不一定。下圖展示了我在市面上看過(guò)的一個(gè)技術(shù)方案，它繞過(guò)了微信小程序?qū)崟r(shí)語(yǔ)音視頻能力，通過(guò)微信小程序WebView組件實(shí)現(xiàn)了連麥直播的方案。這里和大家分享一下。

這個(gè)方案的基本思路是利用WebView的瀏覽器特點(diǎn)，在WebView內(nèi)使用WebRTC的Web API，從而在小程序上獲得實(shí)時(shí)音視頻能力。上圖是這個(gè)方案的拓?fù)鋱D。最底層是微信小程序的基礎(chǔ)能力。上一層是WebView，WebView是微信小程序的一個(gè)控件，可以簡(jiǎn)單看作一個(gè)類似瀏覽器的組件，提供了瀏覽器的一部分特性，但并不是完整的瀏覽器。微信小程序的WebView類似瀏覽器，那么就可能會(huì)支持WebRTC。然而必須要注意到，微信小程序的WebView在安卓平臺(tái)上支持WebRTC，但在iOS平臺(tái)上面不支持WebRTC。雖然這個(gè)方案理論上也能在微信小程序上實(shí)現(xiàn)連麥直播，但是它有以下的局限性：

1）在iOS平臺(tái)上，微信小程序不支持這個(gè)方案，上面已經(jīng)說(shuō)過(guò)。

1. 小程序WebView不是完整的瀏覽器，要比普通瀏覽器表現(xiàn)差而且有很多的限制。
2. 開(kāi)發(fā)者和操作系統(tǒng)之間隔了好幾層：微信底層，小程序，WebView，WebRTC，然后才是開(kāi)發(fā)者的小程序應(yīng)用。每一層的抽象都會(huì)帶來(lái)性能上的消耗，都會(huì)影響到最終的體驗(yàn)。

這個(gè)方案本質(zhì)上還是一個(gè)基于WebRTC的解決方案，沒(méi)有用到微信小程序開(kāi)放的實(shí)時(shí)音視頻能力，而是快速地借助WebView組件，劍走偏鋒，十分討巧地在微信小程序里使用了WebRTC。

連麥直播在各種終端的互通

隨著連麥互動(dòng)直播技術(shù)在各種終端上逐步實(shí)現(xiàn)，那么我們就會(huì)面臨一個(gè)問(wèn)題：在各種終端上可以連麥互通嗎？比如說(shuō)，用戶A在微信小程序上可以和用戶B在原生APP上連麥互通嗎？

我們從上面提到的場(chǎng)景說(shuō)起。用戶A在微信小程序上推流和拉流使用的是RTMP協(xié)議，如果用戶B在原生APP推流和拉流都是使用RTMP協(xié)議，那么兩者天然就是可以連麥互通的。如果原生APP推流和拉流都是使用基于UDP的私有協(xié)議，那么就不能直接地連麥互通，必須要經(jīng)過(guò)接入層進(jìn)行協(xié)議和格式的轉(zhuǎn)換才能互動(dòng)連麥。這個(gè)場(chǎng)景還可以延伸：用戶A在微信小程序上可以和用戶C在瀏覽器WebRTC上連麥互通嗎？背后的邏輯是一樣的。

以即構(gòu)科技的方案為例，即構(gòu)ZEGO的原生APP SDK有兩個(gè)版本：支持RTMP協(xié)議和基于UDP的私有協(xié)議，如果用的是支持RTMP協(xié)議的原生APP SDK，那么直接就可以和小程序互動(dòng)連麥，如果用了基于UDP的私有協(xié)議的原生APP SDK，那么就要經(jīng)過(guò)接入服務(wù)器進(jìn)行協(xié)議和格式的轉(zhuǎn)換。

基于UDP的私有協(xié)議在弱網(wǎng)環(huán)境下會(huì)有更好的表現(xiàn)，而RTMP協(xié)議在非弱網(wǎng)的情況下表現(xiàn)也相當(dāng)好，而且能夠很好地兼容CDN內(nèi)容分發(fā)網(wǎng)絡(luò)。舉個(gè)例子，花椒直播的連麥直播方案一直都是使用即構(gòu)科技提供的RTMP版本的技術(shù)方案，在線上運(yùn)行兩年了，一直都保持良好的用戶體驗(yàn)。

結(jié)語(yǔ)

連麥直播技術(shù)逐步在原生APP, 瀏覽器H5，瀏覽器WebRTC，微信小程序上延伸，衍生出更加豐富的生態(tài)，提供更加便捷和良好的用戶體驗(yàn)，對(duì)視頻直播平臺(tái)和用戶來(lái)說(shuō)是好消息。然而，欲帶皇冠，必承其重。特別是在瀏覽器WebRTC和微信小程序上，開(kāi)發(fā)者要充分理解這些類型終端的特點(diǎn)和局限，才能更好地在上面利用連麥直播技術(shù)進(jìn)行創(chuàng)新，服務(wù)用戶。

【福利】

ZEGO Meetup 上海站 | 視頻直播+的技術(shù)實(shí)踐之道

從2016年到2017年，視頻直播行業(yè)從爆發(fā)走向成熟。2017年與2018年之交，直播行業(yè)又煥發(fā)了第二春，讓人憧憬是否還有第三春。

起起伏伏的是行業(yè)的風(fēng)口和趨勢(shì)，穩(wěn)步前進(jìn)的是技術(shù)的實(shí)踐之道。

在剛剛結(jié)束了 ZEGO Meetup 北京站 后，我們決定繼續(xù)前往上海，與上海的伙伴們一起探討視頻直播的技術(shù)與最佳實(shí)踐。

本期活動(dòng)，我們邀請(qǐng)了即構(gòu)科技、么么直播、滬江CCtalk、涂圖TuSDK的4位音視頻技術(shù)大咖，他們將帶來(lái)：

《么么直播音視頻實(shí)踐和優(yōu)化》

《連麥互動(dòng)直播 X WebRTC》

《使用RTC技術(shù)，搭建優(yōu)秀的在線教育平臺(tái)》

《深度學(xué)習(xí)和視頻特效的技術(shù)融合》

干貨滿滿，就在本周六喔！

點(diǎn)擊文末“ 閱讀原文 ”即可快速報(bào)名喲~

報(bào)名成功的朋友，可以加即構(gòu)工作人員微信zego_tech_consulting，備注“姓名-公司-職位”，提前拉你進(jìn)入活動(dòng)現(xiàn)場(chǎng)群~

時(shí)間：2018年3月31日 13：00-17：30

地點(diǎn)：上海市徐匯區(qū)宜山路700號(hào)C3棟 朗盛科創(chuàng)中心1F 獨(dú)角獸全球平行加速器（桂林路地鐵站1號(hào)或5號(hào)出口）

嘉賓議程

Topic 1:《么么直播音視頻實(shí)踐和優(yōu)化》

黃銘新，么么直播前端團(tuán)隊(duì)負(fù)責(zé)人

嘉賓簡(jiǎn)介：曾就職于天天動(dòng)聽(tīng)、英語(yǔ)流利說(shuō)，現(xiàn)在么么直播負(fù)責(zé)前端開(kāi)發(fā)團(tuán)隊(duì)的team leader相關(guān)工作。技術(shù)上主要偏向于JS、Node全棧式開(kāi)發(fā)，主要負(fù)責(zé)公司內(nèi)的主站、內(nèi)部服務(wù)和部分微服務(wù)的開(kāi)發(fā)和管理。

內(nèi)容簡(jiǎn)介：

1、么么直播項(xiàng)目初期踩過(guò)的一些坑及其解決辦法，如延遲大、卡頓明顯、加載速度慢、在手機(jī)上的性能差等問(wèn)題

2、當(dāng)業(yè)務(wù)需要使用第三方的cdn、sdk時(shí)，如何進(jìn)行資源整合及不同sdk的相互調(diào)用

3、么么在Web/H5上的性能優(yōu)化及前端技術(shù)解決方案——如何降低flash的大小、減小延遲、無(wú)flash進(jìn)行flv播放等

Topic 2: 《連麥互動(dòng)直播 X WebRTC》

冼牛，即構(gòu)科技資深技術(shù)專家、架構(gòu)師

嘉賓簡(jiǎn)介：北京郵電大學(xué)計(jì)算機(jī)碩士，香港大學(xué)工商管理碩士，負(fù)責(zé)即構(gòu)實(shí)時(shí)音視頻引擎的開(kāi)發(fā)與研究，目前工作集中于直播技術(shù)在移動(dòng)端的全面適配，專注視頻直播、音視頻社交、物聯(lián)網(wǎng)和在線教育等行業(yè)。

內(nèi)容簡(jiǎn)介：連麥互動(dòng)直播技術(shù)要滿足應(yīng)用場(chǎng)景的訴求，而應(yīng)用場(chǎng)景要考慮移動(dòng)端的技術(shù)特點(diǎn)：原生的iOS和Android APP體驗(yàn)好但不易傳播，瀏覽器WebRTC易于傳播但受到技術(shù)限制。連麥互動(dòng)直播技術(shù)要充分考慮各種移動(dòng)端的技術(shù)特點(diǎn)，才能讓實(shí)時(shí)音視頻云服務(wù)的強(qiáng)大能力全面地覆蓋各種應(yīng)用場(chǎng)景。這次技術(shù)演講將從WebRTC切入，同時(shí)覆蓋微信小程序、瀏覽器H5和原生APP等移動(dòng)端，結(jié)合這些終端的技術(shù)特點(diǎn)，去分享直播技術(shù)在適配這些終端過(guò)程中的思考和實(shí)踐。