對于一個實時互動的音視頻系統(tǒng)而言，存在很多技術(shù)難點，有幾個比較重要的點：

首先是低延遲，如果要滿足比較流暢地進(jìn)行實時互動，那么單向的端到端的遲延大概要在400毫秒以下才能保證流暢溝通;

第二點就是流暢性，你也很難想象在視頻過程中頻繁卡頓會有良好的互動;

第三點是回聲消除，回聲的產(chǎn)生是揚(yáng)聲器播放的聲音經(jīng)過環(huán)境反射被麥克風(fēng)重新采集并傳輸給對方，這樣對方就會一直聽到自己的回聲，整個互動過程會非常難受;

第四點是國內(nèi)外互通，隨著現(xiàn)在國內(nèi)同質(zhì)化產(chǎn)品越來越多，國內(nèi)的競爭也異常激烈，很多廠商紛紛選擇出海，這時就需要做好海內(nèi)外的互通;

第五點是海量并發(fā)，當(dāng)然這不僅僅指實時音視頻了，基本對于任何一款互聯(lián)網(wǎng)產(chǎn)品而言都是必須要考慮的難點。

技術(shù)難點解決方案

關(guān)于這幾個技術(shù)難點，在這里跟大家分享一下ZEGO即構(gòu)科技的解決思路和實踐經(jīng)驗。

1、低延遲

首先，如果實時音視頻要保證低延遲，那么前端和后端的整個鏈條一定要做到極致的，比如前端的一些編碼算法、流控，甚至丟幀、追幀策略等等都要做到足夠好。另外，不同的業(yè)務(wù)場景下，編碼器的選擇也會有所區(qū)別，從而會帶來不同的編碼延遲，因此不同的業(yè)務(wù)場景能達(dá)到的延遲程度也是不一樣的。

其次，就是對推拉流網(wǎng)絡(luò)的選擇，通常的方案是讓需要實時互動的用戶通過核心語音視頻網(wǎng)絡(luò)——像BGP這樣的優(yōu)質(zhì)節(jié)點來做語音視頻傳輸，而對于一些特定場景來說，比如互動游戲會直播給一些圍觀用戶看，那么這里就需要做轉(zhuǎn)碼、轉(zhuǎn)協(xié)議、甚至混流，再通過內(nèi)容分發(fā)網(wǎng)絡(luò)去分發(fā)。像 內(nèi)容分發(fā)網(wǎng)絡(luò)本身天然就有做就近接入，但對于接入核心語音視頻網(wǎng)絡(luò)就需要有智能的調(diào)度策略來完成就近接入，以及跨運(yùn)營商、跨區(qū)域的接入，比如可以采用上次登錄IP、常用IP和區(qū)域調(diào)度，甚至可以測速再去連接，當(dāng)然網(wǎng)絡(luò)調(diào)度的策略也需要根據(jù)業(yè)務(wù)群的分布仔細(xì)規(guī)劃，甚至采用多個策略配置權(quán)重的方式。

2、流暢性

要實現(xiàn)流暢性也會有很多的技術(shù)難點和策略，我主要會介紹其中幾種。第一個是可以做動態(tài)伸縮的JitterBuffer，在網(wǎng)絡(luò)較差或者網(wǎng)絡(luò)抖動比較劇烈的情況下，可以適當(dāng)增大JitterBuffer，從而降低一點點延遲來對抗抖動。

第二個是快播和慢播技術(shù)，在網(wǎng)絡(luò)較差的環(huán)境，可以在用戶無感知的條件下稍微降低播放速度，來應(yīng)對短暫網(wǎng)絡(luò)抖動引起的立即卡頓，當(dāng)網(wǎng)絡(luò)恢復(fù)可以加快速度追回來，但這種方式并非適合所有場景，比如對于節(jié)奏要求非常準(zhǔn)確的唱歌場景，當(dāng)播放速度稍微放慢就可以被感知。

第三個是碼率自適應(yīng)，也就是以比較合適的碼率做動態(tài)傳輸，為了保證流暢度甚至可以調(diào)整幀率和分辨率。語音視頻引擎會根據(jù)當(dāng)前網(wǎng)絡(luò)測速的結(jié)果和應(yīng)用所期望的碼率，動態(tài)地調(diào)整碼率、幀率和分辨率，最終達(dá)到流暢觀看的用戶體驗。

第四個是分層編碼、傳輸控制，在推流端做一些分層的編碼，這樣在拉流端可以動態(tài)根據(jù)偵測到的網(wǎng)絡(luò)帶寬情況來拉取不同的數(shù)據(jù)去做渲染。分層編碼允許拉流端取選擇不同層次的視頻編碼數(shù)據(jù)，網(wǎng)絡(luò)情況好的時候，就拉取較多層次的數(shù)據(jù);網(wǎng)絡(luò)情況差的情況下，就拉取基礎(chǔ)層次的數(shù)據(jù)。

