「ApsaraVideo for Live技術詳解」系列之五：延遲最佳化，

「ApsaraVideo for Live技術詳解」系列之五：延遲最佳化，

關於直播的技術文章不少，成體系的不多。我們將用七篇文章，更系統化地介紹當下大熱的ApsaraVideo for Live各環節的關鍵技術，協助ApsaraVideo for Live創業者們更全面、深入地瞭解ApsaraVideo for Live技術，更好地技術選型。

本系列文章大綱如下：

（一）採集

（二）處理

（三）編碼和封裝

（四）推流和傳輸

（五）延遲最佳化

（六）現代播放器原理

（七）SDK 效能測試模型

在上一篇推流和傳輸中，關於「直播的第一公裡」的關鍵因素我們展開了詳細的介紹。本篇是《解密ApsaraVideo for Live技術》系列之五：延遲最佳化。

 

我們在很多線上和線下場合分享了如何最佳化直播體驗，詳細講解了各部分造成低延遲和卡頓的原因和相應的最佳化原理。實際上，音視頻的直播系統是一個複雜的工程系統，要做到非常低延遲的直播，需要複雜的系統工程最佳化和對各組件非常熟悉的掌握。這裡面我們再分享幾個簡單而常用的調優技巧。

編碼最佳化

1. 確保 Codec 開啟了最低延遲的設定。Codec 一般都會有低延遲最佳化的開關，對於 H.264 來說其效果尤其明顯。很多人可能不知道 H.264 的解碼器正常情況下會在顯示之前緩衝一定的視訊框架，對於 QCIF 解析度大小的視頻（176 × 144）一般會緩衝 16 幀，對於 720P 的視頻則緩衝 5 幀。對於第一幀的讀取來說，這是一個很大的延遲。如果你的視頻不是使用 H.264 來編碼壓縮的，確保沒有使用到 B 幀，它對延遲也會有較大的影響，因為視頻中 B 幀的解碼依賴於前後的視訊框架，會增加延遲。

2. 編碼器一般都會有碼控造成的延遲，一般也叫做初始化延遲或者視頻緩衝檢驗器 VBV 的緩衝大小，把它當成編碼器和解碼器位元流之間的緩衝，在不影響視頻品質的情況下可以將其設定得儘可能小也可以降低延遲。

3. 如果是僅僅最佳化首開延遲，可以在視訊框架間插入較多的主要畫面格，這樣用戶端收到視頻流之後可以儘快解碼。但如果需要最佳化傳輸過程中的累計延遲，儘可能少使用主要畫面格也就是 I 幀（GOP 變大），在保證同等視頻品質的情況下，I 幀越多，碼率越大，傳輸所需的網路頻寬越多，也就意味著累計延遲可能越大。這個最佳化效果可能在秒級延遲的系統中不是很明顯，但是在 100 ms 甚至更低延遲的系統中就會非常明顯。同時，盡量使用 AAC-LC Codec 來編碼音頻，HE-AAC 或者 HE-AAC V2 雖然編碼效率高，但是編碼所需時間更長，而產生更大體積的音頻造成的傳輸延遲對於視頻流的傳輸來說影響更小。

4. 不要使用視頻 MJPEG 的視頻壓縮格式，至少使用不帶 B 幀的 MPEG4 視頻壓縮格式（Simple profile），甚至最好使用 H.264 baseline profile（X264 還有一個「-tune zerolatency」的最佳化開關）。這樣一個簡單的最佳化可以降低延遲，因為它能夠以更低的碼率編碼全幀率視頻。

5. 如果使用了 FFmpeg，降低「-probesize 」和「 -analyze duration」參數的值，這兩個值用於視訊框架資訊監測和用於監測的時間長度，這兩個值越大對編碼延遲的影響越大，在直播情境下對於視頻流來說 analyzeduration 參數甚至沒有必要設定。

6. 固定碼率編碼 CBR 可以一定程度上消除網路抖動影響，如果能夠使用可變碼率編碼 VBR 可以節省一些不必要的網路頻寬，降低一定的延遲。因此建議盡量使用 VBR 進行編碼。

傳輸協議最佳化

1. 在服務端節點和節點之間盡量使用 RTMP 而非基於 HTTP 的 HLS 協議進行傳輸，這樣可以降低整體的傳輸延遲。這個主要針對終端使用者使用 HLS 進行播放的情況。

2. 如果終端使用者使用 RTMP 來播放，盡量在靠近推流端的收流節點進行轉碼，這樣傳輸的視頻流比原始視頻流更小。

3. 如果有必要，可以使用定製的 UDP 協議來替換 TCP 協議，省去弱網環節下的丟包重傳可以降低延遲。它的主要缺點在於，基於 UDP 協議進行定製的協議的視頻流的傳輸和分發不夠通用，CDN 廠商支援的是標準的傳輸協議。另一個缺點在於可能出現丟包導致的花屏或者模糊（缺少主要畫面格的解碼參考），這就要求協議定製方在 UDP 基礎之上做好丟包控制。

傳輸網路最佳化

1. 我們曾經介紹過即時資料流傳輸網路，它是一種新型的節點自組織的網狀傳輸網路，既適合國內多電訊廠商網路條件下的傳輸最佳化，也適合眾多海外直播的需求。

2. 在服務端節點中緩衝當前 GOP，配合播放器端最佳化視頻首開時間。

3. 服務端即時記錄每個視頻流流向每個環節時的秒級幀率和碼率，即時監控碼率和幀率的波動。

4. 用戶端（推流和播放）通過查詢服務端准即時擷取當前最優節點（5 秒一次），准即時下線當前故障節點和線路。

推流、播放最佳化

1. 考察發送端系統內建的網路 buffer 大小，系統可能在發送資料之前快取資料，這個參數的調優也需要找到一個平衡點。

2. 播放端緩衝控制對於視頻的首開延遲也有較大影響，如果僅最佳化首開延遲，可以在 0 緩衝情況下在資料到達的時候立即解碼。但如果在弱網環境下為了消除網路抖動造成的影響，設定一定的緩衝也有必要，因此需要在直播的穩定性和首開延遲最佳化上找到平衡，調整最佳化緩衝區大小這個值。

3. 播放端動態 buffer 策略，這是上面播放端緩衝控制的改進版本。如果只是做 0 緩衝和固定大小的緩衝之間進行選擇找到平衡，最終還是會選擇一個固定大小的緩衝，這對億級的移動互連網終端使用者來說並不公平，他們不同的網路狀況決定了這個固定大小的緩衝並不完全合適。因此，我們可以考慮一種「動態 buffer 策略」，在播放器開啟的時候採用非常小甚至 0 緩衝的策略，通過對下載首片視頻的耗時來決定下一個時間片的緩衝大小，同時在播放過程中即時監測當前網路，即時調整播放過程中緩衝的大小。這樣即可做到極低的首開時間，又可能夠盡量消除網路抖動造成的影響。

4. 動態碼率播放策略。除了動態調整 buffer 大小的策略之外，也可以利用即時監測的網路資訊來動態調整播放過程中的碼率，在網路頻寬不足的情況下降低碼率進行播放，減少延遲。

以上，是我們在低延遲最佳化方面的部分技巧。實際上我們最佳化低延遲的時候並不是只關注「低延遲」，而是在保證其它條件不影響使用者體驗的情況下盡量做到低延遲，因此它的內容涉及到更多廣泛的話題。而ApsaraVideo for Live的最佳化也包含方方面面，這裡只分享了其中經過我們實踐的部分。隨著實踐的積累，我們接下來會線上上和線下分享