可能是全網最全的移動直播 trouble shooting 手冊（5）——音畫不同步

在七牛做直播 SDK 一年多了，幫助客戶解決過各種形形色色的問題，如直播卡頓、馬賽克、花屏、黑屏、雜音、音畫不同步等等等等，這其中，有一些是網路原因，有一些是客戶的使用姿勢問題，有一些是引數配置錯誤，當然，也有一些是 SDK 本身的問題。

總結下來，如果開發者能夠對直播領域的一些基礎知識有更深入的瞭解，掌握一些基本的排障手段，很多問題是能夠很快自行解決的，甚至也能夠更好地防患於未然。

因此，有了這個系列，我想把這一年多以來，幫助我們的直播客戶排查問題的實戰經驗逐步分享出來，同時也會穿插一些音視訊開發的基礎知識和優化經驗，真心希望能夠幫助到直播領域的開發者們。

本系列會涵蓋的內容包括但不限於如下一些主題：

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

音畫不同步的表現

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

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

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

導致音畫不同步的因素有很多，以下是直播實戰中經常遇到的問題的整理。

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

解決方案：音訊源儘可能離麥克風裝置近一點。

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

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

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

先舉個簡單的例子：
假設音訊 A 和視訊 B 同時從裝置中被採集出來，時間戳為：TA 和 TB，他們差值會很小，播放端收到後會認為是同一時刻的音視訊資料，從而一起播放。

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

那麼，一般大家會「不慎」在哪些地方更改了採集的時間戳呢？

1.視訊演算法處理模組

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

2.緩衝區導致的不同步

多執行緒程式中，往往會在不同執行緒之間共享一些幀緩衝區，緩衝區會導致音視訊對應關係發生變化，如果從緩衝區取資料後，拋棄掉了原有的時間戳，重新使用新的當前時間，那麼，肯定會出現問題。

3.網路傳輸導致的不同步

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

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

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

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

為了方便以後更好地定位該問題，大家可以修改 ffplay 原始碼，把讀取到的每一幀音訊、視訊的時間戳列印出來看看，這裡我給出我對 ffplay 的修改 commit 記錄，大家可以參考一下：github.com/Jhuster/pil…

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

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

關於播放出現音畫不同步的問題排查大致就介紹到這裡了，下篇我們將對馬賽克嚴重這個話題進行探討。