目錄

實驗環境

測試項說明

測試結果

競品分析

總結

                    QOS FEC NACK 實時音視訊傳輸庫測試報告

• QOS-FEC-NACK傳輸庫簡介

QOS-FEC-NACK是一套集FEC前向糾錯、QOS、NACK選擇性重傳、JitterBuff、位元速率自適應等技術於一體的實時音視訊傳輸解決方案。方案基於私有的UDP協議，以庫或原始碼的方式提供使用者，其介面簡潔可快速整合到使用者現有音視訊系統之中。方案使用C++開發支援Windows、Android（JNI）、Ios、Linux系統，支援X86、ARM  32位、64位平臺。

QOS-FEC-NACK庫特別適合在需要在弱網（4G、Wifi）下進行可靠、實時音視訊傳輸的領域。它具有以下特點：

1. 自適應FEC冗餘度，根據當前網路狀況自適應調整冗餘度，提高抵抗力同時避免頻寬浪費。
2. 自適應FEC Group配置，對不同時刻、不同特徵的媒體資料使用不同的FEC Group策略，在不增加抖動的前提下提升連續丟包的抵抗力。
3. 選擇性NACK重傳，只對預期無法恢復的資料包發起重傳，最大限度避免擁塞和抖動。
4. 自適應NACK等待時間選取，內建NACK信令、資料處理，對外層黑盒。
5. 無延時的亂序、重複包處理。
6. JittBuff自適應快取處理，抵抗網路抖動，提供流暢輸出。
7. 位元速率/幀率自適應建議輸出
8. IDR幀請求建議輸出
9. 丟幀凍結機制支援
10. 提供丟包率、位元速率、RTT等上下行基礎統計資料獲取
11. 針對嵌入式等資源受限平臺設計，資源佔用低，執行效率高。編碼規範、程式碼精簡、註釋完善，不依賴於任何第三方開源或閉源庫。

       本文件使用一個點對點投屏DEMO對方案進行各項弱網模擬測試，研究各種弱網特徵下傳輸層的表現情況。文件最後對行業內優秀解決方案：騰訊雲、聲網Agora  WebRtc等進行了研究。

• 實驗環境

       為了保證測試環境一致性和可重現性，我們將在較好的網路環境下藉助第三方弱網模擬工具，模擬各類網路情況。同時也會使用訊號較弱的wifi搭建真實的弱網環境。

       這裡列舉Windows平臺上常用的兩款弱網模擬工具：

       A、Network Emulator for Windows Toolkit

       該工具是一款windows平臺弱網模擬工具，使用說明可以參考以下連結：

                           

                                            圖1 Network Emulator for Windows Toolkit工具

軟體提供：丟包、包篡改、延時、頻寬限制、亂序、斷網等功能。

注意事項：

    1、我們按照上面連結搭建測試工程後，發現實際未生效。解決辦法是載入程式安裝包自帶的樣例XML配置（ConsoleToConsole2PercentPacketloss.xml），在此配置基礎上修改為自己的測試需求。

      2、如上圖所示，測試項可以作用於本機輸入也可以作用於本機輸出。比如對Outgoing的丟包設定將對本機發出的包進行丟包，適合在傳送端使用。而對Incoming的丟包設定將對本機收到的包進行丟包，適合在接收端使用。對待測應用程式而言，在傳送端丟包還是接收端丟包沒有差異，本次實驗均在傳送端進行弱網測試。

                                                      

                                                                                                             

                                                                    圖2 在傳送和接收處模擬弱網

     B、Clumsy

    Clumsy是一款小巧而功能強大的開源弱網模擬工具，支援windows平臺，可用於模擬：丟包(Drop)、延時(Lag)、重複(Duplicate)、亂序(Out of order)、篡改(Tamper)、抖動(Throttle)等。其專案地址：

                                               

                                                    圖3 Clumsy對所有傳送的包按10%進行丟包處理示意

    本次測試主要使用Clumsy，相比使用Network Emulator for Windows Toolkit，二者測試結論基本一致。

