確保Codec開啟了最低延遲的設置。Codec一般都會有低延遲優化的開關，對于H.264來說其效果尤其明顯。很多人可能不知道H.264的解碼器正常情況下會在顯示之前緩存一定的視頻幀，對于QCIF分辨率大小的視頻（176×144）一般會緩存16幀，對于720P的視頻則緩存5幀。對于第一幀的讀取來說，這是一個很大的延遲。如果你的視頻不是使用H.264來編碼壓縮的，確保沒有使用到B幀，它對延遲也會有較大的影響，因為視頻中B幀的解碼依賴于前后的視頻幀，會增加延遲。

編碼器一般都會有碼控造成的延遲，一般也叫做初始化延遲或者視頻緩存檢驗器VBV的緩存大小，把它當成編碼器和解碼器比特流之間的緩存，在不影響視頻質量的情況下可以將其設置得盡可能小也可以降低延遲。

如果是僅僅優化首開延遲，可以在視頻幀間插入較多的關鍵幀，這樣客戶端收到視頻流之后可以盡快解碼。但如果需要優化傳輸過程中的累計延遲，盡可能少使用關鍵幀也就是I幀（GOP變大），在保證同等視頻質量的情況下，I幀越多，碼率越大，傳輸所需的網絡帶寬越多，也就意味著累計延遲可能越大。這個優化效果可能在秒級延遲的系統中不是很明顯，但是在100ms甚至更低延遲的系統中就會非常明顯。同時，盡量使用ACC-LC Codec來編碼音頻，HE-ACC或者HE-ACC 2雖然編碼效率高，但是編碼所需時間更長，而產生更大體積的音頻造成的傳輸延遲對于視頻流的傳輸來說影響更小。

不要使用視頻MJPEG的視頻壓縮格式，至少使用不帶B幀的MPEG4視頻壓縮格式（Simple profile），甚至最好使用H.264 baseline profile（X264還有一個「-tune zerolatency」的優化開關）。這樣一個簡單的優化可以降低延遲，因為它能夠以更低的碼率編碼全幀率視頻。

如果使用了FFmpeg，降低「-probesize」和「-analyze duration」參數的值，這兩個值用于視頻幀信息監測和用于監測的時長，這兩個值越大對編碼延遲的影響越大，在直播場景下對于視頻流來說analyzeduration參數甚至沒有必要設定。

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

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

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

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

我們曾經介紹過七牛直播云的實時流傳輸網絡，它是一種新型的節點自組織的網狀傳輸網絡，既適合國內多運營商網絡條件下的傳輸優化，也適合眾多海外直播的需求。

在服務端節點中緩存當前GOP，配合播放器端優化視頻首開時間。

服務端實時記錄每個視頻流流向每個環節時的秒級幀率和碼率，實時監控碼率和幀率的波動。

客戶端（推流和播放）通過查詢服務端準實時獲取當前最優節點（5秒一次），準實時下線當前故障節點和線路。

考察發送端系統自帶的網絡buffer大小，系統可能在發送數據之前緩存數據，這個參數的調優也需要找到一個平衡點。

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

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

動態碼率播放策略。除了動態調整buffer大小的策略之外，也可以利用實時監測的網絡信息來動態調整播放過程中的碼率，在網絡帶寬不足的情況下降低碼率進行播放，減少延遲。