摘要：針對網絡傳輸中由於延遲、抖動、網絡傳輸條件變化等因素引起的音視頻不同步的問題，設計並實現了一種適應不同網絡條件的音視頻同步方案。利用音視頻編碼技術AMR-WB和H.264具有在複雜網絡環境中速率可選擇的特性，結合RTP時間戳和RTCP反饋檢測QOS，通過控制音視頻編碼方式，實現了動態網絡環境下的音視頻同步方案。重點介紹了可靠網絡環境和動態網絡環境下同步算法的設計過程，並通過實際測試驗證了此方案的可行性。結果表明，此方案能夠保證不同網絡環境中的音視頻同步。
引言
音視頻媒體間同步是多媒體系統服務質量（QoS）研究中的一項重要內容。在網絡上傳輸多媒體數據時，由於終端對數據的處理方式，以及網絡中的延時、抖動，會引起音視頻流的不同步。傳統的解決方案往往存在實時性差，時間開銷大，且無法適應動態網絡環境等缺陷，針對此問題，本文在分析媒體間同步性定義、影響因素等的基礎上，提出了一種基於循環緩衝隊列和RTCP反饋控制的同步解決方案。
1 媒體間同步性定義
同步是多媒體通信的主要特徵，也是其重要研究內容之一，同步與否直接影響多媒體通信的質量。媒體間同步即是要保持音頻流和視頻流之間的時間關係[1]。爲了描述同步，實現相關的控制機制，定義了相應的服務質量參數（QoS）。針對音視頻，採用時間差即偏差來表示。結果表明，如果偏差限制在一定的範圍內，認爲媒體是同步的。當偏移在-90ms（音頻滯後於視頻）到+20ms（音頻超前視頻）之間時，人感覺不到試聽質量的變化，這個區域可以認爲是同步區域；當偏移在-185到+90之外時，音頻和視頻會出現嚴重的不同步現象，此區域認爲是不同步區域。本設計認爲偏移在-120ms到+40ms之間音視頻同步。
1.1 音視頻同步的影響因素
在網絡環境下，多媒體信息在傳輸過程中受到各種因素的影響，會導致其在接收端不能正確播放，即音視頻不同步。引起音視頻不同步的原因主要有兩種：一種是終端處理數據引起的，發送端在數據的採集、編碼、打包等模塊和接收端在處理解包、解壓、回放等模塊時，由於音頻和視頻的數據量以及編碼算法不同而引起的時間差。並且發送端沒有統一的同步時鐘；另一種是網絡傳輸延時，網絡傳輸是受到網絡的實時傳輸帶寬、傳輸距離和網絡節點的處理速度等因素的影響，在網絡阻塞時，媒體信息不能保證以連續的“流”數據方式傳輸，特別是不能保證數據量大的視頻信息的連續傳輸，從而引起媒體流內和流間的失步[2-3]。
2 音視頻同步系統設計
在音視頻同步系統中，發送端在發送音視頻流時，要給各幀數據打上相對時間戳，並且音頻流和視頻流，一個作爲主流，另一個作爲從流。主流連續播放，從流的播放由主流的播放狀態決定，從而實現同步。考慮到人對聲音更爲敏感，在本設計中選擇音頻流作爲主流，視頻流作爲從流。發送端通過AMR-WB和H.264編碼模塊對DirectShow採集到的音視頻數據進行編碼，經過同步處理，最後利用RTP/RTCP等協議實現媒體流的傳輸和控制。接收端接收到RTP傳過來的音視頻數據包後，對數據進行解碼，然後同步處理，最後通過DirectShow播放音視頻。
3 音視頻同步方案設計
考慮到傳統的同步方案只是在接收端通過RTP時間戳實現同步，即將具有相同時間戳的音視頻數據同時表現出來，這種方案由於沒有從有效控制和適應不同網絡環境的角度去實現，並且讀寫時間戳的開銷太大，需要全網同步時鐘等缺陷，因此不適應於音視頻媒體間同步[4]。針對此問題，這裏提出一種結合發送端，利用RTP/RTCP以及可控音視頻編碼技術，適用於不同網絡條件的同步方案。主要表現在以下兩方面：1、發送端數據的採集、編碼即發送控制；2、利用RTCP的反饋指標，通過可控速率的音視頻編碼算法動態適應不同的網絡環境。
3.1 RTP時間戳同步
在網絡暢通時，網絡傳輸時延基本恆定，抖動很小，發送端和接收端的音視頻幀間間隔基本保持一致，媒體數據基本沒有丟失。由於音視頻的RTP之間無直接關聯的控制，所以不能通過關聯控制同步。此時主要利用RTP包頭的時間戳來解決。
在發送端，同一媒體內的時間戳控制：針對音頻的不同採樣速率和視頻的不同幀率來動態的控制時間戳的遞增速率；不同媒體間的同步控制：同一時間採集到的數據打上同樣的時間戳，並在同一線程裏交替發送音視頻數據包。
在接收端，當音視頻數據到達時，先對兩種數據幀進行解碼，在將其解碼數據存入各自的動態循環緩衝區中。因爲音頻和視頻的每個數據幀解碼時間不能準確得到，爲了準確地實現音視頻同步回放，採取先解碼再同步處理的方法。在網絡暢通時，可以把兩種數據的解碼時間差作爲抖動延時的一部分來處理。但是，在網絡環境不好時，不採用這種方法處理。
（1）接收端對音頻幀的處理如下：
圖一 接收音頻幀示意圖
如圖一所示，爲了消除抖動，接收端採用基於循環緩存區的方法保證音頻的連續性。這種方法有兩個優點：一是可以根據RTP數據的接收情況動態的建立緩存空間，二是可以保證緩存中有足夠的音頻數據用於播放。接收端接收到音頻幀時，首先對其解碼，並存入動態的循環緩衝區中，循環緩存塊節點數的門限值爲N，該值比預計最長抖動時間要大。開始啓動播放音頻前，首先把緩衝區充滿，然後定時提取音頻幀播放，並記錄當前播放的時間戳。
（2）接收端對視頻幀的處理如下：
圖二 接收視頻幀示意圖
如圖二所示，視頻幀到達時，接收端對其解碼後，將解碼數據存入循環緩衝區。爲了避免高速視頻畫面出現的塊效應，本系統採用事件驅動的方式來播放視頻流。當緩衝區接收到一個視頻數據包時，把該幀的時間戳TVIDEO與當前待播放的音頻數據的時間戳TAUDIO進行比較。本設計中規定音視頻幀不同步的容忍度爲TMAX=120ms。因此對一幀視頻數據的處理結果分爲以下三種：若TAUDIO-TMAX<TVIDEO<TAUDIO+TMAX,就播放該視頻幀。
若TVIDEO<TAUDIO-TMAX，視頻幀滯後，就丟棄該幀。
若TVIDEO>TAUDIO+TMAX，視頻幀超前，等待下一次定時讀取音頻幀時再處理。
接收端對視頻幀進行同步處理的實現代碼如下：
OnRTPPacket ( RTPPacket *pack,
const RTPTime &receivetime,
const RTPAddress *senderaddress )
{
size_t buffsize=pack->GetPayloadLength();
memset(m_buf,0,MAX_PACKET_SIZE);
//接收視頻流的RTP數據包 memcpy(m_buf,(void*)pack->GetPayloadData(),buffsize);
//對視頻數據進行同步處理
m_psynvideo->Issynvideo(TAUDIO,m_buf);
switch(Issyn)
case 1: //播放該視頻幀
m_pVideoOut->ReceiveVideo(m_buf,buffsize);
break;
case 2:
delete(m_buf); //視頻幀滯後，丟棄該幀
break;
case 3:
waite(m_buf);//視頻幀超前，等待下次處理
break;
}
}
3.2 RTCP反饋控制
當網絡環境較差，無法爲系統提供RSVP時，音視頻流不能按原定的傳輸速率傳送，否則會出現數據包丟失嚴重的情況，這時需要採用RTCP來進行反饋控制。即利用RTCP的發送報告SR和接收報告RR包監測QOS[5]。
接收端將RR包發送給源端，該報告包含用來估算分組丟失和分組延遲抖動等必要信息。源端根據這些信息控制媒體數據的發送量，及時有效地解決同步問題。
根據評估RR包的參數，得到長時指標丟包率和短時指標間隔抖動。當丟包率和抖動達到一定值時：音頻方面，當網絡丟包率和抖動達到某一區域時，選擇不同的AMR-WB傳輸速率，來降低音頻傳輸碼率，提高傳輸效率和系統容量，爲視頻傳輸減少了帶寬負擔。
視頻方面，根據不同值調整視頻數據的發送量，即在發送端對視頻的空域和時域性能進行平衡，選擇丟幀：
（1）當丟包率和抖動很高，即信道速率很低時，通過降低視頻幀率，使每一幀能夠具有較好的空域質量，使用戶在較低的速率條件下，任然可以得到較好的圖像質量。
（2）當丟包率和抖動保持在中等水平，即信道速率中速時，在保持一定的空域質量條件下，應優先考慮時域質量，增強視頻的連續性。
（3）當丟包率和抖動回到較好的水平，即信道速率較高時，在空域質量達到一定程度後，繼續提高空域質量，效率不會太高，反而是圖像連續性的提高對視頻質量的改善更明顯。
4 例子：
AnyChat採用動態緩衝技術，會根據不同的網絡狀況實時調節緩衝區的大小，在實時性和流暢性之間保持平衡。
當網絡狀況較好時，AnyChat會減小緩衝區的容量，提高音視頻的實時性；
當網絡狀況較差時，AnyChat會增大緩衝區的容量，這樣會帶來一些延遲的增加，但是能保障音視頻的流暢性，有效消除網絡抖動對音視頻播放質量的影響；
根據實際網絡測試，AnyChat的音視頻延遲指標如下：
網絡狀態較好時(無丟包，網絡延遲<=10ms)：<1s
網絡狀態一般時（無丟包，網絡延遲<=50ms）：<=1s, >=0.5s
網絡狀態較差時（丟包率<=5%，網絡延遲<=100ms）：<=1.5s
網絡狀態較好時（無丟包，網絡延遲<10ms）：<100ms
網絡狀態一般時（無丟包，網絡延遲<50ms）：<=100ms
網絡狀態較差時（丟包率<=5%，網絡延遲<100ms）：<=250ms
網絡狀態很差時（丟包率<=20%，網絡延遲<500ms）：<=1100ms
注：上述指標爲發言模式下的測試值，如採用放歌模式，則內核爲了保障播放的流暢性，會適當增加緩衝區大小，導致延遲增大。
AnyChat Platform Core SDK V4.6對延遲進行了優化，局域網環境下，實時高清視頻（720P，25fps）通話延遲<100ms。
5 結論
本文設計實現了一種適應不同網絡環境的音視頻同步方案。設計中利用RTP時間戳及循環緩衝區在可靠網絡環境下對音視頻進行同步，以及在動態網絡環境下，利用RTCP反饋控制來動態改變音視頻編碼方式的同步方案。此方案已經成功應用於作者開發的網絡多媒體終端上，保持了較低的丟包率，保證了終端之間多媒體信息的傳輸質量。