• 測試DEMO說明

      本次測試使用windows平臺下的桌面投屏DEMO，DEMO分為傳送端和接收端，傳送端採集自身桌面和揚聲器音訊，壓縮後通過QOS-FEC-NACK 點對點SDK發往接收端，後者解碼並渲染輸出，從而實現螢幕共享功能。

A、接收端

     該組DEMO的功能與投屏類應用類似，我們首先啟動接收端DEMO。進入UDP-AVClient-ScreenPlay資料夾，雙擊啟動AVClient.exe即可。

                                           

                                                               圖4 接收端DEMO啟動介面

       接收端啟動後，將顯示其投屏碼（圖中的4000），傳送端可以使用該投屏碼進行投屏。當傳送端碼流到來時，接收端將使用一個新的視窗“Remote Video”顯示遠端畫面，如下圖所示：

                                                     

                                                         圖5 接收端獨立的視窗展示遠端畫面

      注意：“Remote Video”視窗是一個全屏視窗，使用者可以自行在底部工作列切換。當遠端停止音視訊傳輸時，該視窗內容無更新，且不會響應滑鼠事件，只能底部切換。

      接收端資料夾下的AVClient.ini檔案為其配置檔案，對配置檔案的修改需要重啟客戶端方能生效。配置檔案包括如下幾項：

                                                             

                                                                    圖6 接收端配置檔案

       UseFreezeFrameWhenLost 表示當出現視訊丟包無法恢復時，為了不展現出花屏而將畫面凍結，直至完整的關鍵幀到來再繼續送顯。該值一般設定為1開啟。

       BufferTime表示接收Jitter buff快取毫秒數，為了抵抗網路傳輸、FEC恢復、QOS亂序恢復、NACK重傳等行為帶來的抖動，接收端需要加入快取以保障視訊的流暢性。流暢性和實時性（時延）是一對矛盾的指標，Jitter buff必然將引入一定延時，當前預設為200ms。

       CaptureDownStream表示是否開啟錄製功能，若開啟則將接收到的音視訊流錄製到TS檔案。測試過程中建議關閉。

       FecEnableNack表示本端視訊是否開啟NACK功能，建議開啟以提高視訊抗丟包能力。

      Debug組下是日誌相關的配置，比如path指定日誌檔案存放的路徑，level表示當前期望輸出的日誌級別，常用級別有DEBUG, INFO, WARN, ERROR。enable表示是否啟動日誌功能，建議啟用。

       在後面的測試過程中，將會對部分配置進行調整，檢視調整前後的效果對比。

B、傳送端

傳送端為UDP-AVClient-ScreenCap目錄下的AVClient.exe，在啟動前我們需要先對其進行配置，配置檔案為AVClient.ini

                                                            

                                                                      圖7 傳送端配置檔案

VideoBitrate表示傳送端使用的視訊編碼位元速率，單位kbps，設定為3000即表示3Mbps

VideoTransWidth表示傳送端使用的視訊編碼寬度，VideoTransHeight表示視訊編碼高度，ViceFrameRate表示視訊編碼幀率（本程式使用Direct桌面採集，在效能較低的機器上採集幀率無法達到30fps，編碼幀率仍然會按30fps配置編碼器）

RemoteIpAddr表示接收端的IP地址，請按自己接收端實際情況進行配置。

EncodeQualityLevel0to7表示當採用X264軟編碼時，使用的preset級別，0表示ultrafast，1表示superfast，2表示veryfast，3表示faster，4表示fast，5表示medium，6表示slow，7表示slower。等級越高同等位元速率下的影象質量越好，但CPU佔用也越高，請根據自身機器配置而定，建議設定為1。

HWEnable表示是否啟用硬編碼，程式支援Intel QSV硬編碼和Nvidia硬編碼，相比X264能獲得更低的CPU佔用。不過硬編碼的缺點是靈活性不足，無法支援傳輸層IDR幀請求機制。

FecRedunRatio表示上行FEC使用的冗餘度，比如設定為30時表示使用30%的上行冗餘，設定為0時表示使用自動冗餘度。

