所有的基于網路傳輸的音視頻采集播放系統都會存在音視頻同步的問題，作為現代互聯網實時音視頻通信系統的代表，WebRTC 也不例外，本文將對音視頻同步的原理以及 WebRTC 的實作做深入分析，

時間戳 (timestamp)

同步問題就是快慢的問題，就會牽扯到時間跟音視頻流媒體的對應關系，就有了時間戳的概念，

時間戳用來定義媒體負載資料的采樣時刻，從單調線性遞增的時鐘中獲取，時鐘的精度由 RTP 負載資料的采樣頻率決定，音頻和視頻的采樣頻率是不一樣的，一般音頻的采樣頻率有 16KHz、44.1KHz、48KHz 等，而視頻反映在采樣幀率上，一般幀率有 25fps、29.97fps、30fps 等，

習慣上音頻的時間戳的增速就是其采樣率，比如 16KHz 采樣，每 10ms 采集一幀，則下一幀的時間戳，比上一幀的時間戳，從數值上多 16 x10=160，即音頻時間戳增速為 16/ms，而視頻的采樣頻率習慣上是按照 90KHz 來計算的，就是每秒 90K 個時鐘 tick，之所以用 90K 是因為它正好是上面所說的視頻幀率的倍數，所以就采用了 90K，所以視頻幀的時間戳的增長速率就是 90/ms，

時間戳的生成

音頻幀時間戳的生成

WebRTC 的音頻幀的時間戳，從第一個包為 0，開始累加，每一幀增加 = 編碼幀長 (ms) x 采樣率 / 1000，如果采樣率 16KHz，編碼幀長 20ms，則每個音頻幀的時間戳遞增 20 x 16000/1000 = 320，這里只是說的未打包之前的音頻幀的時間戳，而封裝到 RTP 包里面的時候，會將這個音頻幀的時間戳再累加上一個隨機偏移量（建構式里生成），然后作為此 RTP 包的時間戳，發送出去，如下面代碼所示，注意，這個邏輯同樣適用于視頻包，

視頻幀時間戳的生成

WebRTC 的視頻幀，生成機制跟音頻幀完全不同，視頻幀的時間戳來源于系統時鐘，采集完成后至編碼之前的某個時刻（這個傳遞鏈路非常長，不同配置的視頻幀，走不同的邏輯，會有不同的獲取位置），獲取當前系統的時間 timestamp_us_ ，然后算出此系統時間對應的 ntp_time_ms_ ，再根據此 ntp 時間算出原始視頻幀的時間戳 timestamp_rtp_ ，參看下面的代碼，計算邏輯也在 OnFrame 這個函式中，

為什么視頻幀采用了跟音頻幀不同的時間戳計算機制呢？我的理解，一般情況音頻的采集設備的采樣間隔和時鐘精度更加準確，10ms 一幀，每秒是 100 幀，一般不會出現大的抖動，而視頻幀的幀間隔時間較大采集精度，每秒 25 幀的話，就是 40ms 一幀，如果還采用音頻的按照采樣率來遞增的話，可能會出現跟實際時鐘對不齊的情況，所以就直接每取一幀，按照取出時刻的系統時鐘算出一個時間戳，這樣可以再現真實視頻幀跟實際時間的對應關系，

跟上面音頻一樣，在封裝到 RTP 包的時候，會將原始視頻幀的時間戳累加上一個隨機偏移量（此偏移量跟音頻的并不是同一個值），作為此 RTP 包的時間戳發送出去，值得注意的是，這里計算的 NTP 時間戳根本就不會隨著 RTP 資料包一起發送出去，因為 RTP 包的包頭里面沒有 NTP 欄位，即使是擴展欄位里，我們也沒有放這個值，如下面視頻的時間相關的擴展欄位，

音視頻同步核心依據

從上面可以看出，RTP 包里面只包含每個流的獨立的、單調遞增的時間戳資訊，也就是說音頻和視頻兩個時間戳完全是獨立的，沒有關系的，無法只根據這個資訊來進行同步，因為無法對兩個流的時間進行關聯，我們需要一種映射關系，將兩個獨立的時間戳關聯起來，

這個時候 RTCP 包里面的一種發送端報告分組 SR (SenderReport) 包就上場了，詳情請參考 RFC3550，

SR 包的其中一個作用就是來告訴我們每個流的 RTP 包的時間戳和 NTP 時間的對應關系的，靠的就是上邊圖片中標出的 NTP 時間戳和 RTP 時間戳，通過 RFC3550 的描述，我們知道這兩個時間戳對應的是同一個時刻，這個時刻表示此 SR 包生成的時刻，這就是我們對音視頻進行同步的最核心的依據，所有的其它計算都是圍繞這個核心依據來展開的，

