黑屏狂打、花屏擂煞、閃屏問(wèn)題
首先我們要明白，黑屏趴乡、花屏旁仿、閃屏等問(wèn)題柿估，可能是推流端的問(wèn)題，也可能是播放器的問(wèn)題，遇到這些現(xiàn)象瑰煎，我們要第一時(shí)間用別的播放器（如 VLC，ffplay）試試肚医，如果都出現(xiàn)同樣的問(wèn)題悦穿，那么多半是流本身的問(wèn)題了，反之，則很可能是播放器的問(wèn)題玻淑。
1. 播放黑屏
現(xiàn)象：畫(huà)面是黑的嗽冒，沒(méi)有圖像，但是有聲音补履。
1.1 主播端攝像頭權(quán)限問(wèn)題
無(wú)論 Android還是iOS辛慰，App 使用攝像頭都是需要申請(qǐng)授權(quán)的，特別是 Android 6.0 以后干像，如果 App 層面不做專(zhuān)門(mén)的處理的話帅腌，很可能出現(xiàn)攝像頭權(quán)限被禁用的情況。
如果 App 沒(méi)有獲取到攝像頭權(quán)限麻汰，視頻就無(wú)法采集成功速客，從而導(dǎo)致推出來(lái)的流只有音頻數(shù)據(jù)。
解決方案：
App 層面肯定要小心處理權(quán)限問(wèn)題五鲫，檢測(cè)到未獲取相應(yīng)權(quán)限則禁止開(kāi)播溺职，或者反復(fù)提示主播授予權(quán)限。另外位喂，可以詢(xún)問(wèn)出現(xiàn)問(wèn)題的主播是否有攝像頭預(yù)覽畫(huà)面浪耘，如果 App 沒(méi)有獲得權(quán)限的話，是沒(méi)有預(yù)覽畫(huà)面的塑崖。
1.2 主播端編碼失敗
視頻數(shù)據(jù)采集到后七冲，下一步就是經(jīng)過(guò)編碼器，由于參數(shù)配置或者某些機(jī)型的硬編兼容性問(wèn)題规婆，很可能數(shù)據(jù)送入編碼器后澜躺，編碼失敗，并無(wú)輸出抒蚜，從而導(dǎo)致沒(méi)有視頻數(shù)據(jù)送入到推流模塊掘鄙。
解決方案：
一般推流 SDK 都會(huì)統(tǒng)計(jì)推流的實(shí)時(shí)視頻幀率，CDN 服務(wù)端也會(huì)有一些幀率監(jiān)控嗡髓，因此操漠，如果發(fā)現(xiàn)這些統(tǒng)計(jì)得到的推流幀率為 0，同時(shí)又確定不是沒(méi)有采集到數(shù)據(jù)饿这，那么多半是編碼器的原因浊伙，可以想辦法查看下該機(jī)型的日志看看具體的報(bào)錯(cuò)信息。
1.3 視頻解碼失敗
前面的文章有提到過(guò)蛹稍，當(dāng)播放器遇到不支持的視頻格式吧黄，或者數(shù)據(jù)內(nèi)容/格式異常，則會(huì)解碼失敗唆姐，從而導(dǎo)致無(wú)解碼視頻輸出拗慨。
針對(duì)不支持的格式：
要提前了解播放器本身支持哪些音視頻格式，如 H.264，mp4v赵抢，aac 等等剧蹂，避免播放不支持的格式
播放器本身遇到的硬解或者軟解失敗，應(yīng)該有日志報(bào)錯(cuò)烦却，或者拋出異常給應(yīng)用層提示用戶
針對(duì)視頻數(shù)據(jù)內(nèi)容錯(cuò)誤：
需要分析碼流文件本身宠叼，常見(jiàn)的數(shù)據(jù)內(nèi)容錯(cuò)誤導(dǎo)致的解碼失敗有如下幾種：
- 送入×××的幀數(shù)據(jù)不完整
- H.264 的視頻碼流，缺失了 SPS其爵，PPS 等必要的信息頭
- iOS 的 VideoToolbox 解碼冒冬，只支持 avcc 方式打包的 H.264 數(shù)據(jù)
- 部分 Android 機(jī)型硬編出來(lái)的數(shù)據(jù)有額外的 naul 頭
- 其他等等
1.4 碼流的前半段只有音頻沒(méi)有視頻
這種情況，多半出自 HLS 切片產(chǎn)生的碼流摩渺，當(dāng)主播用同一個(gè)地址推流简烤，前半段只推了音頻（可能是攝像頭權(quán)限被禁用，也可能是選擇了純音頻推流等等）摇幻，然后接著又同時(shí)推了音視頻流横侦，那么，服務(wù)端 HLS 切片產(chǎn)生的文件绰姻，就會(huì)出現(xiàn)這樣的情況枉侧。
基于 ffmpeg 的播放器，會(huì)在解析完視頻頭后初始化×××狂芋，因此榨馁，對(duì)于這種碼流，往往會(huì)出現(xiàn)僅有音頻或者僅有視頻播放的情況银酗。
解決方案：
從 App 端盡可能避免出現(xiàn)這種使用姿勢(shì)辆影，修改播放器的代碼，對(duì)這種碼流進(jìn)行兼容處理黍特。
2. 播放花屏/綠屏
現(xiàn)象：播放畫(huà)面出現(xiàn)圖像紊亂，大面積的異常顏色的方塊圖锯蛀，或者綠屏現(xiàn)象
1.1 丟失參考幀導(dǎo)致的
一般 H.264 碼流有 I灭衷、B、P 三種幀類(lèi)型旁涤，I 幀是關(guān)鍵幀翔曲，B 幀是雙向預(yù)測(cè)內(nèi)插編碼幀，P 幀是前向預(yù)測(cè)編碼幀劈愚。
I 幀由于是幀內(nèi)壓縮瞳遍，因此可以獨(dú)立解碼播放，而 B 幀菌羽，一旦丟失了 I 幀或者后面的 P 幀掠械，則會(huì)解碼失敗，而 P 幀一旦丟失了前面的 I/B/P 幀，也會(huì)導(dǎo)致解碼失敗猾蒂。
對(duì)于丟失了參考幀而導(dǎo)致的解碼失敗均唉，一般就會(huì)出現(xiàn)花屏的現(xiàn)象，花屏的嚴(yán)重程度依賴(lài)于丟失的參考幀對(duì)即將解碼的幀的重要程度肚菠。
那么舔箭，什么情況下會(huì)丟失參考幀呢 ？
首先蚊逢，推流/播放的代碼層面层扶，需要注意，不要丟棄編碼后烙荷、解碼前的視頻幀數(shù)據(jù)怒医，不過(guò)實(shí)際場(chǎng)景中，遇到下面的情況奢讨，
難免還是會(huì)產(chǎn)生丟幀：
網(wǎng)絡(luò)不好稚叹，編碼后的數(shù)據(jù)發(fā)不出去
系統(tǒng)低內(nèi)存，隊(duì)列里面無(wú)法承受更多的幀數(shù)據(jù)
因此拿诸，在這些極端的情況下扒袖，不得不丟幀的話，最合理的策略就應(yīng)該是一次丟一整個(gè) GOP亩码，即：一旦開(kāi)始丟了一個(gè) I 幀季率，那么在遇到下一個(gè) I 幀之前的所有視頻幀，均丟棄掉描沟，這樣即可有效避免播放器端產(chǎn)生解碼花屏飒泻。
1.2 播放器沒(méi)有從關(guān)鍵幀開(kāi)始解碼
原理依然如上面所述，如果不從關(guān)鍵幀開(kāi)始解碼吏廉，則必然會(huì)由于丟失了參考信息而導(dǎo)致解碼花屏泞遗。
因此，播放器席覆，無(wú)論是首播史辙，還是斷網(wǎng)重連后，都應(yīng)該判斷第一幀視頻是否是關(guān)鍵幀佩伤，如果不是聊倔，則應(yīng)該等到第一個(gè)關(guān)鍵幀到達(dá)之后再送入×××。
1.3 碼流中視頻尺寸發(fā)生變化
很多直播 App生巡，橫屏直播和豎屏直播耙蔑，使用的是不同的推流尺寸 ，當(dāng)主播由豎屏推流改為橫屏推流孤荣，同時(shí)又不改變推流地址的話甸陌，觀眾端拉到的流就會(huì)出現(xiàn)中間發(fā)生了視頻尺寸的變化须揣，比如：從 848 x 480 變成了 1280 x 720 等等。
播放器需要實(shí)時(shí)檢測(cè)邀层，如果發(fā)現(xiàn)視頻尺寸發(fā)生了變化返敬，則需要重置×××以及相關(guān)邏輯，否則容易出現(xiàn)解碼花屏或者出現(xiàn)內(nèi)存越界等異常
1.4 硬編硬解的兼容性問(wèn)題
當(dāng)然寥院，如果使用的是 Android 硬編硬解劲赠，則難免會(huì)遇到一些比較坑爹的手機(jī)，硬編硬解沒(méi)有失敗報(bào)錯(cuò)秸谢，但是輸出的圖像確實(shí)異常的情況凛澎。
Android 硬編硬解的兼容性問(wèn)題，代碼上小心仔細(xì)估蹄，充分考慮機(jī)型的兼容性塑煎，不輕易寫(xiě)死任何參數(shù)，剩下能做的就是靠白名單/黑名單了臭蚁。
1.5 推流端圖像尺寸和格式處理不當(dāng)
圖像的格式和尺寸最铁，都是非常重要的參數(shù)，一定要嚴(yán)格配置正確垮兑。
比如：如果采集到的視頻是 NV21 冷尉，編碼器只支持 I420，那么編碼出來(lái)的圖像自然會(huì)出現(xiàn)顏色問(wèn)題系枪。
比如：在一些場(chǎng)景切換的過(guò)程中雀哨，前后攝像頭切換，視頻的尺寸可能發(fā)生了變化私爷，但是剪裁雾棺、處理、編碼模塊沒(méi)有相應(yīng)的修改尺寸衬浑，那么捌浩，也會(huì)出現(xiàn)各種視頻錯(cuò)亂的現(xiàn)象。
3. 播放閃屏
閃屏問(wèn)題嚎卫，從根源來(lái)看嘉栓，就是播放的過(guò)程中，出現(xiàn)了兩種不同的畫(huà)面來(lái)回切換拓诸，從而看起來(lái)像 “閃屏”，比如麻昼，黑白兩張圖片交替渲染奠支。下面我們?cè)賮?lái)看看直播場(chǎng)景下，什么原因會(huì)引發(fā)該現(xiàn)象抚芦。
3.1 播放器緩沖機(jī)制原因
網(wǎng)絡(luò)不好的時(shí)候倍谜，播放器會(huì)頻繁緩沖迈螟，曾遇到過(guò)一種案例，就是某直播 App 應(yīng)用尔崔，在緩沖的時(shí)候答毫，使用了一張廣告圖片，在某種極端弱網(wǎng)情況下季春，由于頻繁緩沖洗搂，導(dǎo)致真實(shí)的播放畫(huà)面和廣告圖片來(lái)回快速切換，導(dǎo)致閃屏現(xiàn)象载弄。
這個(gè)情況是完全可以從播放器的緩沖策略上避免的耘拇，每次緩沖后，不要收到一幀后就立即渲染宇攻，而是適當(dāng)?shù)囟嗑彌_一些數(shù)據(jù)惫叛，再發(fā)送緩沖結(jié)束的消息，從而可以頻繁 ms 級(jí)別的緩沖切換產(chǎn)生的閃屏逞刷。
3.2 推流端的原因
推流端產(chǎn)生閃屏的流嘉涌，往往發(fā)生在有畫(huà)面合成的代碼模塊，比如：疊加水印夸浅、攝像頭/圖片切換推流仑最、連麥合流等等。
畫(huà)面的合成题篷，一定要銘記一點(diǎn)词身，任何情況下，都要避免出現(xiàn)番枚，有合成/沒(méi)有合成 兩種畫(huà)面的交替法严。
直播專(zhuān)題問(wèn)題排查-播放失敗（一）
直播專(zhuān)題問(wèn)題排查-播放卡頓（二）
直播專(zhuān)題問(wèn)題排查-首開(kāi)慢（三)
直播專(zhuān)題問(wèn)題排查-延時(shí)高（四)
直播專(zhuān)題問(wèn)題排查-音畫(huà)不同步（五）
直播專(zhuān)題問(wèn)題排查-黑屏葫笼、花屏深啤、閃屏(六)
直播專(zhuān)題問(wèn)題排查-播放雜音、噪音路星、回聲(七)
直播專(zhuān)題問(wèn)題排查-拖動(dòng)不準(zhǔn)(八)
直播專(zhuān)題問(wèn)題排查-功耗高(九)
直播專(zhuān)題問(wèn)題排查-馬賽克(十)