FecGroupSize表示上行FEC使用的group標準分組大小。為了獲得最佳效果，分組大小建議與位元速率想匹配。512Kbps以下建議設定為8，512Kbps~1Mbps建議設定為16，1Mbps~2Mbps建議設定24，2Mbps~4.5Mbp建議設定28，4.5Mbps以上建議34。注：當關閉自動group策略時，每個group大小均為該值設定值。當開啟傳輸層自動group策略時，將產生非均勻大小的group，此時該值用來表示最小的group大小。

FecEnableNack表示是否啟用NACK選擇性重傳機制。收發雙方均開啟時方能生效，建議雙方均開啟以提高系統抗丟包能力。

IDR幀間隔：當使用X264編碼時，傳送端使用5秒一個IDR幀。當使用硬編碼時，傳送端使用3秒一個IDR幀。

啟動傳送端後進入如下介面，輸入接收端展示的投屏碼即可開始連線。注意：收發雙方並無TCP連線，這裡的連線可以理解為本地UDP資源的建立。

                                                         

                                                                           圖8 傳送端啟動介面

       連線後，客戶端將進入下圖所示的待共享螢幕狀態。可以點選主介面啟動按鈕或者使用懸浮球來啟動桌面共享。啟動後，接收端就能看到傳送端的桌面並能聽到傳送端播放的音樂了。

                                                     

                                                                            圖9 傳送端開始共享桌面

• 測試項說明

說明：同市面上各大實時視訊服務商一樣，DEMO也提供丟幀凍結機制，這樣使用者無法察覺到丟幀帶來的花屏，從而獲得更好的使用者體驗。因此本次測試中，丟包最終將體現為畫面卡頓。DEMO提供了傳送端位元速率自適應功能，傳輸層根據當前的網路狀況實時調整發送幀率，從而達到間接調整位元速率的目的。相比直接調整編碼位元速率，調整幀率有如下優點和缺點：

優點：

A、相比直接調整位元速率，更難察覺質量跳變。

B、無需適配各個平臺的硬體編碼器，各個平臺均可以採用統一的幀率調整方案。

缺點：

A、畫面流暢性受到影響

評測項：流暢度

關於流暢度，我們將分為以下幾個級別：

1. 畫面流暢
2. 偶爾微弱卡頓（附加：卡頓時長+頻率描述）
3. 明顯示卡頓（附加：卡頓時長+頻率描述）
4. 較長時間卡頓

評測項：延時

       延時計算方式：在傳送端開啟毫秒精度秒錶，接收端將看到秒錶值，使用手機對二者螢幕拍照，計算二者差值得到總延時。整個系統中，延時主要有非傳輸層延時和傳輸層延時兩部分組成。非傳輸層延時包括：採集、編碼、解碼、渲染引入的延時，本DEMO實際採集幀率無法達到恆定30fps，對整體延時稍有影響。

       傳輸層延時又分為：相對穩定部分和抖動延時部分。其中接收端Jitter buff程式加入的快取延時屬於相對穩定部分。網路線路傳輸延時、QOS亂序等待時間、NACK重傳等待時間、FEC恢復等待時間、畫面凍結等待時間屬於抖動延時部分，抖動延時只在該動作發生時引入，且動作完成後消失。QOS亂序發生時才會引入等待，比如收到1、2、4號包，輸出1、2後會進入等待，若此期間收到3號包則輸出3、4，若超出等待時間仍未收到3號包則直接輸出4號包，即便後續收到3號包也將其丟棄。若當前丟包無法恢復時，即會觸發NACK重傳，接收方進入NACK等待，等待期間收到了重傳包則輸出，否則等待超時後退出。FEC有group組的概念，冗餘包位於組的尾部，前部媒體包的丟失需要等待尾部冗餘包的到來方能恢復輸出，因此FEC解碼在丟包時也會引入抖動，FEC group越大引入的抖動也越大，不過在同等冗餘率下抗連續丟包的能力也越強。當NACK、FEC均無法恢復時，將凍結畫面並請求遠端傳送IDR，只有收到完整的IDR幀時才恢復送解碼、渲染，這裡也將引入抖動延時。編碼器Gourp越大，“可能”需要的IDR等待時間越長（當接收端主動請求的IDR幀也出現丟包時，只能依靠編碼器自身的週期性IDR幀。當接收端主動請求IDR幀傳輸成功時，等待時間和編碼器自身的週期性IDR間隔無關。）

       需要說明的是延時指標和流暢性指標往往是一對矛盾，播發端快取的資料越多，流暢性越好，延時也越大，反之若快取的資料較少或者不快取，則延時更低，流暢性不足。傳輸層需要根據實際應用場景選擇合適的策略（折中）。SDK提供API供使用者配置接收端的Jitter Buff快取毫秒數。預設情況下使用300ms快取，這是基於300ms的延時不會對雙向音視訊實時互動產生影響這一業內經驗。

