問題背景：

前兩天看讀者留言讓再寫寫音視頻問題排查方面的思路，前面大概寫幾篇：《音視頻播放疑難雜癥分析和解決 ：序篇》、《音視頻常見問題分析和解決：延時和抖動》、《記一次因為丟幀導致視頻播放花屏問題的排查》。今天繼續這個系列補充。由于移動互聯網的快速發展，現在一些音視頻IOT相關的智能設備如IPC、智能貓眼等，有很多移動端瀏覽器或者微信小程序的播放需求，這種情況我們用了HLS+TS方案。

近期上線后，發現視頻整體播放沒有啥大問題，但是仔細看還是感覺有點卡頓，不仔細看不容易發現，就這個視頻卡頓問題進行了一番排查，先說下結論：我們在讀磁盤的TS切片文件時，沒有把整個TS讀完整，導致每個GOP最后有幾幀丟了導致視頻播放起來有稍微的卡頓感。

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

一類是因為音視頻時間戳打的不規范導致視頻在解碼渲染時順序不對引起的；

另外一大類就是視頻傳輸過程中因為網絡問題導致的丟包進而產生的花屏和卡頓問題。一般具體問題需要具體分析，但是思路差不多。

---

問題排查：

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

2.?分析思路：還是利用對比法和分段法進行定位問題出現在那個環節和模塊。

上傳碼流從生產到消費的路徑有兩條：

第一條碼流傳輸路徑：

1-----2------6：這條路徑主要是我們的私有協議，在自研移動端APP上進行觀看播放碼流，實際發現播放很順暢，無卡頓感。

第二條碼流傳輸路徑：

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

?3.?為了復現該問題，我們在攝像頭前面電腦上循環播放一段籃球投籃的小視頻，如果出現卡頓問題很容易在瀏覽器上播放時發現，大家可以看下當時卡頓的情況。接著把HLSTS當時切片到磁盤上的一個個小TS合并成一個大文件播放，比較下到底是不是問題出現在把私有流傳TS切片的過程，如果不是就繼續分析上傳到對象存儲以及之后的下載分發情況。

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

4.?那到底什么原因導致從磁盤讀文件再上傳就少了一部分數據呢，少的數據又少了什么呢？然后把從對象存儲拉下來的TS文件利用Elecard工具分析，發現每個GOP文件內少了幾個P幀數據，由于攝像頭是固定幀率，每4秒一個GOP，我們切片也是一個個GOP進行切成TS文件的。按道理一個TS應該100幀，實際發現總是在GOP的末尾少了幾幀，既然丟幀了難怪播放起來不是很順暢，如果丟幀5幀以上則播放TS時更明顯，當時分析的文件：

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

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

其中左側是切出來文件寫到磁盤上的實際大小，右側是日志上傳時讀取的大小，明顯發現沒有把TS讀完整進行上傳。

6.?由于切片這塊我們借助了FFMPEG，大概思路就是收到一個GOP時完成一個TS切片，切完后立即通知上傳模塊的線程進行讀取文件上傳對象存儲。既然讀的模塊沒有上傳完整，大概想原因可能在讀取文件時，實際切片還沒完全寫到磁盤的文件時，收到通知后發現有文件就開始上傳了。后來也驗證了猜想的正確，因為畢竟丟幀都丟在TS文件的末尾幾幀數據上，那什么原因導致寫磁盤的過程滯后讀文件的線程呢，畢竟這里是同步操作的。再后來發現切片寫文件我們用的FFmpeg接口是av_interleaved_write_frame 而不是av_write_frame，這樣前面的接口為了交織的將音視頻packet寫的TS文件，會根據音視頻的DTS進行緩存和排序，這樣寫文件時沒有av_write_frame直接寫得快，實際我們在調用這個接口時音視頻的DTS我們上層是能控制的也是排好序的，完全沒必要讓FFmpeg接口取做緩存排序這件事，所以將接口切換到av_write_frame，后來切換后實際寫完后通知上傳文件線程就能讀到完整文件。實際上傳的大小也就是文件寫磁盤的大小，視頻卡頓也消失了。下面是分析結果和實際優化后的播放效果。

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

當然解決這個問題思路很多，我們就是通過換接口進行了解決，因為我們直接寫TS不會存在問題，上層調用者對DTS排序問題已經做了處理。

---

思考總結：

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

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

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

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

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

---

往期文章回顧:

譯：構建音視頻直播應用需要考慮的12件事

HLS+FMP4方案對H.265+AAC支持要點

流媒體傳輸協議：RTMP、HLS和RTSP介紹

基于HLS-TS&RTMP-FLV的微信小程序點直播方案

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

國產開源流媒體SRS4.0對視頻監控GB28181的支持

從方塊效應&呼吸效應看編碼量化參數對流控的作用

家庭消費類攝像頭選擇攻略和隱私保護小建議

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

SDP在RTSP、國標GB28181、WebRTC中的實踐

視頻監控攝像頭的互聯網化實踐思路

在HTML5上開發音視頻應用的五種思路

周末活動回顧：視頻質量主觀評價、實時RTC和AV1

音視頻封裝：MP4結構概述和分析工具

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

音視頻基礎知識-時間戳的理解

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

從人類的第一次直播聊聊視頻監控行業

音視頻壓縮：H264碼流層次結構和NALU詳解

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

音視頻常見問題分析和解決：延時和抖動

---

個人轉載內容至朋友圈和群聊天，無需特別申請版權許可。

引用轉載該訂閱號文章，注明文章來源即可。

記得右下角點“在看”，還可以關注該訂閱號，防止遺漏推送哦

---

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。