基於上篇文章說到影響直播效能指標的因素，下面來講講如何解決優化（理論篇）。

一、低端裝置如何上高效能地採集和編碼？

攝像頭採集輸出的是圖片，一張圖的體積並不會小，如果採集的頻次很高，編碼的幀率很高，每張圖都經過編碼器，那麼編碼器又可能會出現過載。

這個時候，可以考慮在編碼前，不影響畫質的前提下（前面我們講過幀率的微觀意義），進行選擇性丟幀，以此降低編碼環節的功耗開銷。

網路不穩定時，需要支援動態改變位元速率，即在推流端，可檢測網路狀態和簡單測速，動態來切換位元速率，以保障網路切換時的推流流暢。

其次編碼、封包、推流 這一部分的邏輯也可以做微調，可以嘗試選擇性丟幀，比如優先丟視訊參考幀（不丟 I 幀和音訊幀 )，這樣也可以減少要傳輸的資料內容，但同時又達到了不影響畫質和版視聽流暢的目的。

三、如何優化開啟速度，達到傳說中的 “秒開”？

大家在平時觀看直播的時候可能會有所體會，為什麼某些直播開啟的速度非常快，一點就開；而某些直播點選播放後要等待幾秒後才能開始播放，是什麼原因導致的呢？？

大部分播放器都是拿到一個完成的 GOP 後才能解碼播放，基於 FFmpeg 移植的播放器甚至需要等待音畫時間戳同步後才能播放（如果一個直播裡邊沒有音訊只有視訊相當於要等待音訊超時後才能播放畫面）。

“秒開”可以從以下幾個方面考慮：

1. 改寫播放器邏輯讓播放器拿到第一個關鍵幀後就給予顯示。

GOP 的第一幀通常都是關鍵幀，由於載入的資料較少，可以達到 “首幀秒開”。

2. 如果直播伺服器支援 GOP 快取，意味著播放器在和伺服器建立連線後可立即拿到資料，從而省卻跨地域和跨運營商的回源傳輸時間。

3. GOP 體現了關鍵幀的週期，也就是兩個關鍵幀之間的距離，即一個幀組的最大幀數。假設一個視訊的恆定幀率是 24fps（即1秒24幀影象），關鍵幀週期為 2s，那麼一個 GOP 就是 48 張影象。一般而言，每一秒視訊至少需要使用一個關鍵幀。

增加關鍵幀個數可改善畫質（GOP 通常為 FPS 的倍數），但是同時增加了頻寬和網路負載。這意味著，客戶端播放器下載一個 GOP，畢竟該 GOP 存在一定的資料體積，如果播放端網路不佳，有可能不是能夠快速在秒級以內下載完該 GOP，進而影響觀感體驗。

4. 如果不能更改播放器行為邏輯為首幀秒開，直播伺服器也可以做一些取巧處理，比如從快取 GOP 改成快取雙關鍵幀

四、如何保障直播持續播放流暢不卡頓？

“秒開”解決的是直播首次載入的播放體驗，如何保障直播持續播放過程中的畫面和聲音視聽流暢呢？因為，一個直播畢竟不是一個 HTTP 一樣的一次性請求，而是一個 Socket 層面的長連線維持，直到直到主播主動終止推流。

上述我們講過卡頓的定義：即播放時畫面滯幀，觸發了人們的視覺感受。在不考慮終端裝置效能差異的情況下，針對網路傳輸層面的原因，我們看看如何保障一個持續的直播不卡頓。

這其實是一個直播過程中傳輸網路不可靠時的容錯問題。例如，播放端臨時斷網了，但又快速恢復了，針對這種場景，播放端如果不做容錯處理，很難不出現黑屏或是重新載入播放的現象。

為了容忍這種網路錯誤，並達到讓終端使用者無感知，客戶端播放器可以考慮構建一個FIFO（先進先出）的緩衝佇列，解碼器從播放快取佇列讀取資料，快取佇列從直播伺服器源源不斷的下載資料。通常，快取佇列的容量是以時間為單位（比如3s），在播放端網路不可靠時，客戶端快取區可以起到“斷網無感”的過渡作用。

顯然，這只是一個“緩兵之計”，如果直播伺服器邊緣節點出現故障，而此時客戶端播放器又是長連線，在無法收到對端的連線斷開訊號，客戶端的緩衝區容量再大也不管用了，這個時候就需要結合客戶端業務邏輯來做排程。

重要的是客戶端結合服務端，可以做精準排程。在初始化直播推流之前，例如基於 IP 地理位置和運營商的精確排程，分配線路質量最優的邊緣接入節點。在直播推流的過程中，可以實時監測幀率反饋等質量資料，基於直播流的質量動態調整線路。（CDN加速服務）