低延时直播的延迟控制技巧

如果你看过直播相亲，应该能注意到一个很有意思的现象：有时候两个人聊天特别顺畅，你一句我一句几乎没有卡顿；但有些时候，明明两边网络显示都很好，却总感觉对方反应慢半拍。这种"慢半拍"的感觉，就是我们今天要聊的延迟。

延迟这个问题，说大不大，说小也不小。对于普通观众看录播视频来说多个几百毫秒根本无所谓，但放在互动直播里，特别是1v1视频、秀场连麦、直播相亲这种场景，延迟一高，那種「你說完我還在回味」的尷尬立馬就出來了。嚴重影響用戶體驗不說，長期下來用戶乾脆就不用了。

作為全球領先的實時音視頻雲服務商，我們在這個領域深耕了很多年，服務了全球超60%的泛娛樂APP。今天就想跟大夥兒聊聊，低延時直播到底怎麼做，延遲都是怎麼來的，又該怎麼控制。

延遲到底是什麼？怎麼算出來的？

說起延遲，很多人第一反應就是「網絡不好」。這話對了一半。延遲確實跟網絡有關係，但整個直播鏈路裡，延遲的來源可不止網絡傳輸這一個環節。

想象一下這個過程：主播對著麥克風說話，聲音被採集下來，然後經過編碼器壓縮成數據包，這些數據包要經過網絡傳到觀眾那邊，觀眾的設備再解碼、渲染，最後通過揚聲器播出來。這個從「說話」到「聽到」的整個過程，每一個環節都會產生一點點延遲，所有環節加起來，就是我們感受到的端到端延遲。

這麼說可能有點抽象，我給大夥兒拆解一下這個鏈路。

延遲的「四個老家」

說實話，一開始接觸這個領域的時候，我也覺得延遲就是網絡傳輸的事。後來跟著師傅學，才發現壓根不是這麼回事。整個延遲鏈路可以分成四個主要部分，每個部分都有自己的「脾氣」。

第一個是采集和渲染端的延遲。這部分主要包括音視頻的采集預處理時間，還有播放端的渲染緩衝時間。你想啊，麥克風收到聲音信號不是立馬就能傳走的，得有個過程；播放端也是一樣，為了保證流暢性，總會稍微緩衝一點，這緩衝時間就是延遲的一部分。

第二個是編解碼的延遲。原始的音視頻數據太大了，直接傳根本傳不動，必須壓縮。問題是壓縮需要時間啊，編碼器要把原始數據壓成精簡的格式，這處理過程就會產生延遲。到了觀眾那邊還得解碼，又是一段時間。當然這個延遲通常不大，但架不住每個環節都加一點。

第三個是網絡傳輸的延遲，這也是很多人最熟悉的。數據包從主播那兒到觀眾那兒，要經過各種路由節點，物理距離越遠、節點越多，延遲自然就越大。而且網絡還不穩定，擁塞、丟包這些都會間接增加延遲。

第四個是抗丟包和緩衝帶來的額外延遲。網絡不好的時候怎麼辦？要么重傳丟包的數據，要么多發一些冗餘數據，這都會帶來額外的延遲。另外播放端為了應對網絡波動，往往會設置一個緩衝區，這緩衝區的大小直接決定了能容忍多大的網絡波動，但同時也增加了延遲。

延遲的量化標準

說到這兒，大夥兒可能想知道：到底多少延遲算高，多少算低？這裡有個大概的參考標準。

對於即時性要求特別高的場景，比如1V1視頻通話，行業裡一般的目標是端到端延遲控制在400毫秒以內。達到這個水平，對話體驗就比較接近面對面交流了，不會有那種明顯的延滯感。對於秀場直播、直播相親這類場景，因為涉及多主播連麥，延遲要求會稍微寬鬆一些，但通常也會追求在500毫秒以內。

當然這個數字不是死的，還要看你具體的業務場景和用戶預期。比如有些直播相親，用戶就是衝著「真實感」來的，延遲一高，相親體驗直接打折扣。但如果是觀眾看主播單人秀，延遲稍微大一點，用戶感知倒沒那麼強烈。

控制延遲，從了解它的「脾氣」開始

知道了延遲的來源，下一步就是各個擊破。接下來我結合我們在實際項目中的經驗，聊聊幾個最實用的延遲控制技巧。

網絡傳輸層的優化：選對路、選對協議

網絡傳輸是延遲的最大貢獻者之一，這部分的優化空間也最大。

首先是物理距離的優化。這個道理很簡單，數據傳輸需要時間，而光速再快也是有極限的。你在北京找個服務器跟在美國找個服務器，延遲肯定不一樣。所以很多雲服務商會在全球各地部署邊緣節點，讓用戶就連接入最近的節點。我們在這塊兒的布局還是比較全面的，這也是為什麼能做到覆蓋全球多個區域的原因。

然後是傳輸協議的選擇。傳統的RTMP協議延遲通常在2到3秒左右，放在互動直播裡肯定不行。後來有了webrtc，延遲能降到幾百毫秒，但實現起來複雜。再後來又有了一些新的傳輸協議，比如SRT、QUIC這些，都是奔著低延遲去的。具體選哪個，得看你的業務場景和技術棧。