評測項：清晰度

DEMO使用自適應幀率方式來間接實現位元速率自適應，因此影象質量與傳輸層無緊密關係，主要由使用者指定的編碼解析度、位元速率、桌面畫面內容決定。注：幀率降低時，幀間相關性降低，運動估計殘差更大，同等位元速率下編碼質量會稍弱。

• 測試結果

測試預設配置：

接收端使用300ms快取，具體配置入下圖所示：

[Config]

UseFreezeFrameWhenLost=1

BufferTime=300

FecEnableNack=1

傳送端使用720P  2Mbps  30fps，FEC使用自動冗餘，具體配置入下圖所示

[Config]VideoBitrate=2000VideoTransWidth=1280VideoTransHeight=720ViceFrameRate=30EncodeQualityLevel0to7=1FecRedunRatio=0FecGroupSize=28FecEnableNack=1HWEnable=0

畫面內容：全屏播放影片

丟包測試

傳送端使用Clumsy 設定傳送丟包5%、8%、12%、20%、30%，為了排除遺留影響，每次修改丟包率均在傳送端斷開連線再重新連線。

5%丟包時，連續觀察20分鐘，畫面流暢，較難感知丟包，延時穩定在300ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

8%丟包時，連續觀察20分鐘，畫面流暢，較難感知丟包，延時穩定在300ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

12%丟包時，連續觀察20分鐘，畫面流暢，較難感知丟包，延時穩定在300ms左右，，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

20%丟包時，連續觀察20分鐘，因位元速率自適應被觸發，畫面幀率逐漸下降，總體比較流暢，較低頻率偶爾卡頓，卡頓時長約300ms左右（IDR請求）。延時穩定在330ms左右。位元速率約2.2Mbps。

30%丟包時，連續觀察20分鐘，因位元速率自適應被觸發，畫面幀率逐漸下降，有較明顯的卡頓。延時穩定在400ms左右。位元速率約2.0Mbps。

                                

                                                           圖10  20%丟包時的延時情況

重複測試

測試配置A，傳送端使用Clumsy 設定Duplicate傳送重複率5%、12%、20%、30%，每次重複1包（Count設定為2）。

5%重複包時，連續觀察20分鐘，畫面流暢，延時穩定在260ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

12%重複包時，連續觀察20分鐘，畫面流暢，延時穩定在260ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

20%重複包時，連續觀察20分鐘，畫面流暢，延時穩定在260ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

30%重複包時，連續觀察20分鐘，畫面流暢，延時穩定在260ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

可見單純的重複包對系統影響很小。

亂序測試

測試配置A，傳送端使用Clumsy 設定Out of order傳送亂序率5%、12%、20%、30%。

5%亂序包時，連續觀察20分鐘，畫面流暢，延時穩定在280ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

12%亂序包時，連續觀察20分鐘，畫面流暢，延時穩定在280ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

20%亂序包時，連續觀察20分鐘，畫面流暢，延時穩定在280ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

30%亂序包時，連續觀察20分鐘，畫面流暢，延時穩定在280ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

可見單純的亂序包對系統影響很小。

延時測試

測試配置A，傳送端使用Clumsy 設定Lag傳送延時50、100、200、400、600ms。

50ms時，連續觀察20分鐘，畫面流暢，延時穩定在310ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

100ms時，連續觀察20分鐘，畫面流暢，延時穩定在340ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

200ms時，連續觀察20分鐘，畫面流暢，延時穩定在520ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

400ms時，連續觀察20分鐘，畫面流暢，延時穩定在740ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

600ms時，連續觀察20分鐘，畫面流暢，延時穩定在920ms左右，冗餘率基本維持在自動冗餘度的下限30%，位元速率平均約2.4Mbps。

