Zoom Video SDK 效能報告

概觀

TestDevLab (一款品質保證與客戶測試工具開發供應商的軟體) 針對 Zoom Video SDK 和另外 4 家 Video SDK 廠商進行分析：Agora、Vonage TokBox、Chime 和 Twilio。 目的是瞭解每個平台運行的方式，以及每個 Video SDK 的最終品質。 此分析受 Zoom Video Communications, Inc. 委託。 此報告中提供的結果，顯示 TestDevLab 自 2022 年 5 月 12 日以來的測試結果。

此報告首先說明評估視訊 Video SDK 時的考量事項。 接著，對結果進行分析，且特別研究效能品質、頻寬保有率，以及在 25% 封包遺失率期間維持中央處理器 (CPU) 和隨機存取記憶體 (RAM) 使用量低。 其他測試環境的詳細資訊於附錄中提供。

專為容易使用設計、輕量級應用程式，以及高度自訂化的 Zoom，在其視訊 Video SDK 的整體品質投入大量精力。 即便網路環境不佳、在移動裝置上使用，以及鄉村或偏遠地區，Zoom Video SDK 的測試結果都相當出色。

TestDevLab 還測試 Video SDK 如何應對資源受限的環境，例如頻寬、CPU 和 RAM 限制。 Zoom Video SDK 的表現依然出色。

TestDevLab 協助新創企業和全球財富 500 強企業，縮短產品發佈週期、提升產品品質並增強使用者體驗。 作為服務與解決方案的一部分，TestDevLab 提供創新音訊/視訊品質測試和基準測試、功能、迴歸、安全性和整合測試，以及 SDK 自動化服務測試，遵守最佳做法並使用業界標準的測試工具和自訂測試解決方案。

評估 Video SDK 品質時，有許多不同層面需要考慮，包括：

使用者裝置：TestDevLab 的測試方法是使用相同裝置，以確保以相同條件比較所有 SDK。

網路限制：為能夠進行比較分析，因此網路條件需要能夠控制。 TestDevLab 採用 4 種網路限制，包括無限制頻寬、傳送方的限制頻寬、接收方的限制頻寬，以及 25% 隨機封包遺失率。 每個裝置分別連線至不同路由器，以確保高品質連線。

可預測性和可重複性：TestDevLab 共進行 8 次測試，拆成 4 組分別進行。 每次進行測試的時間都不同，以降低全球網路壅塞/意外服務減速等所導致的可能影響。TestDevLab 會從所有測試當中，挑選 5 次最為穩定的測試納入分析。

分析：為分析出結果，TestDevLab 會執行製程中驗證。 他們會查看所有測試結果，並且抽查影片以確保資料的真實性，而非主觀感受。

TestDevLab 會對每個情境進行多次測試。 所有廠商的每次測試當中，TestDevLab 所進行的多次測試，在相同情境中都可得出穩定的結果。 對結果進行分析時，TestDevLab 關注：

效能品質。 TestDevLab 分析各種網路條件下音訊延遲和視訊延遲的品質。 同時研究幀率比較、每秒幀數 (FPS)，以及視訊多方法評估融合 (VMAF)。

網路狀況不理想時的資源管理。 TestDevLab 研究廠商如何在封包遺失的情況下管理資源。

CPU/RAM 使用量。 TestDevLab 研究當應用程式處於高負載時 (如許多與會者啟用畫廊檢視視訊時)，廠商消耗資源的方式。

效能品質在任何網路條件下都非常重要。 TestDevLab 測試網路無限制時的音訊延遲、視訊延遲和幀率。

針對所有廠商的音訊延遲測試中發現，除了 Chime 的延遲時間較長以外，所有產品都存在輕微延遲情形。

當比較視訊延遲時，Zoom、Agora、Twilio 和 Chime 大多數的視訊延遲低於 250 毫秒。 然而，Vonage TokBox 的視訊延遲從 250 到 1,000 毫秒不等。

從幀率比較來看，測試結果顯示 Zoom 在視訊通話中的幀率最高。

結果還表明，在各種網路條件測試中，Zoom 的視訊品質最一致。 測試方法從無頻寬限制開始，然後對所有廠商採用低頻寬限制，先從傳送端開始，再套用至接收端。

