上海2017年4月26日電 /美通社/ -- 七牛直播云在 2016 年 6 月發布之后，幫助廣大客戶解決過形形色色的問題，如直播卡頓、馬賽克、花屏、黑屏、雜音、音畫不同步等，這其中，有一些是網絡原因，有一些是開發者的使用姿勢問題，有一些是參數配置錯誤，當然，也有一些是 SDK 本身的問題。近日，七牛云盧俊就直(zhi)播(bo)技術中的各類播(bo)放失敗問題進行(xing)了(le)專(zhuan)業解(jie)析(xi)，以下為解(jie)析(xi)原文：

總結下來，如(ru)果開發(fa)者能夠(gou)對(dui)直播領(ling)域的一些(xie)基礎知識(shi)有更深入的了解(jie)(jie)，掌握(wo)一些(xie)基本的排障手段，很多問題是能夠(gou)很快自行解(jie)(jie)決的，甚至也(ye)能夠(gou)更好地(di)防患于未然。

因此(ci)，繼《直(zhi)播技術詳解(jie)》系列文章之后(hou)，我們推(tui)出了這個新的系列《直(zhi)播疑難雜(za)癥排(pai)查》，我們會(hui)把(ba)協助客(ke)戶解(jie)決直(zhi)播問題的經驗(yan)逐步分享(xiang)出來，同時也會(hui)穿插一些音(yin)視(shi)頻開發的基(ji)礎知識(shi)和優化經驗(yan)，希望能(neng)夠(gou)幫(bang)助到直(zhi)播領域(yu)的開發者(zhe)們。

第一篇文章我們從播放開(kai)(kai)始，因為觀看直播重要(yao)的一個環節(jie)就是打(da)開(kai)(kai)播放器，很多問(wen)題的直接反饋也是來自觀眾端。

導致播放(fang)(fang)失敗的(de)原因有很(hen)(hen)多種，不一(yi)定(ding)是播放(fang)(fang)器本身的(de)問(wen)題(ti)，不過通過播放(fang)(fang)器，我們(men)很(hen)(hen)容(rong)易反過來排(pai)查服務端(duan)或者推流(liu)端(duan)的(de)問(wen)題(ti)。下面我們(men)會從(cong)播放(fang)(fang)失敗的(de)表現、播放(fang)(fang)問(wen)題(ti)排(pai)查工(gong)具、常見問(wen)題(ti)分析等多個方面展開討論。

播放失敗的表現

播放失敗的表現總結下來包括但不限于以下這些：
界面上一直顯示“加載中”，或者提示播放失敗的錯誤；
播放畫面卡死不動，但 UI 按鈕可以點擊；
有(you)聲音沒有(you)畫(hua)面(mian)，有(you)畫(hua)面(mian)沒有(you)聲音。

這里并不討論如播放卡頓、音畫不同步、馬賽克、延時、花屏等問題，這些話題，我們將會在后續的文章中探討，本文重點關注的是：為啥無法順利“打開”直播流 ？

播放問題的排查工具

一(yi)旦我們遇(yu)到視頻(pin)播(bo)放(fang)(fang)不了(le)，第一(yi)件事，就是(shi)要找幾(ji)個(ge)別的(de)播(bo)放(fang)(fang)器(qi)也播(bo)放(fang)(fang)看(kan)看(kan)，做一(yi)下(xia)對比測試，或者對碼(ma)流做一(yi)些基礎分析，以便更好地定位(wei)問題的(de)源頭，各個(ge)平(ping)臺比較常見的(de)播(bo)放(fang)(fang)/分析工具有如下(xia)幾(ji)個(ge)：

命令行工具：ffplay、ffprobe、mediainfo、hls-analyzer 等

網頁端工具

App 應(ying)用(yong)：VLC，VPlayer，MXPlayer 等(deng)

Windows 工具：mp4info、FlvParse、FLVMeta、Elecard StreamEye Studio 等

常見播放失敗問題排查

基礎概念

