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

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

本系列文章大綱以下：

（一）採集

（二）處理

（三）編碼和封裝

（四）推流和傳輸

（五）延遲優化

（六）現代播放器原理

（七）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 甚至更低延遲的系統中就會很是明顯。同時，儘可能使用 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 大小的策略以外，也能夠利用實時監測的網絡信息來動態調整播放過程當中的碼率，在網絡帶寬不足的狀況降低低碼率進行播放，減小延遲。

以上，是咱們在低延遲優化方面的部分技巧。實際上咱們優化低延遲的時候並非只關注「低延遲」，而是在保證其它條件不影響用戶體驗的狀況下儘可能作到低延遲，所以它的內容涉及到更多普遍的話題。而視頻直播的優化也包含方方面面，這裏只分享了其中通過咱們實踐的部分。隨着實踐的積累，咱們接下來會在線上和線下分享更多關於視頻直播甚至點播的優化技巧。

 

本文做者： 何李石@七牛雲佈道師，更多雲行業技術洞見請訪問七牛雲博客。