轉自：http://tieba.baidu.com/p/2138076570
摘要：針對網絡傳輸中由於延遲、抖動、網絡傳輸條件變化等因素引起的音視頻不同步的問題，設計並實現了一種適應不同網絡條件的音視頻同步方案。利用音視頻編碼技術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）接收端對音頻幀的處理如下：
SHAPE
\* MERGE FORMAT
音頻數據到達
數據解碼、存儲
音頻播放
N個緩沖區
定時提取
圖一 接收音頻幀示意圖
如圖一所示，為了消除抖動，接收端采用基於循環緩存區的方法保證音頻的連續性。這種方法有兩個優點：一是可以根據RTP數據的接收情況動態的建立緩存空間，二是可以保證緩存中有足夠的音頻數據用於播放。接收端接收到音頻幀時，首先對其解碼，並存入動態的循環緩沖區中，循環緩存塊節點數的門限值為N，該值比預計最長抖動時間要大。開始啟動播放音頻前，首先把緩沖區充滿，然后定時提取音頻幀播放，並記錄當前播放的時間戳。
（2）接收端對視頻幀的處理如下：
SHAPE
\* MERGEFORMAT
視頻數據到達
解碼存儲
幀提取
比較
播放
丟棄
延時
圖二 接收視頻幀示意圖
如圖二所示，視頻幀到達時，接收端對其解碼后，將解碼數據存入循環緩沖區。為了避免高速視頻畫面出現的塊效應，本系統采用事件驅動的方式來播放視頻流。當緩沖區接收到一個視頻數據包時，把該幀的時間戳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:
wait(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反饋控制來動態改變音視頻編碼方式的同步方案。此方案已經成功應用於作者開發的網絡多媒體終端上，保持了較低的丟包率，保證了終端之間多媒體信息的傳輸質量。