從給播放器傳入播放地址，到播放畫面顯示出來，一般有如下幾個步驟：
DNS 解析，將播放地址中的域名解析為對應的服務器 IP 地址；
連接服務器，完成 http 請求或者 rtmp 握手過程；
接收(shou)服務器(qi)發送的數據，解(jie)協議解(jie)封裝，拿到(dao)音(yin)視頻數據解(jie)碼(ma)播(bo)放。

任何一個環節出了(le)問題(ti)，都有可能導致(zhi)播(bo)放(fang)(fang)失敗，不(bu)同的協議，由于協議層(ceng)原因，播(bo)放(fang)(fang)報錯往往不(bu)太一樣(yang)，我們下面的討(tao)論(lun)，主要以(yi) RTMP/HTTP 這兩種協議為主，假設正常(chang)的播(bo)放(fang)(fang)測試地址如下：

香(xiang)港衛視的 RTMP 直播流：rtmp://live.hkstv.hk.lxdns.com/live/hks

W3C School 的測試 mp4 流：

域名解析失敗
如(ru)果播放(fang)地址(zhi)的(de)域(yu)名無法解析，會導致播放(fang)失敗(bai)，一般斷(duan)網(wang)了或者域(yu)名無效(xiao)，則播放(fang)的(de)時候，會有類似如(ru)下報錯：

$ffplay rtmp://live.hkstv.hk.lxdns.com1/live/hks

Failed to resolve hostname live.hkstv.hk.lxdns.com1: nodename nor servname provided, or not known

Failed to resolve hostname live.hkstv.hk.lxdns.com1: No address associated with hostname

當然，如果(guo)有網絡，但是域名解析失(shi)敗(bai)，一(yi)般 ISP 運營商可能會返(fan)回一(yi)些(xie)類似 404 頁(ye)面，或者(zhe)跳轉到其(qi)他(ta)(ta)的(de)默認(ren)網頁(ye)，因(yin)此，對于 HLS，HTTP-FLV，HTTP-mp4 等碼流(liu)，會因(yin)為讀到一(yi)些(xie)「臟數據(ju)」從(cong)而返(fan)回一(yi)些(xie)其(qi)他(ta)(ta)的(de)錯(cuo)誤，例如：

$ ffplay

//www.w3school2.com.cn1/i/movie.m3u8: Operation timed out

$ ffplay //www.w3school2.com.cn1/i/movie.mp4

//www.w3school2.com.cn1/i/movie.mp4: Invalid data found when processing input

遇到(dao)這(zhe)類錯誤，一般可(ke)以(yi)通過 ping 一下域名(ming)試(shi)試(shi)，看看是否可(ke)以(yi) ping 通，如果(guo) ping 不通，則(ze)可(ke)能要檢(jian)查下域名(ming)解析(xi)的配置了。

服務器連接失敗

如果域(yu)名(ming)正確，并且有網絡連接的(de)狀(zhuang)態，多半(ban)是可以正常解(jie)析出服(fu)務器 ip 地(di)址的(de)，但是依然有連接失(shi)敗(bai)的(de)可能，比如，這(zhe)臺服(fu)務器相應(ying)的(de)服(fu)務掛掉了，或者并沒有在相應(ying)的(de)端(duan)口提供服(fu)務，從而導致(zhi)播放器連接失(shi)敗(bai)，類似問題的(de)報錯如下：

$ ffplay rtmp://

Cannot open connection tcp://:1935

rtmp:// Operation timed out

因為(wei) 對應的服務(wu)(wu)器(qi)并沒有提供 rtmp 拉(la)流服務(wu)(wu)，因此通過 1935 連接該(gai)服務(wu)(wu)器(qi)會(hui)失敗。

$ ffplay

Connection to tcp://:443 failed: Connection refused

因為(wei) 并不支持 https 訪問，因此通過 443 接口(kou)請求 https 連接失敗。

當然(ran)，也有可能是這(zhe)臺(tai)服務(wu)器(qi)雖然(ran)提供了(le) rtmp 拉(la)流服務(wu)但是宕(dang)機了(le)，因此(ci)，我(wo)們需要通過 dig 命(ming)令確定最終訪(fang)問的(de)是哪一臺(tai)服務(wu)器(qi)，并(bing)排(pai)查下(xia)該服務(wu)器(qi)為什(shen)么無法連接，當然(ran)，較好是修改下(xia) ffpmeg 源碼，把解析出(chu)來(lai)的(de)服務(wu)器(qi) IP 地址打(da)印(yin)出(chu)來(lai)，這(zhe)樣就(jiu)可以直接看到所連接的(de)服務(wu)器(qi)地址了(le)。

