Python php linux mysql 开源 google shell centos java apache 微软 Windows Ubuntu nginx 编程 Android wordpress 程序员 Firefox 云计算

直播疑難雜癥排查(5)— 音畫不同步

1. 音畫不同步的表現

很容易判斷,就是畫面和聲音不匹配。

2. 音畫同步的基礎概念

首先我們要明白一個概念,雖然人的肉眼,很容易辨別音畫是否同步的,但是機器則不然,對於播放器而言,它判斷一幀視頻和一幀音頻是否要在同一個時間渲染和播放,依靠的完全是該數據攜帶的時間戳信息。

如果內容的生產端給音視頻數據打的時間戳本身就有問題的話,播放器也往往無能為力了,因此,音畫不同步問題,更多的時候,應該從生產端去排查原因。

3. 音畫不同步的問題排查

3.1 采集源距離太遠

如果音頻源離麥克風距離太遠,聲音傳播到麥克風的速度遠小於畫面(光速),那麽,攝像頭采集到畫面後給出的時間戳,肯定要遠小於麥克風采集到同一時刻音頻給出的時間戳,因此會產生音畫不同步問題。

解決方案:音頻源盡可能離麥克風設備近一點。

3.2 采集設備內部問題

攝像頭和麥克風采集音視頻,在硬件上都會經過一些信號處理模塊,如果處理延時不穩定的時候,則會導致輸出數據的時間不穩定,從而導致應用層獲取時間戳的時候產生誤差,帶來音畫不同步問題。

解決方案:極少數硬件/機型才會有,需要根據采集參數(如采樣率)做一些 Jitter 抖動的矯正。

3.3 時間戳沒有在采集的時候獲取 

如果音視頻幀的時間戳不是在采集的時候獲取,而是在後續的某個環節再獲取,則非常大概率地會出現音視頻不同步問題。

先舉個簡單的例子:

假設音頻 A 和 視頻 B 同時從設備中被采集出來,時間戳為:TA 和 TB,他們差值會很小,播放端收到後會認為是同一時刻的音視頻數據,從而一起播放。

但是,當 音頻 A 和 視頻 B 分別經過某些算法處理模塊後,我們 “不慎” 在處理後重新獲取當前時間戳為了 TA2 和 TB2,那麽,這個更新後的時間戳差值可能會非常大,導致音畫不同步。

那麽,一般大家會 “不慎” 在哪些地方更改了采集的時間戳呢 ?

- 音視頻算法處理模塊

比如:視頻經過美顏、編碼後,重新更新為了處理後的的時間戳。

- 緩沖區導致的不同步

多線程程序中,往往會在不同線程之間共享一些幀緩沖區,緩沖區會導致音視頻對應關系發生變化,如果從緩沖區取數據後,拋棄掉了原有的時間戳,重新使用新的當前時間,那麽,肯定會出現問題。

- 網絡傳輸導致的不同步

由於網絡的傳輸的延時、丟包等原因,同一時刻的音視頻包不會正好同時準確到達,如果在接收到了數據後再打上當前的時間戳,則肯定也會出現不同步問題。

3.4 時間戳出現回退或者紊亂

曾經有遇到過一些音畫不同步的流,我把它的音視頻時間戳打印出來後顯示如下的結果:

wKioL1ka_C6BW2NCAAIWJyjJMK0738.png

該碼流的時間戳沒有單調遞增,而是頻繁出現了回退,這樣的流,會導致播放器出現頻繁卡頓,因為播放器的 master 主時鐘一般是單調遞增的,當出現小於主時鐘的視頻幀後,一般會做丟棄處理,畫面不更新但是音頻還是在繼續播放,從而導致看起來聲音和畫面並沒有匹配上的問題。 

解決方案:排查推流端時間戳是否單調線性遞增,或者排查服務端是否有對流的時間戳有過修改導致回退。

為了方便以後更好地定位該問題,大家可以修改 ffplay 源碼,把讀取到的每一幀音頻、視頻的時間戳打印出來看看,這裏我給出我對 ffplay 的修改 commit 記錄,大家可以參考一下:

https://github.com/Jhuster/pili-ffmpeg/commit/4d0476faba5016b291c2eed2c0a2cd6fe303bd50

3.5 播放端性能問題

比如低端機型軟解 1080P 的高清碼流,會存在解碼不夠及時的問題,導致部分視頻解碼完成後,已經遠慢於當前的音頻時鐘,只能丟棄,從而導致畫面更新不及時,與正在播放的音頻無法匹配上,從而產生音畫不同步的現象。

解決方案:使用硬解,選擇較低清的碼流,增大播放緩沖,等等。

延伸阅读

    评论