多是全網最全的移動直播 trouble shooting 手冊（5）——音畫不一樣步

時間 2019-11-30

原文原文鏈接

在七牛作直播 SDK 一年多了，幫助客戶解決過各類形形色色的問題，如直播卡頓、馬賽克、花屏、黑屏、雜音、音畫不一樣步等等等等，這其中，有一些是網絡緣由，有一些是客戶的使用姿式問題，有一些是參數配置錯誤，固然，也有一些是 SDK 自己的問題。git

總結下來，若是開發者可以對直播領域的一些基礎知識有更深刻的瞭解，掌握一些基本的排障手段，不少問題是可以很快自行解決的，甚至也可以更好地防患於未然。github

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

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

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

音畫不一樣步的表現

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

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

若是內容的生產端給音視頻數據打的時間戳自己就有問題的話，播放器也每每無能爲力了，所以，音畫不一樣步問題，更多的時候，應該從生產端去排查緣由。優化

致使音畫不一樣步的因素有不少，如下是直播實戰中常常遇到的問題的整理。編碼

若是音頻源離麥克風距離太遠，聲音傳播到麥克風的速度遠小於畫面（光速），那麼，攝像頭採集到畫面後給出的時間戳，確定要遠小於麥克風採集到同一時刻音頻給出的時間戳，所以會產生音畫不一樣步問題。線程

解決方案：音頻源儘量離麥克風設備近一點。

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

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

若是音視頻幀的時間戳不是在採集的時候獲取，而是在後續的某個環節再獲取，則很是大機率地會出現音視頻不一樣步問題。

先舉個簡單的例子：
假設音頻 A 和視頻 B 同時從設備中被採集出來，時間戳爲：TA 和 TB，他們差值會很小，播放端收到後會認爲是同一時刻的音視頻數據，從而一塊兒播放。

可是，當音頻 A 和視頻 B 分別通過某些算法處理模塊後，咱們不慎在處理後從新獲取當前時間戳爲了 TA2 和 TB2，那麼，這個更新後的時間戳差值可能會很是大，致使音畫不一樣步。

那麼，通常你們會「不慎」在哪些地方更改了採集的時間戳呢？

1.視頻算法處理模塊

好比：視頻通過美顏、編碼後，從新更新爲了處理後的的時間戳。

2.緩衝區致使的不一樣步

多線程程序中，每每會在不一樣線程之間共享一些幀緩衝區，緩衝區會致使音視頻對應關係發生變化，若是從緩衝區取數據後，拋棄掉了原有的時間戳，從新使用新的當前時間，那麼，確定會出現問題。

3.網絡傳輸致使的不一樣步

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

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

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

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

爲了方便之後更好地定位該問題，你們能夠修改 ffplay 源碼，把讀取到的每一幀音頻、視頻的時間戳打印出來看看，這裏我給出我對 ffplay 的修改 commit 記錄，你們能夠參考一下：github.com/Jhuster/pil…

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

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

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