RTMP 直播流延遲優化：ffplay 與 VLC 表現差異分析及解決方案

現象描述

• ffplay 播放：初始延遲約 4 秒，滑鼠右鍵點擊幾下後延遲大幅降低，近乎同步。控制台輸出 [swscaler @ ...] deprecated pixel format used... 警告。
• VLC 播放：畫面卡頓後跳幀，穩定延遲 8-10 秒。

核心問題排查

1. 時間戳（PTS/DTS）計算邏輯

你的實現：pts = tnow - t0（相對於第一幀的時間差）。潛在風險：

• 系統時間抖動、NTP 同步導致 tnow 非單調遞增。
• 編碼幀率波動時，固定間隔假設失效。
• 缺乏 DTS（解碼時間戳），B 幀場景下解碼順序錯誤。

建議：使用編碼器內部時鐘（如 x264 的 i_pts），或基於固定幀率累加 pts += frame_duration，確保單調遞增。

2. ffplay 右鍵點擊延遲降低之謎

swscaler deprecated pixel format 提示像素格式轉換問題。右鍵菜單觸發重繪，可能迫使 ffplay 刷新緩衝區、重新協商像素格式，間接清理了積壓幀。這說明解碼/渲染管線存在積壓。

3. VLC 高延遲根因

VLC 預設啟用較大的網絡緩衝（network-caching 默認 1000ms+）和解碼緩衝。RTMP 服務端若未正確發送 onMetaData、|RtmpSampleAccess 或關鍵幀間隔過大，VLC 會保守地緩衝更多數據。

解決方案

1. 服務端優化：
   • 強制固定 GOP（關鍵幀間隔），如 2 秒一個 IDR 幀。
   • 發送完整的 onMetaData（width, height, framerate, videocodecid 等）。
   • 確保 PTS/DTS 單調遞增，DTS ≤ PTS。
2. 播放端參數調優：
   • ffplay：-fflags nobuffer -flags low_delay -framedrop -probesize 32 -analyzeduration 0
   • VLC：工具 → 偏好設定 → 輸入/編碼器 → 緩衝值調小（如 300ms），或使用命令行 --network-caching=300。
3. 替代播放器：PotPlayer、MPV、ExoPlayer (Android) 在低延遲 RTMP 表現通常優於 VLC。

關鍵建議

先用 FFprobe 分析你的 RTMP 流結構（ffprobe -show_streams -show_packets rtmp://...），確認關鍵幀間隔、時間戳連續性、Metadata 完整性。問題多半在推流端而非播放端。