問題背景：

前兩天看讀者留言讓再寫寫音視頻問題排查方面的思路，前面大概寫幾篇：《音視頻播放疑難雜癥分析和解決 ：序篇》、《音視頻常見問題分析和解決：延時(shí)和抖動(dòng)》、《記一次因?yàn)閬G幀導(dǎo)致視頻播放花屏問題的排查》。今天繼續(xù)這個(gè)系列補(bǔ)充。由于移動(dòng)互聯(lián)網(wǎng)的快速發(fā)展，現(xiàn)在一些音視頻IOT相關(guān)的智能設(shè)備如IPC、智能貓眼等，有很多移動(dòng)端瀏覽器或者微信小程序的播放需求，這種情況我們用了HLS+TS方案。

近期上線后，發(fā)現(xiàn)視頻整體播放沒有啥大問題，但是仔細(xì)看還是感覺有點(diǎn)卡頓，不仔細(xì)看不容易發(fā)現(xiàn)，就這個(gè)視頻卡頓問題進(jìn)行了一番排查，先說下結(jié)論：我們?cè)谧x磁盤的TS切片文件時(shí)，沒有把整個(gè)TS讀完整，導(dǎo)致每個(gè)GOP最后有幾幀丟了導(dǎo)致視頻播放起來有稍微的卡頓感。

視頻卡頓引起的原因很多，一般分為兩大類：

一類是因?yàn)橐粢曨l時(shí)間戳打的不規(guī)范導(dǎo)致視頻在解碼渲染時(shí)順序不對(duì)引起的；

另外一大類就是視頻傳輸過程中因?yàn)榫W(wǎng)絡(luò)問題導(dǎo)致的丟包進(jìn)而產(chǎn)生的花屏和卡頓問題。一般具體問題需要具體分析，但是思路差不多。

---

問題排查：

1.排查問題前，大概畫下流程處理示意圖：

2.?分析思路：還是利用對(duì)比法和分段法進(jìn)行定位問題出現(xiàn)在那個(gè)環(huán)節(jié)和模塊。

上傳碼流從生產(chǎn)到消費(fèi)的路徑有兩條：

第一條碼流傳輸路徑：

1-----2------6：這條路徑主要是我們的私有協(xié)議，在自研移動(dòng)端APP上進(jìn)行觀看播放碼流，實(shí)際發(fā)現(xiàn)播放很順暢，無(wú)卡頓感。

第二條碼流傳輸路徑：

1-----2-----3-----4------5：由于第一條沒有問題，那說明問題只可能出現(xiàn)在3-----4-----5這三個(gè)環(huán)節(jié)。其中HLSTS服務(wù)是進(jìn)行碼流轉(zhuǎn)化和切片的模塊，第三方對(duì)象存儲(chǔ)主要是借助公有云進(jìn)行存儲(chǔ)TS文件，HLSAPI是m3u8生成和碼流分發(fā)模塊。由于第三方對(duì)象存儲(chǔ)都是大廠阿里，華為的，出問題概率比較低，所以先從HLSTS切片模塊分析起來，逐漸向上層排查。

?3.?為了復(fù)現(xiàn)該問題，我們?cè)跀z像頭前面電腦上循環(huán)播放一段籃球投籃的小視頻，如果出現(xiàn)卡頓問題很容易在瀏覽器上播放時(shí)發(fā)現(xiàn)，大家可以看下當(dāng)時(shí)卡頓的情況。接著把HLSTS當(dāng)時(shí)切片到磁盤上的一個(gè)個(gè)小TS合并成一個(gè)大文件播放，比較下到底是不是問題出現(xiàn)在把私有流傳TS切片的過程，如果不是就繼續(xù)分析上傳到對(duì)象存儲(chǔ)以及之后的下載分發(fā)情況。

結(jié)果發(fā)現(xiàn)把磁盤文件down到本地合并后播放，并無(wú)卡頓感播放挺順利，那說明問題至少出在HLSTS服務(wù)上傳第三方對(duì)象存儲(chǔ)過程以后了。然后利用對(duì)象存儲(chǔ)SDK將上傳上去的TS片段拉下來分析發(fā)現(xiàn)視頻的確卡頓，進(jìn)而說明問題就出在HLSTS上傳這塊了。