線路延時最終會疊加到總體延時之上，測試結果符合預期。

抖動測試

測試配置A，分別進行以下幾項測試

A、傳送端使用Clumsy 設定Throttle  分別5%、12%、20%、30%概率抖動30ms。

測試結果：5%~30%概率30ms抖動對流暢性、延時無可感知的影響。

B、傳送端使用Clumsy 設定Throttle  分別5%、12%、20%、30%概率抖動100ms。

測試結果：5%~30%概率100ms抖動對流暢性、延時無可感知的影響。

C、傳送端使用Clumsy 設定Throttle  分別5%、12%、20%、30%概率抖動150ms。

測試結果：5%~30%概率150ms抖動對流暢性存在一定影響，幾十秒一次的可感知微弱頓挫感。

D、傳送端使用Clumsy 設定Throttle  分別5%、12%、20%、30%概率抖動200ms。

測試結果：5%~30%概率200ms抖動對流暢性存在較大影響，隨著概率的增加，30%概率時一秒一次的可感知明顯頓挫感。

       抖動達到一定程度時，超出Jitter Buff抵抗力，將出現畫面頓挫。目前版本暫未加入Jitter Buff能力自適應，使用者設定Jitter Buff深度後，即根據設定值確定快取深度，不會跟隨媒體流實際抖動自適應調整。這樣做有以下優缺點：

       優點：系統延時穩定於使用者設定值，不隨網路抖動增長而增長。

       缺點：網路抖動超出設定值時，播放器將出現卡頓。當實際抖動小於設定值時，仍然引入了設定值的延時。

抖動優化是後續傳輸層優化的方向之一。

極速測試

       當設定接收端Jitter Buff快取0ms時，即關閉接收端快取功能，收到資料第一時間解碼、第一時間渲染，此時無程式引入的延時，我們稱之為極速模式。

        設定接收端配置檔案BufferTime=0，不加入人為弱網措施時：

測試結果：連續觀察20分鐘，畫面總體比較流暢，延時穩定在94ms左右。對於延時要求較高，而對於流暢性沒有極高要求的場合可以使用極速模式。

斷網測試

本DEMO收發雙方並無TCP連線，斷開一方網路後，另一方只是無法接收或傳送媒體資料，待網路恢復後自行恢復。

• 競品分析

       實時音視訊傳輸一直是多媒體通訊的核心之一，騰訊雲、網易雲信以及部分新興企業如聲網、即構均提供了雲解決方案。各家方案各有千秋，通過相互對比借鑑，能獲得更多靈感。

網站介紹：騰訊實時音視訊（Tencent Real-Time Communication，TRTC）是騰訊雲基於QQ十多年來在音視訊通話技術上積累，提供全平臺互通高品質實時視訊通話服務的一款產品；抗丟包率超過 40%，抗網路抖動超過 1000ms，即使在弱網環境下仍然能夠保證高質量的音視訊通訊，確保視訊通話過程順暢穩定。

注意：騰訊雲、阿里雲等也提供基於RTMP\HLS的直播服務，這類基於TCP協議的直播並非本文所描述的音視訊實時互動範疇，它們往往用於對延時要求不高的單向的音視訊傳輸服務，其對弱網的抵抗力較差，在網路惡化時服務質量衰減迅速。本報告中，我們將以大牛直播RTMP傳輸為例，測試基於TCP的RTMP協議在弱網下的表現。

       騰訊實時音視訊同樣使用私有的UDP協議，目前廣泛應用於微信、QQ等產品。騰雲實時音視訊官網提供了DEMO供使用者測試，使用步驟大致如下，具體請參考騰訊文件說明：

       A、使用者需要先在騰訊雲上註冊實時音視訊服務，並在控制檯中指定音視訊引數。

       B、下載iLive SDK和配套DEMO工程，在DEMO程式碼中填寫註冊時生成的APP ID等引數並編譯可執行程式。

       使用者在騰訊雲後臺中對音視訊互動的詳細引數進行設定（注意：騰訊雲SDK並不在客戶端進行音視訊引數設定，而是在管理後臺設定，客戶端選擇後臺中的某組設定）。當前可供使用者設定的解析度最大到720P，位元速率最高到1500kbps，可能更高級別的引數需要人工客服申請。

                                  

                                                                     圖11 騰訊雲實時音視訊控制檯

                                                      

                                                               圖12 騰訊雲實時音視訊能力設定

       為了方便演示，我們在附件中提供了騰訊雲DEMO的原始碼以及一個使用我們申請測試賬號編譯的可執行程式。程式包括一個傳送端和一個接收端，傳送端將採集系統預設的攝像頭編碼後發往騰訊雲伺服器，後者轉發給接收端。

