七牛云于 6 月底宣布了一個針對視頻直播的及時流網(wǎng)絡(luò) LiveNet 和完整的直播云辦理方案，許多開拓者對這個網(wǎng)絡(luò)息爭決方案的細(xì)節(jié)和利用場景很是感樂趣。

團(tuán)結(jié)七牛及時流網(wǎng)絡(luò) LiveNet 和直播云辦理方案的實踐，我們用八篇文章，更系統(tǒng)化地先容當(dāng)下大熱的視頻直播各環(huán)節(jié)的要害技能，輔佐視頻直播創(chuàng)業(yè)者們更全面、深入地相識視頻直播技能，更好地技能選型。

本系列文章綱要如下：

(一)開篇

(二)收羅

(三)處理懲罰

(四)編碼和封裝

(五)推流和傳輸

(六)延遲優(yōu)化

(七)現(xiàn)代播放器道理

(八)SDK 機(jī)能測試模子

在上一篇推流和傳輸中，關(guān)于「直播的第一公里」的要害因素我們展開了具體的先容。本篇是《解密視頻直播技能》系列之六：延遲優(yōu)化。

我們在許多線上和線下場所分享了如何優(yōu)化直播體驗，具體講授了各部門造成低延遲和卡頓的原因和相應(yīng)的優(yōu)化道理。實際上，音視頻的直播系統(tǒng)是一個巨大的工程系統(tǒng)，要做到很是低延遲的直播，需要巨大的系統(tǒng)工程優(yōu)化和對各組件很是熟悉的把握。這內(nèi)里我們再分享幾個簡樸而常用的調(diào)優(yōu)能力。

編碼優(yōu)化

1. 確保 Codec 開啟了最低延遲的配置。Codec 一般城市有低延遲優(yōu)化的開關(guān)，對付 H.264 來說其結(jié)果尤其明明。許多人大概不知道 H.264 的解碼器正常環(huán)境下會在顯示之前緩存必然的視頻幀，對付 QCIF 判別率巨細(xì)的視頻(176 × 144)一般會緩存 16 幀，對付 720P 的視頻則緩存 5 幀。對付第一幀的讀取來說，這是一個很大的延遲。假如你的視頻不是利用 H.264 來編碼壓縮的，確保沒有利用到 B 幀，它對延遲也會有較大的影響，因為視頻中 B 幀的解碼依賴于前后的視頻幀，會增加延遲。

2. 編碼器一般城市有碼控造成的延遲，directadmin安裝 directadmin漢化，一般也叫做初始化延遲可能視頻緩存檢討器 VBV 的緩存巨細(xì)，把它當(dāng)成編碼器息爭碼器比特流之間的緩存，在不影響視頻質(zhì)量的環(huán)境下可以將其配置得盡大概小也可以低落延遲。

3. 假如是僅僅優(yōu)化首開延遲，可以在視頻幀間插入較多的要害幀，這樣客戶端收到視頻流之后可以盡快解碼。但假如需要優(yōu)化傳輸進(jìn)程中的累計延遲，盡大概少利用要害幀也就是 I 幀(GOP 變大)，在擔(dān)保同等視頻質(zhì)量的環(huán)境下，I 幀越多，碼率越大，傳輸所需的網(wǎng)絡(luò)帶寬越多，也就意味著累計延遲大概越大。這個優(yōu)化結(jié)果大概在秒級延遲的系統(tǒng)中不是很明明，可是在 100 ms 甚至更低延遲的系統(tǒng)中就會很是明明。同時，只管利用 ACC-LC Codec 來編碼音頻，HE-ACC 可能 HE-ACC 2 固然編碼效率高，可是編碼所需時間更長，而發(fā)生更概略積的音頻造成的傳輸延遲對付視頻流的傳輸來說影響更小。

4. 不要利用視頻 MJPEG 的視頻壓縮名目，至少利用不帶 B 幀的 MPEG4 視頻壓縮名目(Simple profile)，甚至最好利用 H.264 baseline profile(X264 尚有一個「-tune zerolatency」的優(yōu)化開關(guān))。這樣一個簡樸的優(yōu)化可以低落延遲，因為它可以或許以更低的碼率編碼全幀率視頻。

5. 假如利用了 FFmpeg，低落「-probesize 」和「 -analyze duration」參數(shù)的值，這兩個值用于視頻幀信息監(jiān)測和用于監(jiān)測的時長，這兩個值越大對編碼延遲的影響越大，在直播場景下對付視頻流來說 analyzeduration 參數(shù)甚至沒有須要設(shè)定。

6. 牢靠碼率編碼 CBR 可以必然水平上消除網(wǎng)絡(luò)發(fā)抖影響，假如可以或許利用可變碼率編碼 VBR 可以節(jié)減一些不須要的網(wǎng)絡(luò)帶寬，低落必然的延遲。因此發(fā)起只管利用 VBR 舉辦編碼。

傳輸協(xié)議優(yōu)化

1. 在處事端節(jié)點和節(jié)點之間只管利用 RTMP 而非基于 HTTP 的 HLS 協(xié)議舉辦傳輸，這樣可以低落整體的傳輸延遲。這個主要針對終端用戶利用 HLS 舉辦播放的環(huán)境。

2. 假如終端用戶利用 RTMP 來播放，只管在接近推流端的收流節(jié)點舉辦轉(zhuǎn)碼，這樣傳輸?shù)囊曨l流比原始視頻流更小。

3. 假如有須要，可以利用定制的 UDP 協(xié)議來替換 TCP 協(xié)議，省去弱網(wǎng)環(huán)節(jié)下的丟包重傳可以低落延遲。它的主要缺點在于，基于 UDP 協(xié)議舉辦定制的協(xié)議的視頻流的傳輸和分發(fā)不足通用，CDN 廠商支持的是尺度的傳輸協(xié)議。另一個缺點在于大概呈現(xiàn)丟包導(dǎo)致的花屏可能恍惚(缺少要害幀的解碼參考)，這就要求協(xié)議定制方在 UDP 基本之上做好丟包節(jié)制。

傳輸網(wǎng)絡(luò)優(yōu)化

1. 我們曾經(jīng)先容過七牛直播云的及時傳播輸網(wǎng)絡(luò)，它是一種新型的節(jié)點自組織的網(wǎng)狀傳輸網(wǎng)絡(luò)，既適合海內(nèi)多運營商網(wǎng)絡(luò)條件下的傳輸優(yōu)化，也適合浩瀚外洋直播的需求。

2. 在處事端節(jié)點中緩存當(dāng)前 GOP，共同播放器端優(yōu)化視頻首開時間。

3. 處事端及時記錄每個視頻流流向每個環(huán)節(jié)時的秒級幀率和碼率，及時監(jiān)控碼率和幀率的顛簸。

4. 客戶端(推流和播放)通過查詢處事端準(zhǔn)及時獲取當(dāng)前最優(yōu)節(jié)點(5 秒一次)，準(zhǔn)及時下線當(dāng)前妨礙節(jié)點和線路。

推流、播放優(yōu)化

1. 考查發(fā)送端系統(tǒng)自帶的網(wǎng)絡(luò) buffer 巨細(xì)，系統(tǒng)大概在發(fā)送數(shù)據(jù)之前緩存數(shù)據(jù)，這個參數(shù)的調(diào)優(yōu)也需要找到一個均衡點。