Zoom Video SDK パフォーマンス レポート

Zoom Video SDK の比較分析

Zoom ミーティング中にデスクに座る男性

概要

ソフトウェアの品質保証とカスタムのテストツール開発を提供する TestDevLab は、Zoom Video SDK と、ほかの Video SDK ベンダー 4 社(Agora、Vonage TokBox、Chime)の Video SDK を分析しました。その目的は、各プラットフォームの動作を把握し、その結果として各 Video SDK の品質を理解することでした。この分析は、Zoom 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の品質評価

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のフレームレートが最も高いことがテストからわかりました。

 

無制限FPSの比較表

 

また、テストしたすべてのネットワーク条件において、Zoom のビデオ品質が最も安定していることも判明しました。 テストは、帯域制限なしという設定から開始し、それから低帯域制限をまずは全ベンダーへ、次に送信側へ、その後受信側へ適用しました。

 

受信側に制限を適用したテストケースにおけるフレームレートの回復状況

非理想的なネットワーク条件下でのリソース管理

TestDevLabは次に、パケットロス25%というシナリオでソースがどの程度対応できるか調べました。パケットロスは、ネットワーク速度を低下させたり、ボトルネックを引き起こしたり、ネットワークスループット帯域幅を中断したりしかねない上、高額になる可能性があります。パケットロスの原因はさまざまですが、その多くは意図的なものではありません。たとえば、ネットワークの混雑、信頼性の低いネットワーク(特にモバイル)、ソフトウェアのバグ、デバイスの過負荷などが挙げられます。

 

パケットロス25%のシナリオを含むテストでは、Zoomはうまく帯域を維持し、パケットロスやネットワークの制約がありながらも見事にCPUとメモリの使用率を低く抑えていました。Zoomは通話品質を維持しながら、スマートな管理を提供し、かつ使用率も低めです。

 

一方で、Agoraはパケットロスに対するアプローチが異なるようで、パケットロスを処理するために多くの帯域を費やしていることがテストから判明しました。ビットレートが制限されていることがパケットロスの原因である場合、より多くの帯域を消費しようとすると問題が発生することがあります。

 

パケットロス 25% 時のオーディオ比較では、Zoom と Agora が 4.00 MOS を超えるレベルで音質をうまく処理していました。 しかし、Twilio の音質は使い物にならないレベルで、Chime の音質レベルも 3.00 MOS 以下と、ほぼ使い物にならない状態でした。

 

25%のPL POLQA比較表

 

パケットロス25%時のオーディオ遅延を見ると、Agoraがパケットロスに対応するために200~250ミリ秒とより大きく増加しているのに比べ、Zoomは100ミリ秒程度の増加となっています。

 

ネットワーク ビットレートの比較では、Twilio と Chime の両者が不安定で、非常に低いビットレートがデフォルトになっていることがテストから判明しました。 一方、Agora のビットレートは非常に高かったため、パケットロスの原因を特定する際に、ネットワークの混雑を考慮していない可能性があることがわかりました。

 

PL 25%時の送信ビットレートの比較

 

PL 25%時の受信ビットレートの比較

 

CPUの使用率に関しては、テストシナリオ全体で、Zoomは他のベンダー4社と比較してCPU使用率が最小でした。

 

PL 25%時のCPUの比較

 

また、RAMの使用率が最小だったのもZoomです。以下の表のように、パケットロス25%時、TwilioとChimeはどちらも約500MBのRAMを使用し、Agoraはビデオ通話で3GB以上使用しています。

 

PL 25%時のRAMの比較

CPU / RAMの使用率

CPU と RAM の使用率が低いことによるメリット:

  • ユーザー体験が向上
  • より多くのリソースを利用できるようになるので、アプリのパフォーマンスが向上
  • アプリのバッテリー消費に対する不満が減少
  • ビデオカンファレンスを実施しながら、他のアプリケーションを起動可能

 

CPUやRAMの使用率が低いということは、リアルタイムA/Vを、リソースを激しく消費する他のアプリケーション(ビデオゲームなど)や、CADや3Dデザインなどのグラフィカルコラボレーション アプリケーションに組み込むといったユースケースには、最適だと言えます。

 

TestDevLab は、ユーザー数あたりの CPU 使用率、時間の経過に伴う CPU 使用率、時間の経過に伴うメモリ使用率を調べました。 テストでは、Zoom Video SDK の CPU 使用率が低いという結果が出ました。 前述のように、低い CPU 使用率は、より良いユーザー体験、利用できるリソースが増えることによるアプリのパフォーマンスの向上、アプリのバッテリー消費に対する不満の減少につながります。

 

ユーザー数あたりの CPU 使用率

 

システム CPU のグリッド比較

 

時間の経過に伴うCPU使用率 - 受信側のCPU無制限

 

時間の経過に伴うCPU使用率 - 受信側のシステムCPU無制限

 

同じテストで、Agora は 32 グリッドのギャラリー ビューをホスティングできませんでした。 また、Vonage TokBox の CPU 使用率は、他のベンダーよりも常に高い状態でした。

まとめ

Zoom Video SDKは、リソース(帯域幅、CPU、RAMなど)が限られている場合も含め、あらゆるネットワークシナリオに対応できる優れた選択肢です。

 

TestDevLabは、各シナリオを複数回テストしましたが、結果は毎回一貫していました。Zoom Video SDKは以下の点で際立っていました。

  • パフォーマンスの品質
  • 帯域幅の信頼性
  • CPU / RAM の使用率

 

開発を加速化し、完全にカスタマイズ可能なビデオベースのアプリケーションを構築する方法については、Zoom Video SDKのページにアクセスしてください。

付録

テスト環境

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)
  • ビデオ通話の解像度: 1,080x720
  • 画面共有の解像度: 1,920x1,080(画面解像度)
  • ビデオのフレームレート: 30FPS
  • ビデオのビットレート: 3000kbps

 

TestDevLabはパフォーマンスを分析するために、ビデオ通話、動的画面共有、静的画面共有のテストシナリオを実施しました。各シナリオは、参加人数を変えて5回テストされました。そのテストには、次のようなプロセスが適用されました。

  • ネットワークに制限を適用
  • 送信側デバイスとの通話を作成
  • 受信側デバイスと追加の参加者が通話に参加
  • ビデオストリーミングや画面共有を開始
  • 並行して、テストの生データを収集
  • ビデオが終了したら、通話への参加順とは逆の順序で通話を終了
  • 生データを処理
  • 処理済みのデータを検証

 

*TestDevLabのテスト設計には、8人の参加者によるギャラリーテストも含まれていましたが、このテストは誤った解像度を使用して実施されていたため、その結果は分析およびレポートには含まれていません。