MeMe影音聊天視訊室七牛雲於 6 月底發布了一個針對視頻直播的實時流網絡 LiveNet 和完整的直播雲解決方案，很多開發者對這個網絡和解決方案的細節和使用場景非常感興趣。
結合七牛實時流網絡 LiveNet 和直播雲解決方案的實踐，我們用八篇文章，更系統化地介紹當下大熱的視頻直播各環節的關鍵技術，幫助視頻直播創業者們更全面、深入地了解視頻直播技術，更好地技術選型。
本系列文章大綱如下：
（六）延遲優化
（七）現代播放器原理
（八）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 大小的策略之外，也可以利用實時監測的網絡信息來動態調整播放過程中的碼率，在網絡帶寬不足的情況下降低碼率進行播放，減少延遲。
以上，是我們在低延遲優化方面的部分技巧。實際上我們優化低延遲的時候並不是只關注「低延遲」，而是在保證其它條件不影響用戶體驗的情況下儘量做到低延遲，因此它的內容涉及到更多廣泛的話題。而視頻直播的優化也包含方方面面，這裡只分享了其中經過我們實踐的部分。隨著實踐的積累，我們接下來會在線上和線下分享更多關於視頻直播甚至點播的優化技巧。
點擊七牛雲公眾號底部菜單「文章精選」即可查看《視頻直播技術詳解》系列歷史文章。
【沒看過癮？直接來上免費公開課】
為了讓大家能夠將技術理論快速應用到實踐開發中，七牛雲聯合慕課網、StuQ 特別製作了一期課程，專門針對移動直播應用開發，供大家學習參考。
慕課網：
StuQ ：
點擊「嬝狎鴗憛v學習《2 小時搞定移動直播 App 開發》
MeMe影音聊天視訊室-《視頻直播技術詳解》系列之六：延遲優化
MeMe影音聊天視訊室七牛雲於 6 月底發布了一個針對視頻直播的實時流網絡 LiveNet 和完整的直播雲解決方案，很多開發者對這個網絡和解決方案的細節和使用場景非常感興趣。
結合七牛實時流網絡 LiveNet 和直播雲解決方案的實踐，我們用八篇文章，更系統化地介紹當下大熱的視頻直播各環節的關鍵技術，幫助視頻直播創業者們更全面、深入地了解視頻直播技術，更好地技術選型。
本系列文章大綱如下：
（六）延遲優化
（七）現代播放器原理
（八）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 大小的策略之外，也可以利用實時監測的網絡信息來動態調整播放過程中的碼率，在網絡帶寬不足的情況下降低碼率進行播放，減少延遲。
以上，是我們在低延遲優化方面的部分技巧。實際上我們優化低延遲的時候並不是只關注「低延遲」，而是在保證其它條件不影響用戶體驗的情況下儘量做到低延遲，因此它的內容涉及到更多廣泛的話題。而視頻直播的優化也包含方方面面，這裡只分享了其中經過我們實踐的部分。隨著實踐的積累，我們接下來會在線上和線下分享更多關於視頻直播甚至點播的優化技巧。
點擊七牛雲公眾號底部菜單「文章精選」即可查看《視頻直播技術詳解》系列歷史文章。
【沒看過癮？直接來上免費公開課】
為了讓大家能夠將技術理論快速應用到實踐開發中，七牛雲聯合慕課網、StuQ 特別製作了一期課程，專門針對移動直播應用開發，供大家學習參考。
慕課網：
StuQ ：
點擊「嬝狎鴗憛v學習《2 小時搞定移動直播 App 開發》