4.?那到底什么原因?qū)е聫拇疟P讀文件再上傳就少了一部分?jǐn)?shù)據(jù)呢，少的數(shù)據(jù)又少了什么呢？然后把從對(duì)象存儲(chǔ)拉下來的TS文件利用Elecard工具分析，發(fā)現(xiàn)每個(gè)GOP文件內(nèi)少了幾個(gè)P幀數(shù)據(jù)，由于攝像頭是固定幀率，每4秒一個(gè)GOP，我們切片也是一個(gè)個(gè)GOP進(jìn)行切成TS文件的。按道理一個(gè)TS應(yīng)該100幀，實(shí)際發(fā)現(xiàn)總是在GOP的末尾少了幾幀，既然丟幀了難怪播放起來不是很順暢，如果丟幀5幀以上則播放TS時(shí)更明顯，當(dāng)時(shí)分析的文件：

這里幀率是25，一個(gè)GOP 4秒固定幀率算下來實(shí)際是100幀實(shí)際只有97幀，說明丟了3幀。

5.?后來發(fā)現(xiàn)從第三方對(duì)象存在下載下來的所有TS多少都存在丟幀情況，有些上傳到OSS對(duì)象上丟了1、2幀有些則丟了4、5幀，那問題肯定出在HLSTS的上傳文件模塊中。為了驗(yàn)證實(shí)際將切到磁盤文件的大小和上傳模塊讀的文件大小做了比較，的確上傳模塊上傳文件都沒有把文件讀完整進(jìn)行上傳。

其中左側(cè)是切出來文件寫到磁盤上的實(shí)際大小，右側(cè)是日志上傳時(shí)讀取的大小，明顯發(fā)現(xiàn)沒有把TS讀完整進(jìn)行上傳。

6.?由于切片這塊我們借助了FFMPEG，大概思路就是收到一個(gè)GOP時(shí)完成一個(gè)TS切片，切完后立即通知上傳模塊的線程進(jìn)行讀取文件上傳對(duì)象存儲(chǔ)。既然讀的模塊沒有上傳完整，大概想原因可能在讀取文件時(shí)，實(shí)際切片還沒完全寫到磁盤的文件時(shí)，收到通知后發(fā)現(xiàn)有文件就開始上傳了。后來也驗(yàn)證了猜想的正確，因?yàn)楫吘箒G幀都丟在TS文件的末尾幾幀數(shù)據(jù)上，那什么原因?qū)е聦懘疟P的過程滯后讀文件的線程呢，畢竟這里是同步操作的。再后來發(fā)現(xiàn)切片寫文件我們用的FFmpeg接口是av_interleaved_write_frame 而不是av_write_frame，這樣前面的接口為了交織的將音視頻packet寫的TS文件，會(huì)根據(jù)音視頻的DTS進(jìn)行緩存和排序，這樣寫文件時(shí)沒有av_write_frame直接寫得快，實(shí)際我們?cè)谡{(diào)用這個(gè)接口時(shí)音視頻的DTS我們上層是能控制的也是排好序的，完全沒必要讓FFmpeg接口取做緩存排序這件事，所以將接口切換到av_write_frame，后來切換后實(shí)際寫完后通知上傳文件線程就能讀到完整文件。實(shí)際上傳的大小也就是文件寫磁盤的大小，視頻卡頓也消失了。下面是分析結(jié)果和實(shí)際優(yōu)化后的播放效果。

這里一個(gè)GOP就變成100幀，實(shí)際日志也顯示上傳的大小和磁盤文件最終的文件大小一致：

當(dāng)然解決這個(gè)問題思路很多，我們就是通過換接口進(jìn)行了解決，因?yàn)槲覀冎苯訉慣S不會(huì)存在問題，上層調(diào)用者對(duì)DTS排序問題已經(jīng)做了處理。

---

思考總結(jié)：