第五個是動態(tài)調(diào)度，當(dāng)在推拉流端監(jiān)測當(dāng)前推拉流質(zhì)量比較差，而且即使通過降低碼率、幀率和分辨率等策略已經(jīng)無法保證質(zhì)量，這時就可以選擇放棄這條鏈路，直接重新做選入、建立連接，當(dāng)然在這個過程中可能會出現(xiàn)短暫的停頓。

3、回聲消除

首先介紹下回聲消除的原理：對端發(fā)送的信號會先給到回聲消除的模塊，作為將來消除的參考信號，再把信號給到揚(yáng)聲器播放，揚(yáng)聲器播放后由于周圍環(huán)境反射形成回聲，與真實的音頻輸入一同被麥克風(fēng)采集，這時采集到的輸入信號是帶有回聲的，回聲消除模塊會根據(jù)前面的參考信號生成濾波抵消掉回聲消后再發(fā)送出去。

原理聽起來會比較簡單，但在實際過程中卻蘊(yùn)藏著很多的難點，比如回聲消除模塊接收的參考信號與最終被環(huán)境反射后的回聲本身就是存在差異的，此外設(shè)備也會極大的影響回聲消除，尤其是國內(nèi)的安卓機(jī)型特別多，比如國內(nèi)某手機(jī)廠商，從麥克風(fēng)采集音頻數(shù)據(jù)到提交中間有將近一百毫秒的延遲，這時回聲消除算法如何適應(yīng)這么長回聲延遲的手機(jī)就很關(guān)鍵;再比如很多用戶在直播中都會用外置聲卡，甚至是模擬器，這無形中也會帶來回聲的延遲。除了設(shè)備，場地同樣存在很大的相關(guān)性，對于普通會議室，設(shè)置 40米的回聲延遲可能已經(jīng)足夠了，但一些大會場這種回聲延遲能達(dá)到將近上百米，這也是一種挑戰(zhàn)。

關(guān)于回聲消除，其實谷歌開源的WebRTC提供了回聲消除模塊，但WebRTC的設(shè)計本身是為了在PC端實時音視頻互動的場景，在移動端的適應(yīng)性上就會差一些，尤其體現(xiàn)在安卓的一些低端機(jī)上。而相對來說，蘋果因為整體硬件、軟件全是自己實現(xiàn)的，麥克風(fēng)、揚(yáng)聲器也都有聲學(xué)模型設(shè)計，因此回聲消除的效果會比安卓好很多。即構(gòu)科技的音視頻引擎都是采用自研，在真機(jī)和模擬器等1000多的機(jī)型上測試過，都可以做到很好的回聲消除。

4、 國內(nèi)外互通

前面提到很多產(chǎn)品都會選擇出海，包括主打國內(nèi)市場的產(chǎn)品也會有一些海外用戶，因此流媒體數(shù)據(jù)和控制信令就要做好跨國的互通，這就需要考慮在全球合理布置一些中繼節(jié)點。

這張圖就是一個典型的中繼續(xù)傳，北京用戶和迪拜用戶之間要做視頻溝通，根據(jù)就近接入原則他們會分別連接當(dāng)?shù)氐墓?jié)點，而這兩個節(jié)點間如果互拉，效果會非常差，這時就需要布置適合的中繼節(jié)點，比如香港、新加坡、日本等等，數(shù)據(jù)路徑的選擇是需要根據(jù)業(yè)務(wù)側(cè)決定的，也就是說在物理鏈路路由之上還要再有一條業(yè)務(wù)的路由表，需要根據(jù)用戶場景制定，包括用戶分布、用戶訪問頻率、高頻段峰值等等，可能每次的路由都會有所不同。

5、海量并發(fā)

海量并發(fā)是所有互聯(lián)網(wǎng)產(chǎn)品都會遇到的問題，這里就不再展開，主要要考慮負(fù)載均衡，如何平滑擴(kuò)容，對于無法覆蓋的地方要做代理調(diào)度，甚至需要考慮容災(zāi)、接入層的設(shè)計等等。

實時語音視頻的技術(shù)門檻相對比較高，如果依靠自己研發(fā)，可能即使會投入很多開發(fā)成本也無法與匹配市場快速發(fā)展的節(jié)奏。現(xiàn)在實時音視頻云服務(wù)已經(jīng)十分成熟，其實不妨“讓專業(yè)的人去做專業(yè)的事”。

總結(jié)

以上是生活随笔為你收集整理的实时音视频技术难点及解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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