注意：為了搭建與我們DEMO類似的環境，我們使用虛擬桌面採集攝像頭作為系統預設攝像頭（執行我們DEMO後，將自動向系統註冊一個名為screen-capture-recorder的虛擬攝像頭，拔掉髮送端機器的其他攝像頭，確保讓虛擬攝像頭成為預設攝像頭）。

注意：騰訊雲並不提供P2P服務，所有音視訊均走伺服器轉發，這可能是由其收費方式決定的，對於所有使用者按使用解析度、時長收費，一個傳送端、一個接收端使用1小時，則按2*1小時計費。若提供P2P服務，並對使用者之間的P2P傳輸收取費用則於情於理說不過去。

注意：騰訊雲SDK將視訊編解碼和傳輸層一起封裝。

       正常情況下，使用720P 1.5Mbps位元速率，在無弱網模擬的情況下，連續觀察20分鐘，畫面流暢，延時穩定在140ms左右，位元速率平均約1.5Mbps。

丟包測試結果：

5%丟包時，連續觀察20分鐘，畫面流暢性有一定下降（幀率下降導致，均勻丟幀，無長時間卡頓）延時穩定在150ms左右，位元速率平均約1.6Mbps。

12%丟包時，連續觀察20分鐘，畫面流暢性進一步下降（幀率下降導致，均勻丟幀）偶爾（幾分鐘）出現明顯示卡頓，延時穩定在140ms左右，位元速率平均約1.6Mbps。

20%丟包時，連續觀察20分鐘，畫面幾秒一次頻繁卡頓（卡住約500ms左右），幀率較低，延時穩定在200ms左右，位元速率平均約1.6Mbps。

通過畫質對比，騰訊雲應該也是採用幀率自適應，並未降低位元速率，影象質量相對恆定。位元速率控制和使用者購買的非常接近，畢竟這個涉及到自身成本。延時總體較低，接收端快取較小，在丟包時因NACK引入的瞬間抖動導致畫面易出現卡頓。IDR幀間隔約為1秒。

抖動測試結果：

使用720P 1.5Mbps位元速率，30%概率引入100ms抖動，無丟包，此時畫面流暢，延時擴大到240ms左右，說明騰訊檢測到網路持續抖動後自適應的增加了接收端快取時間。當關閉抖動模擬時，延時恢復到140ms。觀察到開啟抖動模擬時，畫面會持續1~2秒的卡頓期，然後延時加大，流暢性提升，說明在此期間進行了快取的重新初始化動作。騰訊的接收快取自適應調整的策略值得我們學習。

重複測試結果：

30%重複包時，連續觀察20分鐘，畫面流暢性與未開啟時基本一致，延時穩定在140ms左右，位元速率平均約1.5Mbps。

亂序測試結果：

30%重複包時，連續觀察20分鐘，畫面流暢性與未開啟時基本一致，延時穩定在140ms左右，位元速率平均約1.4Mbps。

      網站介紹：SD-RTN是專為實時傳輸設計的虛擬通訊網路，基於UDP，延時可控。 專利演算法，極大幅提升可靠性。全球部署近 100 個數據中心， 國內數十家中小運營商全面覆蓋， 99.99% 高可用，連通率 99.9%。

      聲網實時音視訊同樣使用私有的UDP協議，基於Webrtc技術優化開發，SDK將音視訊編解碼和傳輸層封裝在一起。

                                    

                                                                    圖13 聲網DEMO下載