音視頻問題很多，常見的就有音視頻卡頓、花屏、延時(shí)大，音畫不同步等一系列問題。但是偏差這些問題無(wú)非就下面幾點(diǎn)：

1.?分段分析，先利用二分法把問題一點(diǎn)點(diǎn)局限到一個(gè)過程或者一個(gè)服務(wù)中，這樣縮小問題的排查范圍；

2.?對(duì)比實(shí)驗(yàn)，利用一些路徑上的對(duì)比實(shí)驗(yàn)也可以快速排查問題不是出在什么地方，也可以大幅度縮小問題排查。例如，直播時(shí)如大家APP播放同一主播的視頻都出現(xiàn)問題，那問題大概率出現(xiàn)在主播端上行推流端，如果你的APP有問題，其他人能順暢播放那說明問題出在你APP的下行端概率比較高，這樣通過做一些簡(jiǎn)單的對(duì)比試驗(yàn)就可以把問題不會(huì)出現(xiàn)的路徑去除掉

3.?寫碼流、分析碼流、看日志、搭建環(huán)境復(fù)現(xiàn)問題成了排查問題根因的最后手段，線上問題一般先采用一些規(guī)避手段解決掉;

4.?專業(yè)的事交給專業(yè)的工具，視頻碼流是比較復(fù)雜的東西，分析時(shí)一定要借助專業(yè)工具，這些專業(yè)工具有些是現(xiàn)成的比如FFmpeg、Elecard、ParseFlv、Mp4Box，有些也需要自己平時(shí)積累開發(fā)一些工具出來，然后分析是傳輸、封裝還是編解碼層的問題。

---

往期文章回顧:

譯：構(gòu)建音視頻直播應(yīng)用需要考慮的12件事

HLS+FMP4方案對(duì)H.265+AAC支持要點(diǎn)

流媒體傳輸協(xié)議：RTMP、HLS和RTSP介紹

基于HLS-TS&RTMP-FLV的微信小程序點(diǎn)直播方案

一圖看懂音視頻核心技術(shù)棧(框架、工具和場(chǎng)景))

國(guó)產(chǎn)開源流媒體SRS4.0對(duì)視頻監(jiān)控GB28181的支持

從方塊效應(yīng)&呼吸效應(yīng)看編碼量化參數(shù)對(duì)流控的作用

家庭消費(fèi)類攝像頭選擇攻略和隱私保護(hù)小建議

音視頻封裝小總結(jié)(PS?TS?和FLV)

SDP在RTSP、國(guó)標(biāo)GB28181、WebRTC中的實(shí)踐

視頻監(jiān)控?cái)z像頭的互聯(lián)網(wǎng)化實(shí)踐思路

在HTML5上開發(fā)音視頻應(yīng)用的五種思路

周末活動(dòng)回顧：視頻質(zhì)量主觀評(píng)價(jià)、實(shí)時(shí)RTC和AV1

音視頻封裝：MP4結(jié)構(gòu)概述和分析工具

音視頻解封裝：MP4核心Box詳解及H264&AAC打包方案

音視頻基礎(chǔ)知識(shí)-時(shí)間戳的理解

音視頻封裝格式：AAC音頻基礎(chǔ)和ADTS打包方案詳解

從人類的第一次直播聊聊視頻監(jiān)控行業(yè)

音視頻壓縮：H264碼流層次結(jié)構(gòu)和NALU詳解

音視頻傳輸：RTP協(xié)議詳解和H.264打包方案

音視頻常見問題分析和解決：延時(shí)和抖動(dòng)

---

個(gè)人轉(zhuǎn)載內(nèi)容至朋友圈和群聊天，無(wú)需特別申請(qǐng)版權(quán)許可。

引用轉(zhuǎn)載該訂閱號(hào)文章，注明文章來源即可。

記得右下角點(diǎn)“在看”，還可以關(guān)注該訂閱號(hào)，防止遺漏推送哦

---

今天就說這么多，祝您工作順利！

總結(jié)

以上是生活随笔為你收集整理的ffmpeg 丢帧 灰屏_音视频常见问题分析和解决：HLS切片丢帧引起的视频卡顿问题排查...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。