丟包判斷實現(xiàn)細(xì)節(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)惡化時，隨著丟包率的增加，同步效果會稍微變差，其中隨機(jī)丟包比周期丟包對同步效果的影響更明顯，這是因為隨機(jī)丟包會引起更多的網(wǎng)絡(luò)抖動。而在幀率碼率和編解碼協(xié)議不變的情況下。帶寬越小，網(wǎng)絡(luò)越容易擁塞，所以帶寬降低時同步效果也會變差。

　　將本方案應(yīng)用在開源的H.323 協(xié)議棧OPENH323 上［7］，實現(xiàn)了一個簡單的基于PC 機(jī)的H.323 桌面終端。兩臺終端建立會話，通過IP cloud 在兩臺終端間模擬各種復(fù)雜惡劣的網(wǎng)絡(luò)環(huán)境，然后使用Wireshark 抓包，可以看到音視頻包的發(fā)送接收時間以及有關(guān)包頭信息，進(jìn)而計算出傳輸中引起的音視頻偏差時間。考慮到算法的復(fù)雜度，本方案選擇了相對較易實現(xiàn)的H.261 和GSM6.10 作為音視頻編解碼協(xié)議。圖3 是呼叫建立后在發(fā)送端10.21.11.121 上截的圖。發(fā)送端敲擊麥克風(fēng)，接收端看到敲擊動作的同時聽到敲擊聲，同步效果良好。

　　圖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ù)抓包。

　　隨機(jī)選取了20 個這樣的音視頻組合，測得傳輸引起的音視頻時間差值，求的平均值為0.000051s，即51μs.可以認(rèn)為，在正常情況下，傳輸階段不會引起失步。

　　多次改變呼叫帶寬和網(wǎng)絡(luò)丟包率，反復(fù)試驗，得到的不同環(huán)境下由傳輸引起的音視頻時間差如表1 所示。

　　表1 不同環(huán)境下由傳輸引起的音視頻時差（單位：μs）。

　　由表1 中的數(shù)據(jù)可以看出，隨著丟包率的增大，音視頻失步有所增加。并且相同丟包率下，隨機(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ù)播放來代替丟掉的音頻包，而這樣會增加音頻播放的滯頓感。這些問題正在進(jìn)一步研究中。

　　5 結(jié)語

　　本方法最大的亮點在于很好的實現(xiàn)了音視頻同步的同時，最大程度的遵守了RTP 協(xié)議和H.323 標(biāo)準(zhǔn)。

　　此外，該方法實現(xiàn)簡便、可以和現(xiàn)有的唇音同步方案同時使用、并且不會額外增加系統(tǒng)的負(fù)擔(dān)，具有很大的實用價值。