近年來由於全球性的新冠疫情，世界各地對實時音視訊的需求猛增。不同國家和地區由於經濟發展、國家政策等原因，網路環境有很大不同，如果要做好音視訊體驗，就需要分地域進行音視訊指標測試。但是不論是外包，還是雲測，都無法滿足我們對質量的要求。
本文將介紹在當前新冠疫情下，聲網是如何對海外不同地區進行音視訊自動化測試，並獲得可靠的指標結果。
本文為「Dev for Dev 專欄」系列內容，作者為聲網音視訊實驗室 Android 開發工程師 胡大化。
01 傳統音視訊測試方法已不適用
以測視訊延時為例，以前我們通常的做法是：首先找一個網路時鐘，然後讓傳送端、接收端兩臺手機進行視訊通話，並且用傳送端手機拍攝這個時鐘，然後接收端就看到網路時鐘的畫面。我們將網路時鐘的時間，減去接收端手機顯示的時鐘時間，就是這一幀視訊的延時。如圖 1.1 所示：
■圖1.1 當前幀延時為315ms
這種測試方法需要測試人員到現場去佈置測試裝置。然而在當前疫情環境下，很難派員工去海外出差進行實地場測。
02 為何不外包給海外測試團隊？
你可能會想到既然不能派員工去海外出差，可不可找當地人幫忙，或者外包給當地專業的測試團隊？
這種策略我們也考慮過。但音視訊測試不同於一般的軟體黑盒測試，在測試過程中實測用例很多，每個用例都要調不同的引數，外部測試團隊很難達到我們平時測試時關注細節的程度，另外他們也不具備測試音視訊所需要的專業知識。無法保證測試結果準確可靠。再者不同國家和地區由於語言時區等原因，協調的成本極高。
03 藉助雲測進行自動化測試
我們嘗試使用雲測供應商在海外不同地區部署的手機做測試，在這些手機安裝測試程式，在國內通過遠端桌面或自動化指令碼控制手機進行音視訊通話。
大的雲測廠商如 Headspin 在國外幾十個國家地區都有部署雲測手機，但云測手機與真機不同，有很多限制：比如攝像頭被遮住，就無法使用那些通過攝像頭採集進行視訊傳輸的測試用例了。因此我們需要設計一套不使用攝像頭測音視訊指標的方案。我們想到了通過自採集 YUV 視訊的方式測試視訊指標。
採用自採集 YUV 的方式，實現了兩個雲測手機之間視訊傳輸，那怎麼才能得到視訊傳輸的效能指標呢？如延時、卡頓、位元速率、幀率等。使用 YUV 自採集的方式，沒有獨立的時鐘源可以參考，測延時必須要解決兩個手機對時問題。我們嘗試通過 NTP 伺服器或區域網對時兩種方案。如果兩個手機都在一個區域網下，通過區域網對時會非常精準，我們在本地實測兩個手機之間交換資料包往返延時 rtt<10ms，而且在同一個區域網內上行和下行鏈路速度一樣，那麼實際對時偏差應該<2ms。這符合我們對精度的要求。
但是有的雲測供應商兩個手機之間無法通過區域網通訊，比如 Headspin 就不可以。這時我們考慮用 NTP 方式對時。NTP 對時誤差在幾十毫秒，相比區域網大很多，如果超過 50ms，就會對我們測延時影響很大，我們希望對時偏差<50ms。如何做到這一點？通過查閱 NTP 官方文件得知，只要對時時 rtt 足夠小，就可以實現。rtt 與對時偏差的關係如下圖 1.2 所示（來源於 NTP 官網）:
■圖1.2 NTP 對時中 rtt 與對時偏差的關係
從上面可以看出，只要往返延時 rtt 控制 100ms 以內，對時偏差-10ms<offset<10ms，這樣兩個手機的對時偏差不會超過 20ms，符合我們的要求。實際環境下能否做到 rtt<100ms 呢？通過實測我們發現完全可以做到。在上海通過阿里雲的 NT P伺服器（ntp.aliyun.com）對時，rtt 在 30ms 左右，很少超過 60ms。
在海外，以印度新德里為例，使用當地的 NTP 伺服器（time.nplindia.org）rtt 也容易在 30ms 以下。因此我們只要使用當地或距離比較近的 NTP 伺服器對時，精度都可以滿足要求。在程式實現時我們可以多次對時，取 rtt<100ms 時的最小值。
解決了對時問題後，需要知道視訊幀的傳送時間和接收到的時間。我們可以在傳送端把傳送時間畫在視訊幀上，接收端把當前時間以浮窗形式蓋在接收到的視訊幀上，對接收端錄屏，錄影後的每一幀都有傳送時間和接收時間，通過AI識別出來後，就可以計算出這一幀的延時。如圖 1.3 所示：
■圖1.3 打上時間戳的視訊傳輸
除了延時外，接下來要計算幀率、位元速率和卡頓率。
幀率的計算比較簡單，對接收端錄屏後的視訊取每一幀，如果這一幀上的數字相比上一幀有變化，我們就認為是不同幀，計算出幀數除以時間就是幀率,位元速率的計算我們可以通過抓包使用 Wireshark 分析，在音視訊通話中視訊資料都是以 UDP 協議傳輸，通過 Wireshark 可以很明顯的區分出來。
卡頓率與時間相關,通常我們計算 200ms、300ms、600ms 這幾種情況下的卡頓率，計算也比較簡單，以 200ms 為例，只要前後不同幀的間隔超過了 200ms，就認為是卡頓，卡頓數除以總幀數就是卡頓率。
04 其他測試方法
相比雲測，是否有更簡單的測試方案呢? 我們想到了想到藉助 SDK 自身的統計資訊，RTC 方案提供商都會在給外部使用的 SDK 中整合詳細且全面的統計資訊，我們可以通過回撥形式拿到。例如，通過聲網的onRtcStats(IRtcEngineEventHandler.RtcStats stats)回撥可以實現獲取當前通話的音視訊指標資訊，更詳細資訊，可訪問聲網文件中心(docs.agora.io/cn）搜尋瞭解。當然這種方式在別的方案不可用時不失為一種參考。
以上僅是一家之言，音視訊測試有很多種方案，說不定你已有更加準確高效的方法。歡迎在聲網開發者社群 rtcdeveloper.agora.io 分享出來，我們一起交流，共同進步！
關於 Dev for Dev
Dev for Dev 專欄全稱為 Developer for Developer，該專欄是聲網與 RTC 開發者社群共同發起的開發者互動創新實踐活動。
透過工程師視角的技術分享、交流碰撞、專案共建等多種形式，匯聚開發者的力量，挖掘和傳遞最具價值的技術內容和專案，全面釋放技術的創造力。