**影響音視頻延遲的關鍵因素（一）：流媒體系統**

低延遲的實時音視頻技術應用場景在不斷擴大，從秀場直播、連麥PK直播到在線教育、視頻會議，音視頻技術的落地應用朝着更高清、更低延時發展。下面咱們來看看，構成音視頻低延遲的因素有哪些，如何實現更低延時的實時音視頻？

首先，來看看第一個影響音視頻延遲的關鍵因素：流媒體系統

如下是目前比較流行的媒體傳輸系統的延遲對比：

第一個是HLS，這是蘋果公司提出的一套傳輸協議，它依託於現有的Http框架，加上蘋果強有力的推進，讓它有了普遍的設備支持基礎。但HLS是以切片爲單位傳輸，默認 6s一個切片，播放器爲了保障流暢，會默認緩存3個切片纔開始播放。所以，即時不考慮任何其餘因素，HLS的系統延遲就達到了18S；

在HLS基礎上，基於Http的分塊傳輸編碼，LHLS作了優化，它能夠作到3-7S的延遲。這套方案還在演進，蘋果在去年的WWDC上提出了新的草案，新版草案號稱能夠作到2S，你們能夠期待下。

第二個和第三個是RTMP和HTTP-FLV，這兩個都是Adobe提出的，其實這兩種協議在優化的較好的狀況下是能夠作到比較低延遲的，即構也支持RTMP，咱們的方案能夠作到實驗室狀況下400ms。但它有個硬傷，它的傳輸基於TCP，TCP在有丟包的狀況下沒法作流控，也就是說現實中它的延遲會達到秒級。

第四個就是比較火的WebRTC，在實驗室狀況它能夠作到100ms之內，即構也有作WebRTC的網關，實測的話是300-500ms。

最後一個是即構自研的私有協議，這一套方案在實驗室環境的延遲和WebRTC區別不大，由於只要有好網絡，不少策略都用不上的，可是在有丟包、網絡抖動的狀況下，咱們的表現會優於RTC，感興趣的小夥伴能夠與咱們聯繫獲取實測數據。

咱們所說的延遲是端到端的延遲，那麼按照數據的流動能夠分爲這幾個步驟：採集、前處理、編碼、傳輸、解碼、後處理、渲染。這整套流程的每一個環節都會引入時延，接下來咱們會分享如何針對每一環節去作優化，敬請期待第二篇~