音視頻同步更多文章
深入理解音視頻pts,dts,time_base以及時間數學公式_視頻pts計算-CSDN博客
ffplay音視頻同步分析_ffplay 音視頻同步-CSDN博客
音視頻采集打時間戳設計
實時音視頻數據的采集和處理場景。具體來說:
采集階段:
- 在音視頻數據采集過程中,需要為每一幀數據計算出時間戳。
- 可以采用"起始時間=系統時間"的方式,計算第一幀的時間戳,后續幀按照固定的幀間隔累加得到。
- 同時引入動態校正機制,檢測累計時間戳與系統時間的偏差,及時修正時間戳。
傳輸階段:
- 將計算好的時間戳與音視頻數據一起傳輸到客戶端。
播放階段:
- 客戶端接收到數據后,先將其緩存一段時間。
- 然后根據附帶的時間戳信息,按照正確的時間順序進行播放。
- 客戶端可以進一步利用時間戳信息來調整緩沖區,以適應網絡環境的變化。
這種時間戳設計方案的核心思路就是:
- 在采集端盡量保證時間戳的準確性和穩定性。后續講解如何設計穩定和準確的方案
- 將時間戳信息傳輸到客戶端,利用它來進行緩沖和時間校正。
- 通過客戶端和服務器端的協作,最終實現音視頻數據的平滑播放。
????????這是實時音視頻領域常用的一種時間戳管理策略,能夠很好地應對系統負載變化、小數誤差累積等問題。
方案推導
第一方案?直接系統時間模式
初始化 starttime = systime
frameTimeStamp = systime - start time
缺陷:涉及到音頻硬件采樣不穩定,操作系統調度和網絡傳輸的時間,導致ts準確度不夠問題且沒用糾正機制。
第二種方案?幀間隔模式
初始化 starttime = systime
frameTimeStamp = current systime - start time
Compute TimeStamp = last FrameTimeStamp + duration
優點:能輸出frame duration穩定的音視頻時間戳。
缺陷:
- 系統負載過高時,實際幀采集間隔可能與理論設定不一致。這將導致計算出的時間戳與實際情況不符,影響播放效果。
- 幀間隔涉及到無限小數時,會隨時間累積產生較大的誤差。例如預計30幀,通常按幀間隔33毫秒處理,但實際是33.3333333毫秒。累積3333幀(約111秒)就出現1秒的誤差。
第三種方案? 幀間隔+直接系統時間模式
初始化 starttime = systime? ? ? ? ? ? ? ? ????????????????????????????????????????//起始時間=系統時間
frameTimeStamp = current systime - start time? ? ? ?????????????????//第一幀時間戳= 系統時間–起始時間
Compute TimeStamp = last FrameTimeStamp + duration? ? ? ?//后續幀TimeStamp=上一幀時間戳+ 幀間隔
?T = current systime? -? starttime? ? ?//當前系統時間 – 起始時間?
if( |Compute TimeStamp - T | ?>= duraiton/2 ) ?Compute TimeStamp? = last FrameTimeStamp
//如果當前幀的計算時間戳(CurrentFrameTS)與系統時間差值(T)的絕對值大于等于一個半幀間隔,那么我們就應該將當前幀的時間戳直接設置為系統時間差值T。?
解決:動態糾正,在第二方案基礎上,解決了隨著播放幀數,時間戳落后或提前現象。落點值 =??T = current systime? -? starttime? ? ?//當前系統時間 – 起始時間。關鍵點是設置一個合理的校正閾值,這里我們使用了半幀間隔。
優點:能夠實時糾正時間戳,只要系統正常運轉,就能立即恢復正確的時間戳。
缺陷:幀間隔不均勻,能否正常播放依賴于終端解決方案。 比如,假如音頻一幀間隔為24毫秒,被采集的回調時間可能為20 毫秒,28毫秒,27毫秒,21毫秒。
終端解決這個問題,可以從以下幾個方面著手:
在客戶端使用自適應緩沖機制:
- 根據實際采集幀率的波動情況,動態調整緩沖區大小,盡量平滑播放。
在服務器端進行幀率轉換:
- 服務器可以對不同幀率的數據進行幀率轉換,輸出穩定的幀率。
- 這樣可以屏蔽掉客戶端設備性能的影響。
使用更加先進的時間戳校正算法:
- 例如利用機器學習等方法,預測并修正時間戳的偏差。
?
采集時間戳同步問題分析
在使用幀間隔+直接系統模式基礎上,發送端時間戳記錄:
- 記錄每一幀音視頻數據的pts時間戳和pts_duration幀間隔
- 同時記錄相鄰幀之間的系統時間間隔 sys_duration
- 這樣可以分析在采集階段,幀間隔的穩定性
分析發送端時間戳:
- (1) ptsd(pts_duration)波動大,說明采集幀間隔不穩定,可能是由于系統負載波動等因素引起的
- ???????幀間隔 pts_duration 波動很大,那么意味著每幀數據被實際采集的時間間隔是不穩定的。這通常是由于系統負載波動、硬件性能波動等因素引起的,導致采集過程不夠穩定。
- (2) pts穩定,但sysd(sys_duration)波動大,說明在數據發送過程中,速率不夠穩定可能是網絡傳輸過程中出現了抖動.
- ???????這里的 pts 時間戳是相對穩定的,意味著數據在采集端生成時間戳是比較準確的。但是,相鄰幀之間的系統時間間隔 sys_duration 卻出現了波動,說明在數據發送過程中,速率不夠穩定。這種情況通常是由于網絡傳輸過程中出現了抖動,導致實際發送速率不夠平滑。
- (3) sysd和ptsd的值應該較為一致,如果兩者差異較大,說明在整個采集-傳輸過程中存在問題
- ???????比如: [send]audio:1-pts:20ms-ptsd:24ms; sysd=23ms
接收端時間戳記錄:
- 接收到的幀信息包含: 幀序號、pts時間戳、pts_duration幀間隔
- 同樣記錄了相鄰幀的系統時間間隔 sys_duration
分析接收端時間戳:
- (1) ptsd(pts_duration)波動大,說明采集幀間隔不穩定
- (2) pts穩定,但sysd(sys_duration)波動大。說明在數據發送過程中,速率不夠穩定
- 比如: [recv] audio:1-pts:20ms-ptsd:24ms; sysd=23ms 200ms
總結核心思路是:
- 在發送端和接收端同時記錄時間戳信息,包括pts時間戳和系統時間
- 通過對這些時間戳數據的分析,可以全面診斷出音視頻同步過程中的各種問題
- ptsd異常 采集端的幀間隔不穩定
- pts穩定下 sysd異常 推流端的數據傳輸速率不穩定,存在網絡傳輸過程中的抖動。
?
?學習資料分享
0voice · GitHub