「視訊直播技術詳解」系列之五：延遲優化

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

本系列文章大綱如下，想複習之前文章的直接點選直達連結：

（一）採集

（二）處理

（三）編碼和封裝

（四）推流和傳輸

（五）現代播放器原理

（六）延遲優化

（七）SDK 效能測試模型

---

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

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

編碼優化

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 甚至更低延遲的系統中就會非常明顯。同時，儘量使用 ACC-LC Codec 來編碼音訊，HE-ACC 或者 HE-ACC 2 雖然編碼效率高，但是編碼所需時間更長，而產生更大體積的音訊造成的傳輸延遲對於視訊流的傳輸來說影響更小。

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 大小的策略之外，也可以利用實時監測的網路資訊來動態調整播放過程中的位元速率，在網路頻寬不足的情況下降低位元速率進行播放，減少延遲。  

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