Zoom 视频 SDK 性能报告

Zoom 视频 SDK 的比较分析

Zoom 视频 SDK 性能报告

概述

TestDevLab(软件质量保证和定制测试工具开发提供商)对 Zoom 视频 SDK 以及 Agora、Vonage TokBox、Chime 和 Twilio 这四个视频 SDK 供应商执行了分析。 其目标是了解每个平台的行为以及每个视频 SDK 的最终质量。 这项分析受托于 Zoom Video Communications, Inc.。 本报告中提供的结果体现的是 2022 年 5 月 12 日的 TestDevLab 测试结果。

本报告首先说明了评估视频 SDK 质量时的注意事项。 然后显示分析结果,特别研究了丢包率为 25% 时的性能质量、带宽持久性以及保持中央处理器 (CPU) 和随机存取内存 (RAM) 的低使用率。 附录中提供了有关测试环境的详细信息。

Zoom 在其视频 SDK 的整体质量上投入了大量精力,旨在打造一个易于使用且高度可定制的轻量级视频 SDK。 即使网络状况不佳、使用移动信号以及模拟农村或偏远地区,Zoom 视频 SDK 的测试结果也很出色。

TestDevLab 还进行了测试,以此了解视频 SDK 如何处理有限的带宽、CPU 和 RAM 等资源。 Zoom 视频 SDK 始终表现良好。

TestDevLab 帮助全球的初创公司和财富 500 强公司加快发布周期、提高产品质量并增强用户体验。 TestDevLab 在其服务和解决方案中为 SDK 提供创新的音频/视频质量测试和基准测试,提供功能、回归、安全性和集成测试以及测试自动化服务,遵循最佳做法并使用行业标准测试工具和自定义测试解决方案。

评估视频 SDK 质量

评估视频 SDK 质量时,需要考虑许多不同的方面,包括:

用户设备:TestDevLab 能够在相同设备上测试所有 SDK,以确保它们具有可比性。

网络限制:为了执行比较分析,网络条件必须是可控的。 TestDevLab 重点关注四种网络限制,其中包括无限带宽、对发送端应用有限带宽、对接收端应用有限带宽以及随机丢包率达 25%。 每个设备都连接一个不同的路由器以确保连接质量。

可预测性和可重复性:TestDevLab 进行了八场测试,每场测试进行四次。 每次测试都在不同的时间进行,以便降低任何潜在的全球网络拥塞/意外服务速度缓慢等问题造成的影响。在这些测试中,TestDevLab 采用了五个行为最稳定的测试。

分析:为了分析结果,TestDevLab 执行了过程内验证。 他们会在一段时间内浏览所有的测试结果,以及通过抽查视频并与主观预测相比来确认数据有效性。

性能结果和分析

TestDevLab 对每个场景进行了多次测试。 在针对所有供应商的每场测试中,TestDevLab 在同一场景中执行多次后得到了稳定的结果。 分析结果时,TestDevLab 研究的是性能质量。 TestDevLab 分析了各种网络条件下的音频延迟和视频延迟质量。 他们还研究了帧率比较、每秒帧数 (FPS) 以及“视频多方法评估融合”(VMAF)。

非理想网络条件下的资源管理。 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 处理的音频质量比较好,MOS 值都高于 4.00。 然而,Twilio 的音频质量太差,无法使用,Chime 的音频质量也几乎无法使用,MOS 值都低于 3.00 。

丢包率为 25% 时的 POLQA 对比图

在研究丢包率为 25% 的音频延迟时,与 Agora 相比,Zoom 大约增加了 100 毫秒,在处理丢包时更是显著增加了 200 – 250 毫秒。

在比较网络比特率时,测试结果显示 Twilio 和 Chime 都不稳定,默认的比特率非常低。 另一方面,Agora 的比特率非常高,这表明该产品在确定丢包原因时可能没有考虑网络拥塞。

已发送数据丢包率为 25% 时的已发送比特率对比

已接收数据丢包率为 25% 时的已发送比特率对比

就 CPU 使用率而言,与其他四家供应商相比,Zoom 在各个测试场景中的 CPU 使用率最低。

丢包率为 25% 时的 CPU 对比

Zoom 的 RAM 使用率也是最低的。 如下图所示,Twilio 和 Chime 在丢包率为 25% 时均使用了大约 500MB 的 RAM,而 Agora 在视频通话时使用的 RAM 超过 3GB。

丢包率为 25% 时的 RAM 对比

CPU/RAM 使用率

降低 CPU 和 RAM 使用率的好处包括:

  • 改善用户体验
  • 增强应用性能并提供更多资源
  • 减少应用耗电的投诉
  • 用户可以在进行视频会议的同时运行其他应用程序

较低的 CPU 和 RAM 使用率非常适用于将实时 A/V 嵌入到其他消耗大量资源的应用程序(如视频游戏)和图形协作应用程序(如 CAD 和 3D 设计)的情况。

TestDevLab 检查了每位用户的 CPU 使用率、一段时间内的 CPU 使用率以及一段时间内的内存使用率。 测试结果表明 Zoom 视频 SDK 的 CPU 使用率较低。 如上所述,较低的 CPU 使用率可以转化为良好的用户体验、增强应用性能并提供更多资源,以及减少应用耗电的投诉。

每位用户的 CPU 使用率

系统 CPU 网格比较

一段时间内的 CPU 使用率 - CPU 无限接收端

一段时间内的 CPU 使用率 - 系统 CPU 无限接收端

在相同的测试中,Agora 无法承载 32 个网格的画廊视图。 此外,与其他供应商相比,Vonage TokBox 的 CPU 使用率始终偏高。

总结

Zoom 视频 SDK 适用于所有网络状况(包括带宽、CPU 和 RAM 等资源受到限制的情况下)。

TestDevLab 对每个场景都进行了多次测试,每次的结果都一致。 Zoom 视频 SDK 脱颖而出的原因为:

  • 性能质量
  • 带宽可靠性
  • CPU/RAM 使用率

请访问本站点,了解如何加速您的开发过程并构建完全可定制且基于视频的应用程序。

附录

测试环境

视频 SDK(包括 Zoom 视频 SDK,以及 Agora、Vonage TokBox、Chime 和 Twilio 的视频 SDK)在一组预定义的场景中进行了测试。

TestDevLab 测试了上述五家供应商,测试类型超过三种,并且安排了两批人数不同的参与者以及四种不同的网络限制条件(包括无限制、在发送端应用限制、在接收端应用限制和 25% 丢包率)。 TestDevLab 进行了八场测试,每场测试在不同时间进行四次。 TestDevLab 从中采用了五个行为最稳定的测试来生成分析和结果。

为了测试不同负载水平下的 CPU 和 RAM 使用率,TestDevLab 创建了一项压力测试,开始时共有 48 位用户参与通话。 当进行视频直播时,TestDevLab 每 60 秒切换一次网格上的用户数量,以便测试 32、16、8*、4 和 2 个用户的场景。

对于性能测试,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 在视频通话、动态屏幕共享和静态屏幕共享测试场景中执行了性能分析。 每个场景以不同人数的参与者测试了五次。 采用了以下流程:

  • 应用网络限制
  • 使用发送端设备创建通话
  • 使用接收端设备并让额外的参与者加入通话
  • 开始直播视频或屏幕共享
  • 并行 – 收集原始测试数据
  • 视频结束后,按照与加入顺序相反的顺序离开通话
  • 处理原始数据
  • 验证处理后的数据

* TestDevLab 测试设计还包括一个由 8 人参加的画廊测试,但是,实施该测试时使用的分辨率不正确,因此这些结果未包含在本次分析和报告中。