媒 體內容在播放時，最令人頭痛的就是音視頻不同步。從技術上來說，解決音視頻同步問題的最佳方案就是時間戳：首先選擇一個參考時鐘（要求參考時鐘上的時間是 線性遞增的）；生成數據流時依據參考時鐘上的時間給每個數據塊都打上時間戳（一般包括開始時間和結束時間）；在播放時，讀取數據塊上的時間戳，同時參考當 前參考時鐘上的時間來安排播放（如果數據塊的開始時間大於當前參考時鐘上的時間，則不急於播放該數據塊，直到參考時鐘達到數據塊的開始時間；如果數據塊的 開始時間小於當前參考時鐘上的時間，則“儘快”播放這塊數據或者索性將這塊數據“丟棄”，以使播放進度追上參考時鐘）。
圖 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在附近的一家遊戲廳碰頭。你們又不同步了，但在遊戲廳將來的某個時間點你們還是會再次同步的。
悟出什麼道理了沒有？其實，同步是一個動態的過程，是一個有人等待、有人追趕的過程。同步只是暫時的，而不同步纔是常態。人們總是在同步的水平線上振盪波動，但不會偏離這條基線太遠。
本文轉自：http://blog.csdn.net/happydeer/archive/2004/12/06/206765.aspx