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