優質一對一原始碼“輔助”解決音影片直播技術難點

直播作為實時性和互動性要求較高的音影片應用場景，存在非常多的技術難點，就連一對一的直播模式也毫不例外。比如低延遲、流暢性、回聲消除、國內外互通和海量併發等問題，都是開發過程中的難點。但是，在開發過程中如果具備了優質的一對一原始碼，那麼這些難點可能都會得到一定的解決。

1.  低延遲

要想保證低延遲，前端和後端整個鏈條一定要做的非常嚴謹。像前端的一些編碼演算法或者是丟幀策略等都要做好。此外，不同的業務場景之間編碼器的選擇也會有所不同，從而也會帶來不同程度上的編碼延遲，所以不同的業務場景能夠達到的延遲程度也是不一樣的。還有就是對於推拉流網路的選擇，大部分的解決方案都會讓需要實時互動的使用者透過核心的語音影片網路，像是 BGP之類的優質節點來做傳輸，也有可能需要做轉碼、轉協議或混流之後，再透過聶榮分發網路去分發。這樣一來，在接入核心語音影片網路時就需要有智慧的排程策略來完成就近接入了。

2.流暢性

流暢性作為直播過程中容易出現較多技術難點的一個方面，需要注意的也有很多。

（ 1 ）可以做動態伸縮的 jitterbuffer，在網路狀況差或者是網路抖動比較劇烈的情況下，可可以適當增大，從而降低延遲來對應出現的網路抖動情況。

（ 2 ）快播和滿播技術在網路環境較差時，可以在使用者毫無感知的條件下稍微降低播放速度，然後來解決短暫出現的網路抖動所引起的卡頓情況，當網路恢復後，還可以快速追趕回來。需要注意的是，這種方式並不適合所有的應用場景。

（ 3）位元速率自適應，也就是說選擇合適的位元速率來做動態傳輸。為了保證流暢度可以適當調整解析度和幀率，當然，語音影片引擎會根據當前的網路測速結果和應用需要的位元速率，動態調整位元速率、幀率和解析度，以此達到流暢觀看的使用者體驗。

（ 4 ）在推流端做一些分層的編碼，這樣一來，在拉流端可以動態的根據偵測到的網路頻寬情況來拉取不同的資料去做渲染。而分層編碼允許拉流端選擇不同層次的影片編碼資料，網路情況好的時候，就選取較多層次的資料，網路情況差的情況下，就選取基礎層次的資料。

（ 5 ）在推拉流端監測當前推拉流質量比較差時，即使透過降低位元速率、解析度和幀率等策也無法保證質量時，可以選擇放棄此鏈路。

3.回聲消除

先簡單介紹一下回聲消除的原理，對端傳送的訊號會先給到回聲消除的模組，作為將來消除的參考訊號，再將訊號給到揚聲器播放，播放後由於周圍環境反射形成回聲，與真實的音訊輸入一同被麥克風採集，這時採集到的輸入訊號是帶有回聲的，回聲消除模組會根據前面的參考訊號生成濾波抵消掉會回聲後再傳送出去。至於回聲消除的問題，谷歌開源的 WebRTC提供了回聲消除模組，但它本身設計是為了在PC端實現音影片互動場景，在移動端的適應性較差，尤其是Android端。

4.  國內外互通

這一點適用於海外運營的使用者，流媒體資料和控制信令就需要做好跨國互通，所以要考慮在全球合理佈置一些中繼節點。資料路徑的選擇是需要根據業務決定的，也就是說在物理鏈路路由之上還需要再有一條業務的路由表，並且根據使用者的場景制定，比如使用者分佈、訪問頻率或高頻段峰值等。可能每次的路由都會不同。

5.  海量併發

這是所有的網際網路相關產品都會遇到的問題， 主要考慮負載均衡，如何平滑擴容，對於無法覆蓋的地方要做代理排程，甚至需要考慮容災、接入層的設計等等 ，再此就不多做贅述。

由此可見，在開發過程中不僅需要優質的一對一原始碼作為 “輔助”，還需要考慮多方面因素和可能發生的問題，只有這樣才能開發出真正優質的直播 app。如若不然，將會在直播領域中就此“銷聲匿跡”。

本文宣告原創，轉載請註明出處。