SR 包的生成

由上面論述可知，NTP 時間和 RTP 時間戳是同一時刻的不同表示，只是精度和單位不一樣，NTP 時間是絕對時間，以毫秒為單位，而 RTP 時間戳則和媒體的采樣頻率有關，是一個單調遞增數值，生成 SR 包的程序在 RTCPSender::BuildSR(const RtcpContext& ctx) 函式里面，老版本里面有 bug，寫死了采樣率為 8K，新版本已經修復，下面截圖是老版本的代碼：

計算的思路如下

首先，我們要獲取當前時刻（即 SR 包生成時刻）的 NTP 時間，這個直接從傳過來的引數 ctx 中就可以獲得：

其次，我們要計算當前時刻，應該對應的 RTP 的時間戳是多少，根據最后一個發送的 RTP 包的時間戳 last_rtp_timestamp_ 和它的采集時刻的系統時間 last_frame_capture_time_ms_，和當前媒體流的時間戳的每 ms 增長速率 rtp_rate ，以及從 last_frame_capture_time_ms_ 到當前時刻的時間流逝，就可以算出來，注意，last_rtp_timestamp_ 是媒體流的原始時間戳，不是經過隨機偏移的 RTP 包時間戳，所以最后又累加了偏移量 timestamp_offset_ ，其中最后一個發送的 RTP 包的時間資訊是通過下面的函式進行更新的：

音視頻同步的計算

因為同一臺機器上音頻流和視頻流的本地系統時間是一樣的，也就是系統時間對應的 NTP 格式的時間也是一樣的，是在同一個坐標系上的，所以可以把 NTP 時間作為橫軸 X，單位是 ms，而把 RTP 時間戳的值作為縱軸 Y，畫在一起，下圖展示了計算音視頻同步的原理和方法，其實很簡單，就是使用最近的兩個 SR 點，兩點確定一條直線，之后給任意一個 RTP 時間戳，都可以求出對應的 NTP 時間，又因為視頻和音頻的 NTP 時間是在同一基準上的，所以就可以算出兩者的差值，

上圖以音頻的兩個 SR 包為例，確定出了 RTP 和 NTP 對應關系的直線，然后給任意一個 rtp_a，就算出了其對應的 NTP_a，同理也可以求任意視頻包 rtp_v 對應的 NTP_v 的時間點，兩個的差值就是時間差，

下面是 WebRTC 里面計算直線對應的系數 rate 和偏移 offset 的代碼：

在 WebRTC 中計算的是最新收到的音頻 RTP 包和最新收到的視頻 RTP 包的對應的 NTP 時間，作為網路傳輸引入的不同步時長，然后又根據當前音頻和視頻的 JitterBuffer 和播放緩沖區的大小，得到了播放引入的不同步時長，根據兩個不同步時長，得到了最終的音視頻不同步時長，計算程序在 StreamSynchronization::ComputeRelativeDelay() 函式中，之后又經過了 StreamSynchronization::ComputeDelays() 函式對其進行了指數平滑等一系列的處理和判斷，得出最終控制音頻和視頻的最小延時時間，分別通過 syncable_audio_->SetMinimumPlayoutDelay(target_audio_delay_ms) 和 syncable_video_->SetMinimumPlayoutDelay(target_video_delay_ms) 應用到了音視頻的播放緩沖區，

這一系列操作都是由定時器呼叫 RtpStreamsSynchronizer::Process() 函式來處理的，

另外需要注意一下，在知道采樣率的情況下，是可以通過一個 SR 包來計算的，如果沒有 SR 包，是無法進行準確的音視頻同步的，

WebRTC 中實作音視頻同步的手段就是 SR 包，核心的依據就是 SR 包中的 NTP 時間和 RTP 時間戳，最后的兩張 NTP 時間-RTP 時間戳 坐標圖如果你能看明白（其實很簡單，就是求解出直線方程來計算 NTP），那么也就真正的理解了 WebRTC 中音視頻同步的原理，如果有什么遺漏或者錯誤，歡迎大家一起交流！

「視頻云技術」你最值得關注的音視頻技術公眾號，每周推送來自阿里云一線的實踐技術文章，在這里與音視頻領域一流工程師交流切磋，

標籤：其他

上一篇：Kilo 使用教程

下一篇：如何在 Istio 中支持 Dubbo、Thrift、Redis 以及任何七層協議？