本文是 《直播疑難雜癥排查》系列的第五篇文章，我們重點來看看直播中常見的音畫不同步問題。

1. 音畫不同步的表現

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

2. 音畫同步的基礎概念

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

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

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

3.1 采集源距離太遠

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

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

3.2 采集設備內部問題

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

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

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

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

先舉個簡單的例子：

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

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

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

- 音視頻算法處理模塊

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

- 緩沖區導致的不同步

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

- 網絡傳輸導致的不同步

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

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

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

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

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

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

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

3.5 播放端性能問題

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

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

4. 小結

關於播放出現音畫不同步的問題排查大致就介紹道這裏了，有任何疑問歡迎來信 [email protected] 交流，另外，歡迎關註我的新浪微博 @盧_俊 或者 微信公眾號 @Jhuster 獲取最新的文章和資訊。

本文出自 “Jhuster的專欄” 博客，請務必保留此出處http://ticktick.blog.51cto.com/823160/1926436

直播疑難雜癥排查（5）— 音畫不同步