視頻流中的DTS／PTS到底是什麼?
DTS（解碼時間戳）和PTS（顯示時間戳）分別是解碼器進行解碼和顯示幀時相對於SCR（系統參考）的時間戳。SCR可以理解爲解碼器應該開始從磁盤讀取數據時的時間。
mpeg文件中的每一個包都有一個SCR時間戳並且這個時間戳就是讀取這個數據包時的系統時間。通常情況下，解碼器會在它開始讀取mpeg流時啓動系統時鐘（系統時鐘的初始值是第一個數據包的SCR值，通常爲0但也可以不從0開始）。
DTS 時間戳決定了解碼器在SCR時間等於DTS時間時進行解碼，PTS時間戳也是類似的。通常，DTS/PTS時間戳指示的是晚於音視頻包中的SCR的一個時 間。例如，如果一個視頻數據包的SCR是100ms（意味着此包是播放100ms以後從磁盤中讀取的），那麼DTS/PTS值就差不多是200 /280ms，表明當SCR到200ms時這個視頻數據應該被解碼並在80ms以後被顯示出來（視頻數據在一個buffer中一直保存到開始解碼）下 溢通常發生在設置的視頻數據流相關mux率太高。
如果mux率是1000000bits/sec（意味着解碼器要以1000000bits/sec的速率 讀取文件），可是視頻速率是2000000bits/sec（意味着需要以2000000bits/sec的速率顯示視頻數據），從磁盤中讀取視頻數據時 速度不夠快以至於1秒鐘內不能夠讀取足夠的視頻數據。這種情況下DTS/PTS時間戳就會指示視頻在從硬盤中讀出來之前進行解碼或顯示（DTS/PTS時間戳就要比包含它們的數據包中的SCR時間要早了）。
如今依靠解碼器，這基本已經不是什麼問題了（儘管MPEG文件因爲應該沒有下溢而並不完全符合MPEG標準）。一些解碼器（很多著名的基於PC的播放器）儘可能快的讀取文件以便顯示視頻，可以的話直接忽略SCR。
注意在你提供的列表中，平均的視頻流速率爲～3Mbps（3000000bits/sec）但是它的峯值達到了14Mbps（相當大，DVD限制在 9.8Mbps內）。這意味着mux率需要調整足夠大以處理14Mbps的部分， bbMPEG計算出來的mux率有時候太低而導致下溢。
你計劃讓視頻流速率這麼高麼？這已經超過了DVD的說明了，而且很可能在大多數獨立播放其中都不能播放。如果你不是這麼計劃，我會從1增加mquant的值並且在視頻設置中將最大碼流設置爲9Mbps以保持一個小一點的碼流。
如果你確實想讓視頻碼率那麼高，你需要增大mux率。從提供的列表可以得出bbMPEG使用14706800bits/sec或者1838350bytes /sec的mux率（總數據速率爲：1838350bytes/sec（14706800bits/sec）行）。你在強制mux率字段設置的值應該是以
bytes/sec爲單位並被50整除。所以我會從36767（1838350/50）開始，一直增加直到不會再出現下溢錯誤爲止。
音視頻同步原理[ffmpeg]
ffmpeg對視頻文件進行解碼的大致流程：
1. 註冊所有容器格式和CODEC: av_register_all()
2. 打開文件: av_open_input_file()
3. 從文件中提取流信息: av_find_stream_info()
4. 窮舉所有的流，查找其中種類爲CODEC_TYPE_VIDEO
5. 查找對應的解碼器: avcodec_find_decoder()
6. 打開編解碼器: avcodec_open()
7. 爲解碼幀分配內存: avcodec_alloc_frame()
8. 不停地從碼流中提取中幀數據: av_read_frame()
9. 判斷幀的類型，對於視頻幀調用: avcodec_decode_video()
10. 解碼完後，釋放解碼器: avcodec_close()
11. 關閉輸入文件:av_close_input_file()
output_example.c 中AV同步的代碼如下(我的代碼有些修改)，這個實現相當簡單，不過挺說明問題。
音視頻同步-時間戳
媒體內容在播放時，最令人頭痛的就是音視頻不同步。從技術上來說，解決音視頻同步問題的最佳方案就是時間戳：首先選擇一個參考時鐘（要求參考時鐘上的時間是線性遞增的）；生成數據流時依據參考時鐘上的時間給每個數據塊都打上時間戳（一般包括開始時間和結束時間）；在播放時，讀取數據塊上的時間戳，同時參考當前參考時鐘上的時間來安排播放（如果數據塊的開始時間大於當前參考時鐘上的時間，則不急於播放該數據塊，直到參考時鐘達到數據塊的開始時間；如果數據塊的開始時間小於當前參考時鐘上的時間，則“儘快”播放這塊數據或者索性將這塊數據“丟棄”，以使播放進度追上參考時鐘）。
可見，避免音視頻不同步現象有兩個關鍵——一是在生成數據流時要打上正確的時間戳。如果數據塊上打的時間戳本身就有問題，那麼播放時再怎麼調整也於事無補。假如，視頻流內容是從0s開始的，假設10s時有人開始說話，要求配上音頻流，那麼音頻流的起始時間應該是10s，如果時間戳從0s或其它時間開始打，則這個混合的音視頻流在時間同步上本身就出了問題。打時間戳時，視頻流和音頻流都是參考參考時鐘的時間，而數據流之間不會發生參考關係；也就是說，視頻流和音頻流是通過一箇中立的第三方（也就是參考時鐘）來實現同步的。第二個關鍵的地方，就是在播放時基於時間戳對數據流的控制，也就是對數據塊早到或晚到採取不同的處理方法。圖2.8中，參考時鐘時間在0-10s內播放視頻流內容過程中，即使收到了音頻流數據塊也不能立即播放它，而必須等到參考時鐘的時間達到10s之後纔可以，否則就會引起音視頻不同步問題。
基於時間戳的播放過程中，僅僅對早到的或晚到的數據塊進行等待或快速處理，有時候是不夠的。如果想要更加主動並且有效地調節播放性能，需要引入一個反饋機制，也就是要將當前數據流速度太快或太慢的狀態反饋給“源”，讓源去放慢或加快數據流的速度。熟悉DirectShow的讀者一定知道，DirectShow中的質量控制（Quality Control）就是這麼一個反饋機制。DirectShow對於音視頻同步的解決方案是相當出色的。但WMF SDK在播放時只負責將ASF數據流讀出並解碼，而並不負責音視頻內容的最終呈現，所以它也缺少這樣的一個反饋機制。
音視頻同步通訊SDK源碼包分享：
Android：http://down.51cto.com/data/711001
Windows：http://down.51cto.com/data/715497
Linux：http://download.csdn.net/detail/weixiaowenrou/5169796
IOS：http://down.51cto.com/data/715486
WEB：http://down.51cto.com/data/710983