如何在直播中解決黑屏、花屏、閃屏問題 | 直播疑難雜症排查

 

本文是 《直播疑難雜症排查》系列的第七篇文章，咱們來重點看看直播中常見的各類黑屏、花屏、閃屏問題。

首先咱們要明白，黑屏、花屏、閃屏等問題，多是推流端的問題，也多是播放器的問題，遇到這些現象，咱們要第一時間用別的播放器（如 VLC，ffplay）試試，若是都出現一樣的問題，那麼多半是流自己的問題了，反之，則極可能是播放器的問題。

 

播放黑屏

現象：畫面是黑的，沒有圖像，可是有聲音。

 

1.主播端攝像頭權限問題

不管 Android 仍是 iOS，App 使用攝像頭都是須要申請受權的，特別是 Android 6.0 之後，若是 App 層面不作專門的處理的話，極可能出現攝像頭權限被禁用的狀況。

若是 App 沒有獲取到攝像頭權限，視頻就沒法採集成功，從而致使推出來的流只有音頻數據。

解決方案：App 層面確定要當心處理權限問題，檢測到未獲取相應權限則禁止開播，或者反覆提示主播授予權限。另外，能夠詢問出現問題的主播是否有攝像頭預覽畫面，若是 App 沒有得到權限的話，是沒有預覽畫面的。

 

2.主播端編碼失敗

視頻數據採集到後，下一步就是通過編碼器，因爲參數配置或者某些機型的硬編兼容性問題，極可能數據送入編碼器後，編碼失敗，並沒有輸出，從而致使沒有視頻數據送入到推流模塊。

解決方案：通常推流 SDK 都會統計推流的實時視頻幀率，CDN 服務端也會有一些幀率監控，所以，若是發現這些統計獲得的推流幀率爲 0，同時又肯定不是沒有采集到數據，那麼多半是編碼器的緣由，能夠想辦法查看下該機型的日誌看看具體的報錯信息。

 

3.視頻解碼失敗

前面的文章有提到過，當播放器遇到不支持的視頻格式，或者數據內容/格式異常，則會解碼失敗，從而致使無解碼視頻輸出。

針對不支持的格式：

• 要提早了解播放器自己支持哪些音視頻格式，如 H.264，mp4v，aac 等等，避免播放不支持的格式

• 播放器自己遇到的硬解或者軟解失敗，應該有日誌報錯，或者拋出異常給應用層提示用戶

針對視頻數據內容錯誤：

須要分析碼流文件自己，常見的數據內容錯誤致使的解碼失敗有以下幾種：

• 送入解碼器的幀數據不完整

• H.264 的視頻碼流，缺失了 SPS，PPS 等必要的信息頭

• iOS 的 VideoToolbox 解碼，只支持 avcc 方式打包的 H.264 數據

• 部分 Android 機型硬編出來的數據有額外的 naul 頭

• 其餘等等

 

4.碼流的前半段只有音頻沒有視頻

這種狀況，多半出自 HLS 切片產生的碼流，當主播用同一個地址推流，前半段只推了音頻（多是攝像頭權限被禁用，也多是選擇了純音頻推流等等），而後接着又同時推了音視頻流，那麼，服務端 HLS 切片產生的文件，就會出現這樣的狀況。

基於 ffmpeg 的播放器，會在解析完視頻頭後初始化解碼器，所以，對於這種碼流，每每會出現僅有音頻或者僅有視頻播放的狀況。

解決方案：從 App 端儘量避免出現這種使用姿式，修改播放器的代碼，對這種碼流進行兼容處理。

 

播放花屏/綠屏

現象：播放畫面出現圖像紊亂，大面積的異常顏色的方塊圖，或者綠屏現象

 

1.丟失參考幀致使的

通常 H.264 碼流有 I、B、P 三種幀類型，I 幀是關鍵幀，B 幀是雙向預測內插編碼幀，P 幀是前向預測編碼幀。 

I 幀因爲是幀內壓縮，所以能夠獨立解碼播放，而 B 幀，一旦丟失了 I 幀或者後面的 P 幀，則會解碼失敗，而 P 幀一旦丟失了前面的 I/B/P 幀，也會致使解碼失敗。

