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