黑屏、花屏、閃屏問題
首先我們要明白,黑屏、花屏、閃屏等問題,可能是推流端的問題,也可能是播放器的問題,遇到這些現象,我們要第一時間用別的播放器(如 VLC,ffplay
)試試,如果都出現同樣的問題,那么多半是流本身的問題了,反之,則很可能是播放器的問題。
1. 播放黑屏
現象:畫面是黑的,沒有圖像,但是有聲音。
1.1 主播端攝像頭權限問題
無論 Android
還是iOS
,App 使用攝像頭都是需要申請授權的,特別是 Android 6.0 以后,如果 App 層面不做專門的處理的話,很可能出現攝像頭權限被禁用的情況。
如果 App 沒有獲取到攝像頭權限,視頻就無法采集成功,從而導致推出來的流只有音頻數據。
解決方案:
App 層面肯定要小心處理權限問題,檢測到未獲取相應權限則禁止開播,或者反復提示主播授予權限。另外,可以詢問出現問題的主播是否有攝像頭預覽畫面,如果 App 沒有獲得權限的話,是沒有預覽畫面的。
1.2 主播端編碼失敗
視頻數據采集
到后,下一步就是經過編碼器,由于參數配置或者某些機型的硬編兼容性問題,很可能數據送入編碼器后,編碼失敗,并無輸出,從而導致沒有視頻數據送入到推流模塊。
解決方案:
一般推流 SDK 都會統計推流的實時視頻幀率,CDN 服務端也會有一些幀率監控,因此,如果發現這些統計得到的推流幀率為 0,同時又確定不是沒有采集到數據,那么多半是編碼器的原因,可以想辦法查看下該機型的日志看看具體的報錯信息。
1.3 視頻解碼失敗
前面的文章有提到過,當播放器遇到不支持的視頻格式,或者數據內容/格式異常,則會解碼失敗,從而導致無解碼視頻輸出。
針對不支持的格式:
要提前了解播放器本身支持哪些音視頻格式,如 H.264,mp4v,aac 等等,避免播放不支持的格式
播放器本身遇到的硬解或者軟解失敗,應該有日志報錯,或者拋出異常給應用層提示用戶
針對視頻數據內容錯誤:
需要分析碼流文件本身,常見的數據內容錯誤導致的解碼失敗有如下幾種:
- 送入×××的幀數據不完整
- H.264 的視頻碼流,缺失了 SPS,PPS 等必要的信息頭
- iOS 的 VideoToolbox 解碼,只支持 avcc 方式打包的 H.264 數據
- 部分 Android 機型硬編出來的數據有額外的 naul 頭
- 其他等等
1.4 碼流的前半段只有音頻沒有視頻
這種情況,多半出自 HLS 切片產生的碼流,當主播用同一個地址推流,前半段只推了音頻(可能是攝像頭權限被禁用,也可能是選擇了純音頻推流等等),然后接著又同時推了音視頻流,那么,服務端 HLS 切片產生的文件,就會出現這樣的情況。
基于 ffmpeg 的播放器,會在解析完視頻頭后初始化×××,因此,對于這種碼流,往往會出現僅有音頻或者僅有視頻播放的情況。
解決方案:
從 App 端盡可能避免出現這種使用姿勢,修改播放器的代碼,對這種碼流進行兼容處理。
2. 播放花屏/綠屏
現象:播放畫面出現圖像紊亂,大面積的異常顏色的方塊圖,或者綠屏現象
1.1 丟失參考幀導致的
一般 H.264 碼流有 I、B、P 三種幀類型,I 幀是關鍵幀,B 幀是雙向預測內插編碼幀,P 幀是前向預測編碼幀。
I 幀由于是幀內壓縮,因此可以獨立解碼播放,而 B 幀,一旦丟失了 I 幀或者后面的 P 幀,則會解碼失敗,而 P 幀一旦丟失了前面的 I/B/P 幀,也會導致解碼失敗。
對于丟失了參考幀而導致的解碼失敗,一般就會出現花屏的現象,花屏的嚴重程度依賴于丟失的參考幀對即將解碼的幀的重要程度。
那么,什么情況下會丟失參考幀呢 ?
首先,推流/播放的代碼層面,需要注意,不要丟棄編碼后、解碼前的視頻幀數據,不過實際場景中,遇到下面的情況,
難免還是會產生丟幀:
網絡不好,編碼后的數據發不出去
系統低內存,隊列里面無法承受更多的幀數據
因此,在這些極端的情況下,不得不丟幀的話,最合理的策略就應該是一次丟一整個 GOP,即:一旦開始丟了一個 I 幀,那么在遇到下一個 I 幀之前的所有視頻幀,均丟棄掉,這樣即可有效避免播放器端產生解碼花屏。
1.2 播放器沒有從關鍵幀開始解碼
原理依然如上面所述,如果不從關鍵幀開始解碼,則必然會由于丟失了參考信息而導致解碼花屏。
因此,播放器,無論是首播,還是斷網重連后,都應該判斷第一幀視頻是否是關鍵幀,如果不是,則應該等到第一個關鍵幀到達之后再送入×××。
1.3 碼流中視頻尺寸發生變化
很多直播 App,橫屏直播和豎屏直播,使用的是不同的推流尺寸 ,當主播由豎屏推流改為橫屏推流,同時又不改變推流地址的話,觀眾端拉到的流就會出現中間發生了視頻尺寸的變化,比如:從 848 x 480 變成了 1280 x 720 等等。
播放器需要實時檢測,如果發現視頻尺寸發生了變化,則需要重置×××以及相關邏輯,否則容易出現解碼花屏或者出現內存越界等異常
1.4 硬編硬解的兼容性問題
當然,如果使用的是 Android 硬編硬解,則難免會遇到一些比較坑爹的手機,硬編硬解沒有失敗報錯,但是輸出的圖像確實異常的情況。
Android 硬編硬解的兼容性問題,代碼上小心仔細,充分考慮機型的兼容性,不輕易寫死任何參數,剩下能做的就是靠白名單/黑名單了。
1.5 推流端圖像尺寸和格式處理不當
圖像的格式和尺寸,都是非常重要的參數,一定要嚴格配置正確。
比如:如果采集到的視頻是 NV21 ,編碼器只支持 I420,那么編碼出來的圖像自然會出現顏色問題。
比如:在一些場景切換的過程中,前后攝像頭切換,視頻的尺寸可能發生了變化,但是剪裁、處理、編碼模塊沒有相應的修改尺寸,那么,也會出現各種視頻錯亂的現象。
3. 播放閃屏
閃屏問題,從根源來看,就是播放的過程中,出現了兩種不同的畫面來回切換,從而看起來像 “閃屏”,比如,黑白兩張圖片交替渲染。下面我們再來看看直播場景下,什么原因會引發該現象。
3.1 播放器緩沖機制原因
網絡不好的時候,播放器會頻繁緩沖,曾遇到過一種案例,就是某直播 App 應用,在緩沖的時候,使用了一張廣告圖片,在某種極端弱網情況下,由于頻繁緩沖,導致真實的播放畫面和廣告圖片來回快速切換,導致閃屏現象。
這個情況是完全可以從播放器的緩沖策略上避免的,每次緩沖后,不要收到一幀后就立即渲染,而是適當地多緩沖一些數據,再發送緩沖結束的消息,從而可以頻繁 ms 級別的緩沖切換產生的閃屏。
3.2 推流端的原因
推流端產生閃屏的流,往往發生在有畫面合成的代碼模塊,比如:疊加水印、攝像頭/圖片切換推流、連麥合流等等。
畫面的合成,一定要銘記一點,任何情況下,都要避免出現,有合成/沒有合成 兩種畫面的交替。
直播專題問題排查-播放失?。ㄒ唬?/a>
直播專題問題排查-播放卡頓(二)
直播專題問題排查-首開慢(三)
直播專題問題排查-延時高(四)
直播專題問題排查-音畫不同步(五)
直播專題問題排查-黑屏、花屏、閃屏(六)
直播專題問題排查-播放雜音、噪音、回聲(七)
直播專題問題排查-拖動不準(八)
直播專題問題排查-功耗高(九)
直播專題問題排查-馬賽克(十)