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