上篇［2］我們講述了直播應用層協議及傳輸層協議的選擇以及對直播體驗影響的分析 。
本篇中我們將介紹在傳輸直播流媒體過程中的內容緩存與傳輸策略優化細節原理。
基礎知識：I幀、B幀、P幀 I幀表示關鍵幀。你可以理解為這一幀畫面的完整保留；解碼時只需要本幀數據就可以完成。（因為包含完整畫面） P幀表示這一幀跟之前的一個關鍵幀（或P幀）的差別。解碼時需要用之前緩存的畫面疊加上本幀定義的差別，生成最終畫面。（也就是差別幀，P幀沒有完整畫面數據，只有與前一幀的畫面差別的數據） B幀是雙向差別幀。B幀記錄的是本幀與前后幀的差別（具體比較復雜，有4種情況）。換言之，要解碼B幀，不僅要取得之前的緩存畫面，還要解碼之后的畫面，通過前后畫面的與本幀數據的疊加取得最終的畫面。 B幀壓縮率高，但是編解碼時會比較耗費CPU，而且在直播中可能會增加直播延時，因此在移動端上一般不使用B幀。
關鍵幀緩存策略
關鍵幀緩存策略
一個典型的視頻幀序列為IBBPBBPBBP…… 對於直播而言，為了減少直播的延時，通常在編碼時不使用B幀。P幀B幀對於I幀都有直接或者間接的依賴關系，所以播放器要解碼一個視頻幀序列，並進行播放，必須首先解碼出I幀，其后續的B幀和P幀才能進行解碼，這樣服務端如何進行關鍵幀的緩存，則對直播的延時以及其他方面有非常大的影響。 比較好的策略是服務端自動判斷關鍵幀的間隔，按業務需求緩存幀序列，保證在緩存中存儲至少兩個或者以上的關鍵幀，以應對低延時、防卡頓、智能丟包等需求。
延遲與卡頓的折中
直播的延時與卡頓是分析直播業務質量時，非常關注的兩項指標。
互動直播的場景對延時非常敏感，新聞體育類直播則更加關注播放的流暢度。
然而，這兩項指標從理論上來說，是一對矛盾的關系——需要更低的延時，則表明服務器端和播放端的緩沖區都必須更短，來自網絡的異常抖動容易引起卡頓；業務可以接受較高的延時時，服務端和播放端都可以有較長的緩沖區，以應對來自網絡的抖動，提供更流暢的直播體驗。 當然，對於網絡條件非常好的用戶，這兩項是可以同時保證的，這里主要是針對網絡條件不是那么好的用戶，如何解決延時與卡頓的問題。
這里通常有兩種技術來平衡和優化這兩個指標：
一是服務端提供靈活的配置策略，對於延時要求更敏感的，則在服務端在保證關鍵幀的情況下，對每個連接維持一個較小的緩沖隊列；對於卡頓要求更高的直播，則適當增加緩沖隊列的長度，保證播放的流暢。
二是服務端對所有連接的網絡情況進行智能檢測，當網絡狀況良好時，服務端會縮小該連接的緩沖隊列的大小，降低延遲；而當網絡狀況較差時，特別是檢測到抖動較為明顯時，服務端對該連接增加緩沖隊列長度，優先保證播放的流暢性。
丟包策略
什么時候需要丟包呢？ 對於一個網絡連接很好，延時也比較小的連接，丟包策略永遠沒有用武之地的。而網絡連接比較差的用戶，因為下載速度比較慢或者抖動比較大，這個用戶的延時就會越來越高。 另外一種情況是，如果直播流關鍵幀間隔比較長，那么在保證首包是關鍵幀的情況下，觀看這個節目的觀眾，延遲有可能會達到一個關鍵幀序列的長度。上述兩種情況，都需要啟用丟包策略，來調整播放的延時。
關於丟包，需要解決兩個問題： 一是正確判斷何時需要進行丟包； 二是如何丟包以使得對觀眾的播放體驗影響最小。
較好的做法是后端周期監控所有連接的緩沖隊列的長度，這樣隊列長度與時間形成一個離散的函數關系，后端通過自研算法來分析這個離散函數，判斷是否需要丟包。 一般的丟幀策略，就是直接丟棄一個完整的視頻幀序列，這種策略看似簡單，但對用戶播放的影響體驗非常大。而應該是后台采用逐步丟幀的策略，每個視頻幀序列，丟最后的一到兩幀，使得用戶的感知最小，平滑的逐步縮小延時的效果。
以上就是UCloud直播雲：內容緩存與傳輸策略優化細節原理。關於接入網絡優化、直播協議選擇、終端優化，請參閱已發布或將發布的其他部分。
預告 前面介紹了直播后端系統的原理及優化，那么直播推流、播放端是否有可以優化的點呢？ 答案是肯定的，客戶端的優化對直播秒開、延遲體驗的實現至關重要，請關注的《關於直播，所有的技術細節都在這里了（四）》，我們將帶來客戶端優化的技術細節。