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

七牛雲發表於2017-06-05

「黑屏、花屏、閃屏」經常出現在直播應用中，除了網路問題，在直播過程中的黑屏、花屏、閃屏卻有很多技術原因，這篇文章將全方位為你解決直播中的「黑屏、花屏、閃屏」問題。

繼《直播技術詳解》系列文章之後，我們推出了這個新的系列《直播疑難雜症排查》，把解決直播問題的經驗逐步分享出來，同時也會穿插一些音視訊開發的基礎知識和優化經驗，希望能夠幫助到直播領域的開發者們。

本系列會涵蓋的內容包括但不限於如下一些主題： - 播放失敗

首先我們要明白，黑屏、花屏、閃屏等問題，可能是推流端的問題，也可能是播放器的問題，遇到這些現象，我們要第一時間用別的播放器（如 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.推流端的原因

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

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

推薦閱讀：視訊直播技術詳解

相關文章