摘 要： 針對H.323 視頻會(huì)議系統(tǒng)設(shè)計(jì)了一種基于RTP 的音視頻同步方法，該方法在嚴(yán)格遵守RTP 協(xié)議的前提下，將音視頻數(shù)據(jù)聯(lián)系起來通過同一個(gè)媒體通道傳輸，從而達(dá)到唇音同步的目的。實(shí)驗(yàn)表明：該方法在對圖像質(zhì)量影響很小的情況下，很好地實(shí)現(xiàn)了音視頻的同步播放，并且具有實(shí)現(xiàn)簡便，不增加系統(tǒng)負(fù)擔(dān)等優(yōu)點(diǎn)，具有廣泛的實(shí)用性。

　　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ī)定一對連接只能傳輸音頻或者視頻中的一種，通過同一個(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)方案是，將音頻按一定的對應(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ì)如下：

　?。?） 發(fā)送端分別獨(dú)立的對音視頻信息進(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)行請求丟包重傳、亂序重排等網(wǎng)絡(luò)異常處理［5，6］，然后進(jìn)入組幀緩沖等待解碼器取走數(shù)據(jù)，進(jìn)入組幀緩沖的數(shù)據(jù)沒有亂序包和重包，偶有丟包；（5） 音視頻各自拆包組幀，實(shí)現(xiàn)過程如圖2 所示：

　　圖2 組幀同步實(shí)現(xiàn)原理圖。

　?。?） 音視頻從各自的解碼緩沖隊(duì)列中按順序取數(shù)據(jù)送解碼，通過組幀過程中給音視頻數(shù)據(jù)加上的本地時(shí)戳來校準(zhǔn)后同步播放。