音視頻同步系列文章之——基於時間戳記的同步點

媒體內容在播放時，最令人頭痛的就是音視頻不同步。從技術上來說，解決音視頻同步問題的最佳方案就是時間戳記：首先選擇一個參考時鐘（要求參考時鐘上的時間是線性遞增的）；產生資料流時依據參考時鐘上的時間給每個資料區塊都打上時間戳記（一般包括開始時間和結束時間）；在播放時，讀取資料區塊上的時間戳記，同時參考當前參考時鐘上的時間來安排播放（如果資料區塊的開始時間大於當前參考時鐘上的時間，則不急於播放該資料區塊，直到參考時鐘達到資料區塊的開始時間；如果資料區塊的開始時間小於當前參考時鐘上的時間，則“儘快”播放這塊資料或者索性將這塊資料“丟棄”，以使播放進度追上參考時鐘）。

 

 

圖2.8 解決音視頻同步問題的時間戳記方案

 

可見，避免音視頻不同步現象有兩個關鍵——一是在產生資料流時要打上正確的時間戳記。如果資料區塊上打的時間戳記本身就有問題，那麼播放時再怎麼調整也於事無補。2.8，視頻流內容是從0s開始的，假設10s時有人開始說話，要求配上音頻流，那麼音頻流的起始時間應該是10s，如果時間戳記從0s或其它時間開始打，則這個混合的音視頻流在時間同步上本身就出了問題。打時間戳記時，視頻流和音頻流都是參考參考時鐘的時間，而資料流之間不會發生參考關係；也就是說，視頻流和音頻流是通過一個中立的第三方（也就是參考時鐘）來實現同步的。第二個關鍵的地方，就是在播放時基於時間戳記對資料流的控制，也就是對資料區塊早到或晚到採取不同的處理方法。圖2.8中，參考時鐘時間在0-10s內播放視頻流內容過程中，即使收到了音頻流資料區塊也不能立即播放它，而必須等到參考時鐘的時間達到10s之後才可以，否則就會引起音視頻不同步問題。

基於時間戳記的播放過程中，僅僅對早到的或晚到的資料區塊進行等待或快速處理，有時候是不夠的。如果想要更加主動並且有效地調節播放效能，需要引入一個反饋機制，也就是要將當前資料流速度太快或太慢的狀態反饋給“源”，讓源去放慢或加快資料流的速度。熟悉DirectShow的讀者一定知道，DirectShow中的品質控制（Quality Control）就是這麼一個反饋機制。DirectShow對於音視頻同步的解決方案是相當出色的。但WMF SDK在播放時只負責將ASF資料流讀出並解碼，而並不負責音視頻內容的最終呈現，所以它也缺少這樣的一個反饋機制。

為了更好地理解基於時間戳記的音視頻同步方案，下面舉一個生活中的例子。假設你和你的一個朋友約好了今天18:00在滬上廣場見面，然後一起吃飯，再去打遊戲。實際上，這個18:00就是你和你朋友保持同步的一個時間點。結果你17:50就到了滬上廣場，那麼你必須等你的朋友。10分鐘過後，你的朋友還沒有到，這時他打來電話說有事耽擱了，要晚一點才能到。你沒辦法，因為你已經在旁邊的餐廳預訂了位置，如果不馬上趕過去，預訂就會被取消，於是你告訴你的朋友直接到餐廳碰頭吧，要他加快點。於是在餐廳將來的某個時間點就成為你和你朋友的又一個同步點。雖然具體時間不定（要看你朋友趕過來的速度），但這樣努力的方向是對的，你和你朋友肯定能在餐廳見到面。結果呢？你朋友終於在18:30趕過來了，你們最終“同步”了。吃完飯19:30了，你臨時有事要處理一下，於是跟你朋友再約好了20:00在附近的一家遊戲廳碰頭。你們又不同步了，但在遊戲廳將來的某個時間點你們還是會再次同步的。

其實，同步是一個動態過程，是一個有人等待、有人追趕的過程。同步只是暫時的，而不同步才是常態。人們總是在同步的水平線上振蕩波動，但不會偏離這條基準太遠。