Zoom Video SDK パフォーマンス レポート
Zoom Video SDK の比較分析
-
01概要
-
02Video SDK の品質評価
-
03パフォーマンスの結果と分析
-
04パフォーマンスの品質
-
05非理想的なネットワーク条件下でのリソース管理
-
06CPU / RAM の使用率
-
07結論
概要
ソフトウェアの品質保証とカスタムのテストツール開発を提供する TestDevLab は、Zoom Video SDK と他の Video SDK ベンダー 4 社(Agora、Vonage TokBox、Chime)の Video SDK を分析しました。 その目的は、各プラットフォームの動作を把握し、その結果として各 Video SDK の品質を理解することでした。 この分析は、Zoom Video Communications からの委託です。 このレポートで報告する調査結果は、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 の品質評価
Video SDK の品質を評価する際は、以下のようなさまざまな側面を考慮する必要があります。
ユーザーのデバイス: TestDevLab の調査範囲においては、すべての SDK を同じデバイスでテストし、比較できるようにしました。
ネットワークの制限: 比較分析を実施するためには、ネットワークの状態を制御できる必要があります。 TestDevLab は、4 つのネットワーク制限(無制限、送信側に帯域制限を適用、受信側に帯域制限を適用、ランダムな 25% のパケットロス)に焦点を当てました。 高品質の接続を確保するために、各デバイスは異なるルーターに接続しています。
予測可能性と再現性: TestDevLab は、8 つのテストを 4 回に分割して実施しました。 各テストは、潜在的なグローバル ネットワークの混雑や予期せぬサービスの低下などといった影響を軽減するために、異なる時間帯に実施しました。こうしたテストの中から、TestDevLab は最も動作が安定していた 5 つのテストを取り上げました。
分析: 結果を分析するために、TestDevLab はプロセス内検証を実行しました。 全テストの経時的な結果を調べるとともに、主観と比較したデータの妥当性を確認するためにビデオの無作為抽出検査を実施します。
パフォーマンスの結果と分析
TestDevLab は、各シナリオを複数回テストしました。 各テストで、またすべてのベンダーにおいて、TestDevLab は同じシナリオを複数回テストしても、安定した結果を得ることができました。 結果を分析する際、TestDevLab は次の点に着目しました。
パフォーマンスの品質。 TestDevLab は、さまざまなネットワーク条件下で、オーディオ遅延とビデオ遅延の品質を分析しました。 また、フレームレートの比較、FPS(1 秒当たりのフレーム数)、VMAF(Video Multimethod Assessment Fusion)についても調査しました。
非理想的なネットワーク条件下でのリソース管理。 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% 時のオーディオ遅延を見ると、Agora がパケットロスに対応するために 200~250 ミリ秒とより大きく増加しているのに比べ、Zoom は 100 ミリ秒程度の増加となっています。
ネットワーク ビットレートの比較では、Twilio と Chime の両者が不安定で、非常に低いビットレートがデフォルトになっていることがテストから判明しました。 一方、Agora のビットレートは非常に高かったため、パケットロスの原因を特定する際に、ネットワークの混雑を考慮していない可能性があることがわかりました。
CPU の使用率に関しては、テストシナリオ全体で、Zoom は他のベンダー 4 社と比較して CPU 使用率が最小でした。
また、RAM の使用率が最小だったのも Zoom です。 以下の表のように、パケットロス 25% 時、Twilio と Chimeはどちらも約 500 MB の RAM を使用し、Agora はビデオ通話で 3 GB 以上使用しています。
CPU/RAM の使用率
CPU と RAM の使用率が低いことによるメリット:
- ユーザー体験が向上
- より多くのリソースを利用できるようになるので、アプリのパフォーマンスが向上
- アプリのバッテリー消費に対する不満が減少
- ビデオ カンファレンスを実施しながら、他のアプリケーションを起動可能
CPU や RAM の使用率が低いということは、リアルタイム A/V を、リソースを激しく消費する他のアプリケーション(ビデオゲームなど)や、CAD や 3D デザインなどのグラフィカル コラボレーション アプリケーションに組み込むといったユースケースには、最適だと言えます。
TestDevLab は、ユーザー数あたりの CPU 使用率、時間の経過に伴う CPU 使用率、時間の経過に伴うメモリ使用率を調べました。 テストでは、Zoom Video SDK の CPU 使用率が低いという結果が出ました。 前述のように、低い CPU 使用率は、より良いユーザー体験、利用できるリソースが増えることによるアプリのパフォーマンスの向上、アプリのバッテリー消費に対する不満の減少につながります。
同じテストで、Agora は 32 グリッドのギャラリー ビューをホスティングできませんでした。 また、Vonage TokBox の CPU 使用率は、他のベンダーよりも常に高い状態でした。
結論
Zoom Video SDK は、リソース(帯域幅、CPU、RAM など)が限られている場合も含め、あらゆるネットワーク シナリオに対応できる優れた選択肢です。
TestDevLab は、各シナリオを複数回テストしましたが、結果は毎回一貫していました。 Zoom Video SDK は以下の点で際立っていました。
- パフォーマンスの品質
- 帯域幅の信頼性
- CPU / RAM の使用率
開発を加速化し、完全にカスタマイズ可能なビデオベースのアプリケーションを構築する方法については、このサイトにアクセスしてください。
付録
テスト環境
Zoom Video SDK をはじめ、Agora、Vonage TokBox、Chime、Twilio の Video SDK を、事前に定義したシナリオに沿ってテストしました。
TestDevLab は、5 社のベンダー全社を、テストの種類 3 パターン、参加人数 2 パターン、ネットワーク制限 4 パターン(無制限、送信側に制限を適用、受信側に制限を適用、パケットロス 25%)でテストしました。 TestDevLab は、8 つのテストを 4 回に分けて、異なる時間に実施しました。 そこから、TestDevLab はその中で最も動作が安定していた 5 つのテストを取り上げて、解析と結果を出したのです。
さまざまな負荷レベルで CPU と RAM の使用状況をテストするため、TestDevLab は合計 48 人のユーザーが通話を始めるストレステストを作成しました。 ビデオのストリーミング中、TestDevLab は 32 人、16 人、8* 人、4 人、2 人のユーザーのシナリオをテストするために、60 秒ごとにグリッド上のユーザー数を切り替えました。
パフォーマンス テストについては、TestDevLab プラットフォームを以下のように構成しました。
- 送信側のデバイス: MSI Katana GF66 11UD i7-11800H, 8GB, 512GB SSD, GeForce RTX 3050 Ti 4GB
- 受信側のデバイス: Lenovo ThinkPad E495|R5 3500U|16GB|512SSD|Vega 8 (20NE-001GMH)
- ビデオ通話の解像度: 1080×720
- 画面共有の解像度:1920×1080(画面解像度)
- ビデオのフレームレート: 30 FPS
- ビデオのビットレート: 3000 kbps
TestDevLab はパフォーマンスを分析するために、ビデオ通話、動的画面共有、静的画面共有のテストシナリオを実施しました。 各シナリオは、参加人数を変えて 5 回テストされました。 そのテストには、次のようなプロセスが適用されました。
- ネットワークに制限を適用
- 送信側デバイスとの通話を作成
- 受信側デバイスと追加の参加者が通話に参加
- ビデオ ストリーミングや画面共有を開始
- 並行して、テストの生データを収集
- ビデオが終了したら、通話への参加順とは逆の順序で通話を終了
- 生データを処理
- 処理済みのデータを検証
* TestDevLab のテスト設計には、8 人の参加者によるギャラリー テストも含まれていましたが、このテストは誤った解像度を使用して実施されていたため、その結果は分析およびレポートには含まれていません。