音視頻同步是我們觀看視頻的一個基本體驗，尤其對于視頻畫面中能看到聲源動作（如：嘴型）的場景，音視頻同步問題非常影響體驗。
在短視頻與直播APP中，采集端作為音視頻的生產者，如果采集端產生的音視頻源本身就無法保證同步，那么后面不管經過什么處理，都很難再讓用戶看到音視頻同步的畫面了，因此，在采集端保證音視頻同步上尤其重要。
那么如何保證app在各種正常/非正常狀況下盡量保證輸出同步的音視頻？本文就是講述我們是如何解決上述問題的。
音視頻同步的原理
音視頻采集的數據分別來自于麥克風與攝像頭，而攝像頭與麥克風其實是兩個獨立的硬件，而音視頻同步的原理是相信攝像頭與麥克風采集數據是實時的，并在采集到數據時給他們一個時間戳來標明數據所屬的時間，而編碼封裝模塊只要不改動音視頻時間的相對關系就能保證音頻與視頻在時間上的對應。如此封裝好數據之后，播放端就能夠根據音視頻的時間戳來播放對應的音視頻，從實現音視頻同步的效果。
時間戳參考標準
取格林威治時間做為對比標準，即音視頻時間戳都為采集時間點相對于格林威治標準時間的時間差；
取系統開機時間做為對比標準，即音視頻時間戳都是采集時間點相對于手機開機時間的時間差。目前iOS上AVCaptureSession這套API就是參考這個時間標準給的時間戳。
其它時間戳標準
基于“開源項目1”的音視頻同步探討
原生某開源框架
如圖：
簡介
音/視頻被采集到之后會先經過音/視頻處理模塊，音/視頻在被處理之后才進入計算時間戳的模塊。
在第一幀到達時記一個計時起點，然后根據采集的幀間隔對接下來每一幀的時間戳進行計算：frameTimeStamp = lastFrameTimeStamp + frameDuration。
優點
能輸出frame duration穩定的音視頻時間戳。
風險
無論是音頻還是視頻，在手機過熱、性能不足等極端情況下有可能出現采集不穩定的情況，比如說預計1s采集30幀，實際只采集到28幀，而音視頻的時間戳是通過累加來計算的，這樣就有會出現音視頻不同步的情況。
Video Process（人臉檢測、濾鏡、3D貼紙）有可能無法在一幀時間內處理完當前幀，這樣就會出現幀數比預期低的情況，從而出現音視頻不同步。
幀間隔涉及到無限小數時，因為計算機的精度有限會引發的時間戳偏移，此偏移會隨著幀數的增加而逐漸被放大。
基于開源項目1的改進方案1
如圖：
時間戳的獲取方法非常直接——每一幀都在改幀進入時間戳計算模塊時獲取當前系統時間作為時間戳。
優點
APP性能正常的情況下肯定不會出現音視頻不同步；
能夠實時糾正時間戳，只要APP正常運轉，就能立即恢復正確的時間戳。
風險
依賴Video Process與Audio Process模塊處理時長相近，而實際工程中因為人臉檢測、貼紙等原因，Video Process可能會出現阻塞的情況，從而導致臨時性的音視頻不同步
在Audio Process與Video Process模塊處理幀耗時不均勻的情況下會出現音視頻時間戳不均勻的問題，能否正常播放依賴于終端
基于開源項目1的一個改進方案2
如圖：
簡介
音/視頻被采集到之后，先獲取采集模塊提供的音視頻時間戳，然后在音/視頻處理模塊透傳采集模塊獲取到的音/視頻時間戳，在時間戳計算模塊繼續透傳采集模塊給的時間戳。
優點
除非采集模塊給出錯誤數據，否則音視頻都一定是同步的。
風險
可能會出現音視頻時間戳不均勻的情況，尤其是在手機過熱、性能不足等極端情況下。
直播方向更進一步的優化探討
大致流程如圖：
簡介
音/視頻被采集到之后，先獲取采集模塊提供的音視頻時間戳，然后在音/視頻處理模塊透傳采集模塊獲取到的音/視頻時間戳。
在時間戳計算模塊透傳視頻時間戳，并根據下文中提到的方法計算音頻時間戳。
音頻時間戳計算方法
實時計算時間戳：當前時間戳=起始時間戳+幀數*幀采樣數/采樣率；
如果時間戳偏移量超出閾值，糾正時間戳；
糾正頻率達到超出閾值，直接透傳采集時間戳。
優點
能夠提供一個穩定的音頻時間戳，可以兼容幀間隔小幅抖動造成的音頻時間戳不均勻；
兼容性能不足時導致實際采集幀數低于幀率。
風險
糾正時間戳時可能會造成聲音卡頓的感覺。
總結
具體方案最好是針對實際應用場景有選擇性的做優化，比如說，在可以控制播放器策略的情況，可以考慮根據自研播放器特性做時間戳處理。而如果播放器不可控，則盡量通過策略保障幀間隔穩定。 |
