字節跳動Android面試:直播中 網速比較差的條件下，如何使畫面保證流暢的效果

本專欄專一分享大型Bat面試知識，後續會持續更新，喜歡的話麻煩點擊一個關注

面試官: 直播中 網速比較差的條件下，如何使畫面保證流暢的效果

崗位場景

心理分析：「 網速比較差的條件下，如何使畫面保證流暢的效果」 該問題能夠轉換成一個優化問題。直播技術最難的是優化，接下來咱們從五個方面來進行直播優化

求職者: 遇到優化問題 必定要淡定，一步一步 調理清晰。面試官也不會徹底記得有幾種優化，他只是試探你 看你了不瞭解。若是遇到該問題 說話卡頓 結巴，面試官能夠下定決定 你沒弄過

音視頻的直播系統是一個複雜的工程系統，要作到很是低延遲的直播，須要複雜的系統工程優化和對各組件很是熟悉的掌握。下面整理幾個簡單經常使用的調優技巧：

1 編碼優化

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 進行編碼。

2 傳輸協議優化

1. 在服務端節點和節點之間儘可能使用 RTMP 而非基於 HTTP 的 HLS 協議進行傳輸，這樣能夠下降總體的傳輸延遲。這個主要針對終端用戶使用 HLS 進行播放的狀況。
2. 若是終端用戶使用 RTMP 來播放，儘可能在靠近推流端的收流節點進行轉碼，這樣傳輸的視頻流比原始視頻流更小。
3. 若是有必要，可使用定製的 UDP 協議來替換 TCP 協議，省去弱網環節下的丟包重傳能夠下降延遲。它的主要缺點在於，基於 UDP 協議進行定製的協議的視頻流的傳輸和分發不夠通用，CDN 廠商支持的是標準的傳輸協議。另外一個缺點在於可能出現丟包致使的花屏或者模糊（缺乏關鍵幀的解碼參考），這就要求協議定製方在 UDP 基礎之上作好丟包控制。

3 傳輸網絡優化

1. 咱們曾經介紹過實時流傳輸網絡，它是一種新型的節點自組織的網狀傳輸網絡，既適合國內多運營商網絡條件下的傳輸優化，也適合衆多海外直播的需求。
2. 在服務端節點中緩存當前 GOP，配合播放器端優化視頻首開時間。
3. 服務端實時記錄每一個視頻流流向每一個環節時的秒級幀率和碼率，實時監控碼率和幀率的波動。
4. 客戶端（推流和播放）經過查詢服務端準實時獲取當前最優節點（5 秒一次），準實時下線當前故障節點和線路。

4 推流、播放優化

1. 考察發送端系統自帶的網絡 buffer 大小，系統可能在發送數據以前緩存數據，這個參數的調優也須要找到一個平衡點。
2. 播放端緩存控制對於視頻的首開延遲也有較大影響，若是僅優化首開延遲，能夠在 0 緩存狀況下在數據到達的時候當即解碼。但若是在弱網環境下爲了消除網絡抖動形成的影響，設置必定的緩存也有必要，所以須要在直播的穩定性和首開延遲優化上找到平衡，調整優化緩衝區大小這個值。
3. 播放端動態 buffer 策略，這是上面播放端緩存控制的改進版本。若是隻是作 0 緩存和固定大小的緩存之間進行選擇找到平衡，最終仍是會選擇一個固定大小的緩存，這對億級的移動互聯網終端用戶來講並不公平，他們不一樣的網絡情況決定了這個固定大小的緩存並不徹底合適。所以，咱們能夠考慮一種「動態 buffer 策略」，在播放器開啓的時候採用很是小甚至 0 緩存的策略，經過對下載首片視頻的耗時來決定下一個時間片的緩存大小，同時在播放過程當中實時監測當前網絡，實時調整播放過程當中緩存的大小。這樣便可作到極低的首開時間，又可可以儘可能消除網絡抖動形成的影響。
4. 動態碼率播放策略。除了動態調整 buffer 大小的策略以外，也能夠利用實時監測的網絡信息來動態調整播放過程當中的碼率，在網絡帶寬不足的狀況降低低碼率進行播放，減小延遲。

以上，是低延遲優化方面的部分技巧。實際上咱們優化低延遲的時候並非只關注「低延遲」，而是在保證其它條件不影響用戶體驗的狀況下儘可能作到低延遲，所以它的內容涉及到更多普遍的話題。

更多BATJ字節跳動面試資料，整理了一下+以下視頻教學，更有LiveDataBus.Google官方架構組件.Jetpack架構.餓了麼通訊技術.OPenGL.音視頻.人工智能.Python.性能優化.Flutter等。後續還有最新華爲鴻蒙相關研發。

QQ交流羣：892872246