H.323 視頻會議系統中，發送端同時采集到的音視頻數據能在接收端同時播放，則認為唇音同步。終端采集到的音視頻數據肯定是同步的，要保證同時播放，就要保證音視頻在采集和播放處理過程中消耗的時間相同。IP 網絡的特點決定了通過不同通道的音視頻數據傳輸所消耗的時間不可能完全相同，唇音同步是視頻會議系統中的一大難題。如果同時采樣的音視頻數據播放時間偏差在[-80ms,+80ms]以內，用戶基本上感覺不到不同步， 一旦超出[-160ms,+160ms],用戶就可以明顯感覺到，中間部分是臨界范圍。
1 引言
1.1 文章安排
本文第2 節分析了現有的音視頻同步方案的缺點。第3 節詳細描述了本文所設計方案的實現過程。第4 節給出實驗數據以及分析結果。第5 節給出結論。
1.2 基本介紹
H.323 視頻會議系統中，音視頻不同步現象產生的原因除了網絡環境外，還有一個是音視頻的分開傳輸。雖然H.323 建議音視頻通過不同道道傳輸，但是實際傳輸數據的RTP[2,3]協議和其底層的UDP 協議都沒有規定一對連接只能傳輸音頻或者視頻中的一種，通過同一個通道傳輸音視頻完全可能，而且這樣可以最大程度的減少網絡原因引起的音視頻不同步，本文給出了這一設想的實現方案，并做了驗證。
2 現有解決方案
目前最常用的唇音同步方法從思路上可以分為以下兩類：
思路一，發送端給每個要發送的RTP 包打上時戳，記錄它們的采樣時間。接收端通過增加延時等方式，保證同時采樣的數據同時播放。這類方法的實現需要一個中立的第三方參考時鐘，需要有RTCP 協議的SR[2,3]的參與， 如果這兩個條件不具備，同步就失去了依據。
思路二，唇音不同步本質上是由H.323 視頻會議系統中音視頻的分開傳輸和處理導致的，如果采用某種方法將音視頻信息關聯起來，就可以有效的避免不同步現象。一種實現方案是，將音頻按一定的對應關系嵌入到視頻中傳輸，接收端從視頻中提取音頻數據并重建，從而達到唇音同步的目的[4].該方案實現較復雜，而且采用非標準的RTP 實現方式，會給不同廠商H.323 產品間的互通帶來困難。
3 一種新的音視頻同步方法
本方法基本思路是：在音視頻數據的采樣、編碼、打包、發送、網絡傳輸、接收、網絡異常處理、拆包、解碼、播放這十個處理過程中，采集、編碼、打包、拆包和解碼的時間基本上固定，不會因為網絡環境差異造成時延的差異，而發送、網絡傳輸、接收、網絡異常處理四個過程則具有較大的隨機性，其處理時間會隨著網絡性能的不同有較大的差異，進而造成播放時音視頻的不同步。因此唇音同步處理的重點就在于保證發送、網絡傳輸、接收、網絡異常處理這四個過程中音視頻的同步，即圖1 中發送同步到組幀同步之間的部分。
圖1 唇音同步實現全過程
其他處理過程引起的時間差，只要在系統穩定后給音頻加上固定的延時即可，因為一般情況下，音頻處理所花的時間比視頻處理少，具體的差值可多次實驗統計得到。
RTP 協議規定每個RTP 包中所承載的有效載荷類型（PT）是唯一的，但是如果將音視頻通過同一個通道傳輸，并且保證同一時刻采集到的音視頻幀順次交錯發送，則既能保證音視頻在傳輸中的同步，又遵守了RTP 協議。音頻數據量較小，一個RTP 包即能承載一幀，一個視頻幀則需要多個RTP 包承載，幀結束標志采用RTP 包頭中的Mark 字段，該字段為1,則說明當前包是一幀的結束包。
依據上述思想，方案具體實現過程設計如下：
（1） 發送端分別獨立的對音視頻信息進行采樣，組幀和打包，然后放到各自的緩沖隊列中等待發送（2） 數據發送模塊從發送緩沖中取數據，1） 從音頻緩沖隊列中取一個包（一幀）；2） 從視頻緩沖隊列中取數據，每取一個包，都判斷RTP 包頭的Mark 字段是否為1,如果為1,說明當前視頻幀已經取完，轉1），如果Mark 字段為0,說明當前視頻幀還未取完，轉2）；（3） 音視頻數據通過同一個通道發送到網絡；（4） 接收端收到數據，根據包頭中的PT 字段區分音視頻，放到各自的接收緩沖隊列中進行請求丟包重傳、亂序重排等網絡異常處理[5,6],然后進入組幀緩沖等待解碼器取走數據，進入組幀緩沖的數據沒有亂序包和重包，偶有丟包；（5） 音視頻各自拆包組幀，實現過程如圖2 所示：
圖2 組幀同步實現原理圖。
（6） 音視頻從各自的解碼緩沖隊列中按順序取數據送解碼，通過組幀過程中給音視頻數據加上的本地時戳來校準后同步播放。
丟包判斷實現細節說明：
在終端的可靠性和代碼的健壯性得到保證的前提下，發送端是不可能有包序號不連續的，對于接收端，本方案中的丟包，是指經過丟包重傳等網絡異常處理策略之后依然存在的丟包，必然是及其少量的。本方法中的音頻采樣、組幀和打包是分開處理的，即音視頻RTP包號分別連續，所以一般情況，依據各自的包序號即可判斷是否有丟包。而對于一個會話中收到的第一個媒體包即丟失的情況，一旦出錯，可能導致音視頻播放時間整體錯位。本文通過發送端所加的RTP 包頭中的時戳來避免這種情況，時間戳的計算公式如下：
Timestamp（0） = （unsigned long） r and（）；
Timestamp（t）=Timestamp（0）+△T*fr eq /1000;
△T = T（t） – T（0），時間差，單位： ms;freq: 采樣頻率；
H.323 視頻會議中，與會各方的編解碼協議、采樣率、幀率等參數在打開通道后的能力協商階段即已確定，要改變這些參數，必然要重新能力協商，而任何時候應用層都知道協商的結果。所以只要規定一個會話中發送的頭一個音頻包和頭一個視頻包的時戳相同，即可由時戳來建立音視頻包的對應關系。實際上，視頻數據頭一幀的圖像分成多個包傳輸，這幾個包具有相同的時戳，同時丟失的可能性很小。而且視頻組幀解碼過程中，還要分I 幀、P 幀和B 幀區別處理，比如每個GOP 中只要I 幀丟失，其后的P 幀和B 幀都必須丟棄，直到收到下一個I 幀，這已經超出了本文的研究范圍，此處不再詳述。
4 理論分析和結果驗證
理論上講，采用本方法后，在網絡狀態良好時能做到音視頻傳輸中的完全同步。網絡狀態惡化時，隨著丟包率的增加，同步效果會稍微變差，其中隨機丟包比周期丟包對同步效果的影響更明顯，這是因為隨機丟包會引起更多的網絡抖動。而在幀率碼率和編解碼協議不變的情況下。帶寬越小，網絡越容易擁塞，所以帶寬降低時同步效果也會變差。
將本方案應用在開源的H.323 協議棧OPENH323 上[7],實現了一個簡單的基于PC 機的H.323 桌面終端。兩臺終端建立會話，通過IP cloud 在兩臺終端間模擬各種復雜惡劣的網絡環境，然后使用Wireshark 抓包，可以看到音視頻包的發送接收時間以及有關包頭信息，進而計算出傳輸中引起的音視頻偏差時間。考慮到算法的復雜度，本方案選擇了相對較易實現的H.261 和GSM6.10 作為音視頻編解碼協議。圖3 是呼叫建立后在發送端10.21.11.121 上截的圖。發送端敲擊麥克風，接收端看到敲擊動作的同時聽到敲擊聲，同步效果良好。
圖3 驗證平臺--終端互通實現效果圖。
終端10.21.11.121 在正常網絡環境下，以512k的帶寬呼叫終端10.21.11.152,呼叫建立5 分鐘之后用Wireshark 抓到的音視頻數據包如圖4 和圖5 所示：
圖4 發送端音視頻數據抓包。
圖5 接收端音視頻數據抓包。
隨機選取了20 個這樣的音視頻組合，測得傳輸引起的音視頻時間差值，求的平均值為0.000051s,即51μs.可以認為，在正常情況下，傳輸階段不會引起失步。
多次改變呼叫帶寬和網絡丟包率，反復試驗，得到的不同環境下由傳輸引起的音視頻時間差如表1 所示。
表1 不同環境下由傳輸引起的音視頻時差（單位：μs）。
由表1 中的數據可以看出，隨著丟包率的增大，音視頻失步有所增加。并且相同丟包率下，隨機丟包對同步效果的影響更明顯，這和理論分析的結果完全吻合。但是即便在播放階段還有2%丟包這樣惡劣的環境下，傳輸引起的音視頻時間差仍然低于1000us.
即： 該方法將[-80ms,+80ms] 的同步范圍的159/160 留給音視頻處理和組幀解碼階段。
理論上講，低帶寬高丟包環境下，使用該方法后視頻質量會有所下降。這是因為，本文的算法增加了視頻幀被丟棄的概率。如圖4 所示，每個CIF 格式的視頻幀需要4 個H.261 的RTP 包來傳輸，其中任意一個包丟失都會使該幀成為無用幀被丟棄。采用了本文的同步策略后，如果該視頻幀對應的音頻包丟失，該幀也會被丟棄。這一點可以根據系統的實際需求做出取舍，比如用前一個包的重復播放來代替丟掉的音頻包，而這樣會增加音頻播放的滯頓感。這些問題正在進一步研究中。
5 結語
本方法最大的亮點在于很好的實現了音視頻同步的同時，最大程度的遵守了RTP 協議和H.323 標準。
此外，該方法實現簡便、可以和現有的唇音同步方案同時使用、并且不會額外增加系統的負擔，具有很大的實用價值。