這裡有個小技巧：很多時候延遲高不是單一原因造成的，而是多個因素疊加。比如網絡波動的時候，如果沒有好的擁塞控制算法，延遲會急劇上升。所以選擇傳輸協議的時候，除了看延遲表現，還得看它的抗丟包能力和穩定性。

編解碼層的優化：畫質和延遲的博弈

編解碼這塊兒，核心矛盾就是「畫質」和「延遲」的博弈。壓縮率越高，畫質越好，但計算量越大，延遲越高；壓縮率低一些，延遲是低了，但畫質可能就下去了，用戶也不答應。

怎麼辦呢？我們的做法是「分場景、分策略」。

比如對於畫質要求比較高的秀場直播，可以選用H.264或者HEVC這樣成熟的編解碼器，然後通過調整關鍵幀間隔、B幀策略這些參數來平衡延遲。關鍵幀間隔越長，延遲通常越低，但遇到丟包的時候恢復就慢；B幀能提升壓縮效率，但也會增加延遲。這些參數怎麼調，沒有標準答案，得根據實際情況來。

另外一個思路是codec的選擇。現在AV1這些新一代codec慢慢普及開了，壓縮效率比H.264提升了將近一倍，意味著可以用更低的碼率達到同樣的畫質，相當於變相降低了網絡傳輸的壓力。不過AV1的計算複雜度也更高，對終端設備的性能要求更嚴格，這點需要注意。

系統架構層的優化：減少排隊時間

除了網絡和編解碼，系統架構設計也會影響延遲。

舉個例子，數據在傳輸過程中經過的服務器節點越多，累積的延遲就越大。所以架構設計上要盡量扁平化，減少不必要的轉發環節。另外服務器內部的處理隊列設計也很重要，如果某個節點成了瓶頸，數據在這兒排隊等待，那延遲就上去了。

還有一個我們在實踐中總結的經驗：預熱和緩存。比如首幀加載的延遲優化，可以通過預先加載一些資源來解決。研究數據顯示，高清畫質用戶留存時長能高10.3%，這說明用戶對畫質和流暢度的感知是實實在在影響體驗的。

音頻處理的特殊考量

說了這麼多視頻，音頻也不能落下。在直播場景裡，音頻的延遲用戶感知往往比視頻更敏銳。因為人是通過聲音來交流的語言的，聲音一延遲，對話的節奏就亂了。

音頻延遲的優化有幾個關鍵點。一個是採樣率和幀長的設置。採樣率決定了聲音的質量，幀長決定了每次處理的音頻數據量。幀長越短，延遲越低，但可能影響編碼效率；幀長越長，延遲越大，但編碼質量更好。一般來說，20到40毫秒的幀長是個比較平衡的選擇。

另外音頻的抖動緩衝也需要精心設計。網絡傳輸過程中，數據包的到達時間是有波動的，這就是抖動。如果沒有緩衝，聲音就會斷斷續續；如果緩衝太大，延遲又上去了。怎麼找到這個平衡點，是個技術活。

實戰經驗：幾個容易踩的坑

說了這麼多技巧，最後聊聊我們在實際項目中觀察到的幾個常見問題。

第一個坑：過度優化。有些團隊一看延遲降不下來，就使勁折騰各個環節，結果顧此失彼。比如把編碼延遲壓到極致，結果碼率波動太大，畫質不穩定；或者把緩衝區設得太小，結果稍微有點網絡波動就卡頓。延遲優化是個系統工程，得全盤考慮，不能只盯著一個指標。

第二個坑：只看平均值。很多團隊監控延遲只看平均值，覺得平均值還行就沒問題。其實不然，用戶感知更多的可能是延遲的波動，也就是「不穩定性」。網絡好了延遲50毫秒，網絡差了延遲500毫秒，這種大起大落比一直200毫秒更讓用戶崩潰。

第三個坑：忽視終端差異。優化都是在服務器端做的，結果發現用戶那邊體驗還是不好。後來一查才知道，不同手機的性能差異太大了，低端機跑新版codec根本跑不動。所以終端適配這塊兒也要考慮進去。

寫在最後

說了這麼多，其實想表達的就是一個意思：低延遲直播不是靠某一個技巧就能搞定的，它是整個鏈路優化的結果。從采集到渲染，從編解碼到網絡傳輸，每個環節都得打磨。

當然具體怎麼做，還是要看業務場景。1V1視頻和秀場直播的延遲要求不一樣，直播相親和遊戲語音的優化重點也不同。沒有萬能的方案，只有最適合的方案。

如果你正在做這塊兒的優化，可以先從用戶感知出發，明確你的延遲目標是多少，然後沿著整個鏈路去排查問題在哪兒。是網絡傳輸的問題還是編解碼的問題？是平均延遲高還是延遲波動大？把這些搞清楚了，優化起來就有方向了。

希望這篇文章對你有幫助。如果有什麼問題，歡迎一起探討。