接下來，TestDevLab 會研究 25% 封包遺失率情境期間的資源保有率。 封包遺失可使網路速度下降、導致瓶頸、頻寬效率降低導致網路中斷，最終付出昂貴代價。 造成封包遺失的原因很多，其中又有許多是無意間造成。 常見案例有：網路壅塞、網路不佳 (尤其是行動裝置)、軟體錯誤，以及裝置負載過多。

在測試當中 (包括 25% 封包遺失率)，Zoom 在頻寬預留方面表現出色，而封包遺失及網路受限的條件之下，CPU 和記憶體使用量皆較低。 Zoom 提供智慧管理，在相對保守的同時維持通話品質。

另一方面，測試顯示，Agora 似乎採取不同策略處理封包遺失：占用大量頻寬企圖解決封包遺失。 如果封包遺失的原因為位元速率受限，則占用更多頻寬可能會導致問題發生。

在 25% 封包遺失率中比較音訊品質，Zoom 和 Agora 處理音訊的能力較好，得分高於 4.00 MOS。 但是，Twilio 的音訊品質近乎無法辨識，而 Chime 的品質趨近於無法辨識，得分低於 3.00 MOS。

在 25% 封包遺失率中研究音訊延遲，Zoom 增加約 100 毫秒延遲，然而 Agora 延遲更為嚴重，增加大約 200 – 250 毫秒以處理封包遺失。

網路位元速率比較期間，測試結果顯示 Twilio 和 Chime 皆不穩定，且預設為非常低的位元速率。 另一方面，Agora 的位元速率非常高，顯示出該產品可能沒有將封包遺失的問題歸因於網路壅塞。

至於 CPU 使用量，與其他 4 家廠商相比，Zoom 所占用的 CPU 資源最少。

同時，Zoom 對 RAM 的使用量也是最低。 如下方圖表所示，Twilio 和 Chime 在 25% 封包遺失率下，皆占用約 500MB 的 RAM，而 Agora 在視訊通話中使用超過 3GB。

CPU 與 RAM 使用量較低的好處包括：

CPU 和 RAM 使用量較低，則為即時影音嵌入其他重度消耗資源應用程式的完美使用案例，例如：電玩遊戲、圖形協作應用程式 (如 CAD 和 3D 設計)。

TestDevLab 檢查每個使用者人數的 CPU 使用量、一段時間內的 CPU 使用量及記憶體使用量。 測試過程中，結果顯示 Zoom Video SDK 所占用的 CPU 較低。 如上所述，較低的 CPU 使用量代表較佳的使用者體驗、應用程式效能更好，以及更多的可用資源，並降低應用程式導致電池過熱的投訴。

而相同測試中，Agora 無法進行 32 格的畫廊檢視。 此外，Vonage TokBox 比起其他廠商占用的 CPU 資源更多。

Zoom Video SDK 在任何網路環境中都是良好選擇，包括資源受限 (如頻寬、CPU 和 RAM 限制) 的情況。

TestDevLab 於每個環境中進行多次測試，且每次得出一致的結果。 Zoom Video SDK 於評估結果中脫穎而出，因其卓越的：

造訪此網站，瞭解如何加速開發和建置完整可自訂的視訊型應用程式。

測試環境

Video SDK 包括 Zoom Video SDK，以及 Agora、Vonage TokBox、Chime 和 Twilio 皆於預先定義的情境中進行測試。

TestDevLab 測試全部 5 家廠商，共計 3 種測試類型 (包括兩種不同的與會者人數)，4 種不同網路限制 (包括無限制、傳送方限制、接收方限制，以及 25% 封包遺失率)。 TestDevLab 於不同時間，將總共 8 次測試拆為 4 組分別進行。 從 8 次測試結果當中，TestDevLab 挑選出 5 個最穩定的測試，用於進一步分析和產生結果。

為了測試不同負載等級下的 CPU 和 RAM 使用量，TestDevLab 建立一次壓力測試，總計 48 名使用者加入通話。 當視訊開始串流時，TestDevLab 開始每 60 秒切換一次網格的使用者人數，以測試 32、16、8*、4 和 2 名使用者的環境。

針對效能測試，TestDevLab 平台配置如下：

TestDevLab 進行視訊通話、動態畫面分享和靜態畫面分享測試情境，以進行效能分析。 每個情境都會以不同的與會者人數進行 5 次測試。 測試會根據以下步驟進行：

* TestDevLab 測試設計還包括 8 名與會者的畫廊測試，但是此測試使用的解析度不正確，因此這些結果不納入分析和報告中。