實際上，音視訊的直播系統是一個複雜的工程系統，要做到非常低延遲的直播，需要複雜的系統工程優化和對各元件非常熟悉的掌握。


編碼優化

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 雖然編碼效率高，但是編碼所需時間更長，而產生更大體積的音訊造成的傳輸延遲對於視訊流的傳輸來說影響更小。

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

傳輸協議優化

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

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

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

推流、播放優化

1、考察傳送端系統自帶的網路 buffer 大小，系統可能在傳送資料之前快取資料，這個引數的調優也需要找到一個平衡點。

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

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

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