對於丟失了參考幀而致使的解碼失敗，通常就會出現花屏的現象，花屏的嚴重程度依賴於丟失的參考幀對即將解碼的幀的重要程度。

那麼，什麼狀況下會丟失參考幀呢 ？

首先，推流/播放的代碼層面，須要注意，不要丟棄編碼後、解碼前的視頻幀數據，不過實際場景中，遇到下面的狀況，不免仍是會產生丟幀：

• 網絡很差，編碼後的數據發不出去

• 系統低內存，隊列裏面沒法承受更多的幀數據

所以，在這些極端的狀況下，不得不丟幀的話，最合理的策略就應該是一次丟一整個 GOP，即：一旦開始丟了一個 I 幀，那麼在遇到下一個 I 幀以前的全部視頻幀，均丟棄掉，這樣便可有效避免播放器端產生解碼花屏。

 

2.播放器沒有從關鍵幀開始解碼

原理依然如上面所述，若是不從關鍵幀開始解碼，則必然會因爲丟失了參考信息而致使解碼花屏。

所以，播放器，不管是首播，仍是斷網重連後，都應該判斷第一幀視頻是不是關鍵幀，若是不是，則應該等到第一個關鍵幀到達以後再送入解碼器。

基於 ffmpeg 的播放器，如何判斷關鍵幀，能夠參考文章：《FFMPEG Tips (3) 如何讀取每一幀的信息》

 

3.碼流中視頻尺寸發生變化

不少直播 App，橫屏直播和豎屏直播，使用的是不一樣的推流尺寸 ，當主播由豎屏推流改成橫屏推流，同時又不改變推流地址的話，觀衆端拉到的流就會出現中間發生了視頻尺寸的變化，好比：從 848 x 480 變成了 1280 x 720 等等。

播放器須要實時檢測，若是發現視頻尺寸發生了變化，則須要重置解碼器以及相關邏輯，不然容易出現解碼花屏或者出現內存越界等異常。

 

4.硬編硬解的兼容性問題

固然，若是使用的是 Android 硬編硬解，則不免會遇到一些比較坑爹的手機，硬編硬解沒有失敗報錯，可是輸出的圖像確實異常的狀況。

Android 硬編硬解的兼容性問題，代碼上當心仔細，充分考慮機型的兼容性，不輕易寫死任何參數，剩下能作的就是靠白名單/黑名單了。

 

5.推流端圖像尺寸和格式處理不當

圖像的格式和尺寸，都是很是重要的參數，必定要嚴格配置正確。

好比：若是採集到的視頻是 NV21 ，編碼器只支持 I420，那麼編碼出來的圖像天然會出現顏色問題。

好比：在一些場景切換的過程當中，先後攝像頭切換，視頻的尺寸可能發生了變化，可是剪裁、處理、編碼模塊沒有相應的修改尺寸，那麼，也會出現各類視頻錯亂的現象。

 

播放閃屏

閃屏問題，從根源來看，就是播放的過程當中，出現了兩種不一樣的畫面來回切換，從而看起來像 「閃屏」，好比，黑白兩張圖片交替渲染。下面咱們再來看看直播場景下，什麼緣由會引起該現象。

1.播放器緩衝機制緣由

網絡很差的時候，播放器會頻繁緩衝，曾遇到過一種案例，就是某直播 App 應用，在緩衝的時候，使用了一張廣告圖片，在某種極端弱網狀況下，因爲頻繁緩衝，致使真實的播放畫面和廣告圖片來回快速切換，致使閃屏現象。

這個狀況是徹底能夠從播放器的緩衝策略上避免的，每次緩衝後，不要收到一幀後就當即渲染，而是適當地多緩衝一些數據，再發送緩衝結束的消息，從而能夠頻繁 ms 級別的緩衝切換產生的閃屏。

 

2.推流端的緣由

推流端產生閃屏的流，每每發生在有畫面合成的代碼模塊，好比：疊加水印、攝像頭/圖片切換推流、連麥合流等等。

畫面的合成，必定要銘記一點，任何狀況下，都要避免出現，有合成/沒有合成兩種畫面的交替。

 

---

推薦閱讀：

• 播放失敗

• 直播卡頓

• 首開慢

• 延時高

• 音畫不一樣步

• 馬賽克嚴重