1.低延遲
要想保證低延遲，前端和後端整個鏈條一定要做的非常嚴謹。像前端的一些編碼算法或者是丟幀策略等都要做好。此外，不同的業務場景之間編碼器的選擇也會有所不同，從而也會帶來不同程度上的編碼延遲，所以不同的業務場景能夠達到的延遲程度也是不一樣的。還有就是對於推拉流網絡的選擇，大部分的解決方案都會讓需要實時互動的用戶通過核心的語音視頻網絡，像是BGP之類的優質節點來做傳輸，也有可能需要做轉碼、轉協議或混流之後，再通過聶榮分發網絡去分發。這樣一來，在接入核心語音視頻網絡時就需要有智能的調度策略來完成就近接入了。
2.流暢性
流暢性作為直播過程中容易出現較多技術難點的一個方面，需要注意的也有很多。
（1）可以做動態伸縮的jitterbuffer，在網絡狀況差或者是網絡抖動比較劇烈的情況下，可可以適當增大，從而降低延遲來對應出現的網絡抖動情況。
（2）快播和滿播技術在網絡環境較差時，可以在用戶毫無感知的條件下稍微降低播放速度，然後來解決短暫出現的網絡抖動所引起的卡頓情況，當網絡恢復後，還可以快速追趕回來。需要注意的是，這種方式並不適合所有的應用場景。
（3）碼率自適應，也就是說選擇合適的碼率來做動態傳輸。為了保證流暢度可以適當調整分辨率和幀率，當然，語音視頻引擎會根據當前的網絡測速結果和應用需要的碼率，動態調整碼率、幀率和分辨率，以此達到流暢觀看的用戶體驗。
（4）在推流端做一些分層的編碼，這樣一來，在拉流端可以動態的根據偵測到的網絡帶寬情況來拉取不同的數據去做渲染。而分層編碼允許拉流端選擇不同層次的視頻編碼數據，網絡情況好的時候，就選取較多層次的數據，網絡情況差的情況下，就選取基礎層次的數據。
（5）在推拉流端監測當前推拉流質量比較差時，即使通過降低碼率、分辨率和幀率等策也無法保證質量時，可以選擇放棄此鏈路。
3.回聲消除
先簡單介紹一下回聲消除的原理，對端發送的信號會先給到回聲消除的模塊，作為將來消除的參考信號，再將信號給到揚聲器播放，播放後由於周圍環境反射形成回聲，與真實的音頻輸入一同被麥克風採集，這時採集到的輸入信號是帶有回聲的，回聲消除模塊會根據前面的參考信號生成濾波抵消掉會回聲後再發送出去。至於回聲消除的問題，谷歌開源的WebRTC提供了回聲消除模塊，但它本身設計是為了在PC端實現音視頻互動場景，在移動端的適應性較差，尤其是Android端。
4.國內外互通
這一點適用於海外運營的用戶，流媒體數據和控制信令就需要做好跨國互通，所以要考慮在全球合理佈置一些中繼節點。數據路徑的選擇是需要根據業務決定的，也就是說在物理鏈路路由之上還需要再有一條業務的路由表，並且根據用戶的場景制定，比如用戶分佈、訪問頻率或高頻段峰值等。可能每次的路由都會不同。
5.海量併發
這是所有的互聯網相關產品都會遇到的問題，主要考慮負載均衡，如何平滑擴容，對於無法覆蓋的地方要做代理調度，甚至需要考慮容災、接入層的設計等等，再此就不多做贅述。
由此可見，在開發過程中不僅需要優質的一對一語音直播系統源碼作為“輔助”，還需要考慮多方面因素和可能發生的問題，只有這樣才能開發出真正優質的直播app。如若不然，將會在直播領域中就此“銷聲匿跡”。
本文轉載自網絡，感謝（愛吃五花肉嗎）的分享，轉載僅為分享乾貨知識，如有侵權歡迎聯繫雲豹科技進行刪除處理