[轉]音頻視頻同步

本篇文章轉自吉林大學碩士論文。

 

5.5接收端音視頻的同步控制
5.5.1媒體內同步控制算法
爲保證媒體內同步性，對音頻，採用基於播放時限的同步方法，在接收終端設置音頻接收緩衝區(Jitter buffer)。緩衝區設定一個門限值M，該值比預計最長抖動時間要大。門限值M的大小可經過公式5.1計算：

其中，d_{max 、}d_min 分別是媒體單元經過網絡的最大、最小延遲，r爲數據傳輸速率。在系統接收端，開始時，語音數據在緩存中積累，直到緩存大小達到M。而後纔可提取播放。對視頻流，爲更利於達到媒體間同步，正常狀況下，採用到達事件驅動的方式播放視頻流，而不採用定時讀取的方式。
5.5.2媒體間同步控制算法
系統中各媒體流採用的是虛軸(virtual axes)模型，即音視頻流有各自的時間軸，發送時各幀打上相對時間戳(RTS)。考慮兩個流，一個主流，一個從流，主流連續播放，從流的播放由主流的播放狀態決定，從而實現同步。對於音頻流和視頻流，因爲聽覺對聲音的不連續比視覺對圖像不連續的敏感程度要高，於是選擇音頻流爲主流，視頻流爲從流，音頻流連續播放。經過調整視頻播放過程實現媒體間同步控制。當RTP幀到達接收端後，隨後被送至相應的解碼器進行解碼。因爲每一個數據幀的複雜度不相同，所以不可能精確知道解壓縮所消耗的時間。此處採用兩種方案，並對兩種方案分別進行討論。方案一：計算延遲抖動時未進行解壓，解壓時間不做爲網絡延遲的一部分，這樣延抖動能夠真正反映網絡擁塞狀況，如圖5-7所示；方案二：爲準確地控制回放時間，數據包在進行同步以前應由軟件解碼器進行解壓縮。這樣解壓縮時間做爲網絡延遲的一部分，解壓後的時間做爲數據包的到達時間。

 

 

 

按照方案一系統音視頻同步播放過程及視頻播放算法以下：
1．首先，回放開始時，定時從音頻緩衝區中取出語音包，送入音頻設備播放，並記錄當前播放幀的時間戳T_play。這樣作的好處是考慮語音的敏感性(這裏暫不考慮音頻播放的時間)。同時當新的音頻數據分組到達，被加到緩存中時，只要沒有分組的時延超過M（見5.5.1）個緩存單元，緩存中就有足夠的數據用於連續播放。
2．視頻幀到達時，把該幀的時間戳T_v與T_play比較。規定音視頻幀不一樣步的容忍度爲T_av=120ms。若T_play-T_av≤T_v≤T_play+T_av，就播放該視頻幀。若T_v<T_play-T_av，視頻幀滯後，就丟棄該幀。若T_v>T_play+T_av，視頻幀超前，重複播放前一幀，等待下一次定時讀取音頻幀時再處理。3．這裏音頻的播放速率必定，不考慮終端工做負載的變化。若用緩存的方式來讀取視頻數據，當畫面出現高速運動的物體時，數據會大量緩衝，形成畫面出現嚴重的塊效應，所以，正常狀況下，採用到達事件驅動的方式播放視頻流，而不採用定時讀取的方式。爲了防止音頻流失步時，出現視頻流數據丟棄較爲嚴重的現象，系統中必須優先保證音頻流的同步，而且可以連續播放。視頻處理算法以下：
HandVideoFameArrival：//視頻幀到達
if(getVideoFrame(v)//取出視頻幀
{
    If（T_v<T_play-T_av）//滯後，丟棄；
    else if(T_v>T_play+T_av)//超前；
   {
     VideoFrameWaitNum++；//緩存區待處理數據包數目加1
     play(last_v);
   }
   else play(v)//音視頻同步，播放視頻
}
音頻處理算法以下：
HandleAudioFrameTime：//定時時間到
getAudioFrame(a)；//取出音頻幀
Aplay=getCurrentPlayingAudioTimestamp；//獲得正在播放的音頻幀時間戳
play(a)；//送入音頻設備播放
對方案二，同步控制見流程圖5-8，視解碼時間爲網絡時延的一部分，考慮到媒體數據解碼時沒法保留RTP包頭信息，特別是時間戳信息，故而在處理RTP包的同時將時間戳信息提取保存，其它步驟同方案一。