請求的資源不存在

對于 http 協議的(de)直播(bo)地(di)址，請求的(de)播(bo)放資(zi)源不存在，返回的(de)錯誤還是比(bi)較快的(de)，比(bi)如：

$ ffplay

Server returned 404 Not Found

$ ffplay

Invalid data found when processing input

注：由于讀到 ISP 運營商返回的跳轉頁面的“臟數據”，因此也有可能返回上面(mian)這種錯(cuo)誤。

而 RTMP 直播協議，跟 HTTP 協議的播放，有著一個很大的不同，就是播放器請求的數據，并不一定“存放”在服務器，因此，服務器無法簡單通過 URI 定位不到則返回 404，這些數據可能是在 RTMP 握手之后，由生產端逐步產生并由服務器轉發到客戶端，因此很難簡單判斷說“資源不存在”。

通常 RTMP 協(xie)議(yi)的直播(bo)流，如(ru)果推流端沒有推流了，播(bo)放器這邊一(yi)般(ban)是讀數據超時(shi)后(hou)才(cai)會返回錯誤，例如(ru)：

$ ffplay rtmp://live.hkstv.hk.lxdns.com/live/hks1

rtmp://live.hkstv.hk.lxdns.com/live/hks1: Input/output error

不支持的格式

視頻流的采用(yong)的網絡(luo)協議、編(bian)(bian)碼(ma)格(ge)式(shi)、封裝格(ge)式(shi)有很多種，網絡(luo)協議比如(ru) http/https/rtmp/rtsp 等等，編(bian)(bian)碼(ma)格(ge)式(shi)比如(ru) h.264，mpeg4，aac，speex 等等，封裝格(ge)式(shi)比如(ru) flv，mp4，avi，rmvb 等等，這些協議和格(ge)式(shi)的流，都是需要播放器專門添(tian)加支(zhi)持的，因此，播放器遇到(dao)不支(zhi)持的協議或者(zhe)格(ge)式(shi)，也會(hui)導致播放失敗，如(ru)下所示：

Protocol not found

Invalid data found when processing input

只有(you)(you)音頻(pin)(pin)沒有(you)(you)視(shi)頻(pin)(pin)，或(huo)者只有(you)(you)視(shi)頻(pin)(pin)沒有(you)(you)音頻(pin)(pin)

出(chu)現該錯誤的原因可能(neng)有如下幾點(dian)：

音(yin)頻/視(shi)頻的編碼格(ge)式不支持，導致解(jie)碼失(shi)敗

音頻(pin)/視頻(pin)的數(shu)據內(nei)容異常，導致解碼(ma)失(shi)敗(bai)

基于 ffmpeg 的播放器的"probesize"設置太小(xiao)，導致解析碼流信息(xi)不(bu)足

碼流(liu)/文件本身(shen)的前(qian)半(ban)段只(zhi)有音頻(pin)沒有視(shi)頻(pin)，或者只(zhi)有視(shi)頻(pin)沒有音頻(pin)

這個問題播放啟動流程已經(jing)完成，只是出現了畫面缺失、或(huo)者音頻缺失，也算(suan)是一種播放失敗，限于(yu)本文(wen)篇(pian)幅(fu)，該(gai)問題后面會抽出專(zhuan)門的章節來分析(xi)。

其他播放失敗

上面只分析了常見的(de)播(bo)放(fang)失(shi)敗問題，其實導致播(bo)放(fang)失(shi)敗的(de)原(yuan)(yuan)因(yin)還(huan)有(you)很多(duo)種，這里無法一(yi)一(yi)都列出來，不過通過 ffplay 的(de)報錯(cuo)，就可能知道大(da)概的(de)原(yuan)(yuan)因(yin)，再聯(lian)合(he)服務端一(yi)起調試調試，一(yi)般(ban)都是可以找到根本(ben)原(yuan)(yuan)因(yin)的(de)。