直播疑難雜症排查(5)— 音畫不同步
本文是《直播疑難雜症排查》系列的第五篇文章,我們重點來看看直播中常見的音畫不同步問題。
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/4d0476faba5016b291c2eed2c0a2cd6fe303bd503.5 播放端性能問題
比如低端機型軟解 1080P 的高清碼流,會存在解碼不夠及時的問題,導致部分視頻解碼完成後,已經遠慢於當前的音頻時鐘,只能丟棄,從而導致畫面更新不及時,與正在播放的音頻無法匹配上,從而產生音畫不同步的現象。
解決方案:使用硬解,選擇較低清的碼流,增大播放緩衝,等等。
4. 小結
關於播放出現音畫不同步的問題排查大致就介紹道這裡了,有任何疑問歡迎來信 lujun.hust@gmail.com 交流,另外,歡迎關注我的新浪微博 @盧_俊 或者 微信公眾號 @Jhuster 獲取最新的文章和資訊。
推薦閱讀:
※猛攻吃貨人群,今日頭條短視頻營銷戰場上的突擊戰!
※國內有沒有適合青少年觀看的性教育視頻?
※三個月前,我嘗試破解了圓形構圖