黑屏狂打、花屏擂煞、閃屏問(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)題排查-馬賽克(十)