注意：我們選擇多人音視訊通話DEMO，Wireshark截包發現該DEMO在同一網段內走的是P2P（雖然走的P2P，但仍然按量收費）。附件中已經包括了測試DEMO執行程式。

                                              

                                                                      圖14 聲網DEMO啟動介面

       在啟動DEMO後，選擇720P  30fps解析度（這個解析度為攝像頭通訊時的解析度，本次測試我們使用螢幕共享，後者將預設使用桌面的解析度進行通訊，幀率最高只能設定15fps），並填寫一個房間號，收發雙方使用相同的房間號即可進行互通。

                                      

                                                                         圖15 使用螢幕共享功能

        我們將桌面解析度設定為720P，DEMO將自動使用720P 約800Kbps位元速率（DEMO未提供對桌面共享解析度、位元速率的設定功能），在無弱網模擬的情況下，連續觀察20分鐘，畫面因幀率15fps的緣故流暢性一般，延時穩定在240ms左右。

丟包測試結果：

5%丟包時，連續觀察20分鐘，畫面流暢性有一定下降（幀率動態變化，最低到8fps，丟幀不夠均勻，無長時間卡頓）延時穩定在400ms左右，位元速率平均約800Kbps。

12%丟包時，連續觀察20分鐘，畫面不流暢（幀率下降導致，非均勻丟幀），延時穩定在550ms左右，位元速率平均約800Kbps。

20%丟包時，連續觀察20分鐘，畫面很不流暢（非均勻丟幀，幀率在8~13fps），延時穩定在400ms左右，位元速率平均約800Kbps。

抖動測試結果：

使用720P 800kbps位元速率，30%概率引入100ms抖動，無丟包，此時畫面流暢性基本不受影響（受15fps緣故，流暢性一般），延時擴大到450ms左右，位元速率基本不變。說明聲網檢測到網路持續抖動後增加了接收端快取時間。當關閉抖動模擬較長時間後，延時仍然維持在400ms左右。這點與騰訊的處理策略不同。

重複測試結果：

30%重複包時，連續觀察20分鐘，畫面流暢性與未開啟時基本一致，延時穩定在220ms左右，位元速率平均約800kbps。

亂序測試結果：

30%重複包時，連續觀察20分鐘，畫面流暢性與未開啟時基本一致，延時穩定在220ms左右，位元速率平均約800kbps。

3、附加：QOS-FEC-NACK  15fps 720P 800Kbps版本測試

因為聲網DEMO限制，只能達到15fps，為此我們將QOS-FEC-NACK DEMO也使用同等環境。傳送端配置如下：

[Config]VideoBitrate=800VideoTransWidth=1280VideoTransHeight=720ViceFrameRate=15EncodeQualityLevel0to7=1FecRedunRatio=10FecGroupSize=28FecEnableNack=1HWEnable=0

我們使用720P 15fps 800Kbps編碼，使用固定10%的冗餘度。

接收端配置如下：

[Config]

UseFreezeFrameWhenLost=1

BufferTime=300

FecEnableNack=1

丟包測試結果：

在無弱網模擬的情況下，連續觀察20分鐘，畫面因幀率15fps的緣故流暢性一般，延時穩定在320ms左右。

5%丟包時，連續觀察20分鐘，畫面流暢性基本不受影響（幀率穩定於15fps，無長時間卡頓）延時穩定在330ms左右，位元速率平均約900Kbps。

12%丟包時，連續觀察20分鐘，畫面流暢性基本不變，偶爾有短暫頓挫感（幀率穩定於15fps，無長時間卡頓）延時穩定在400ms左右，位元速率平均約900Kbps。

20%丟包時，連續觀察20分鐘，畫面很不流暢（均勻丟幀，幀率最低降到8fps）。延時穩定在400ms左右，位元速率平均約900Kbps。

• 總結

       QOS-FEC-NACK方案可以在保障實時性前提下，有效提升音視訊在弱網下的傳輸效果，相比業內領先的解決方案，傳輸效果在某些指標上已經較為接近。相比業內以雲服務方式提供服務，QOS-FEC-NACK提供開放的介面，可以方便的加入到私有網路中。方案以庫或原始碼方式提供，相比昂貴的按時收費成本更低。