Сравнительный анализ Zoom Video SDK
Отчет о производительности Zoom Video SDK

- 01 Обзор - Jumplink to Обзор
- 02 Оценивание качества Video SDK - Jumplink to Оценивание качества Video SDK
- 03 Результаты и анализ производительности - Jumplink to Результаты и анализ производительности
- 04 Качество работы - Jumplink to Качество работы
- 05 Управление ресурсами в условиях несовершенной сети - Jumplink to Управление ресурсами в условиях несовершенной сети
- 06 Использование ЦП и ОЗУ - Jumplink to Использование ЦП и ОЗУ
- 07 Заключение - Jumplink to Заключение
- 08 Приложение - Jumplink to Приложение
Компания TestDevLab, поставщик инструментов обеспечения качества программного обеспечения и пользовательского тестирования, провела анализ Zoom Video SDK и четырех других поставщиков Video SDK: Agora, Vonage TokBox, Chime и Twilio. Целью было определить поведение каждой платформы и качество каждого пакета Video SDK, который получается в результате. Этот анализ проведен по заказу компании Zoom Communications, Inc. Данные, представленные в этом отчете, отражают результаты тестирования TestDevLab с 12 мая 2022 г.
В этом отчете сначала описываются соображения, которые необходимо учитывать при оценке качества Video SDK. Затем представлен анализ результатов, в частности, рассматривается качество производительности, сохранение пропускной способности, а также низкое использование центрального процессора (CPU) и оперативной памяти (RAM) при потере 25% пакетов. Подробная информация о среде тестирования представлена в приложении.
Решение Zoom простое в использовании, не перегружает систему и обеспечивает возможность детальной настройки, что свидетельствует об общем уровне качества нашего Video SDK. Даже в сценариях с неудовлетворительным сетевым подключением, использованием мобильных устройств и смоделированных загородных или удаленных мест расположения результаты теста Zoom Video SDK были удовлетворительными.
Компания TestDevLab также проводила тестирование, чтобы узнать, как пакеты Video SDK обрабатывали ограниченные ресурсы, такие как пропускная способность, ЦП и ОЗУ. Пакет Zoom Video SDK продолжал работать на должном уровне.
TestDevLab помогает стартапам и компаниям, попавшим в список Fortune 500, по всему миру ускорить циклы выпуска, а также повысить качество продуктов и удобство пользования. В рамках предоставляемых ею услуг и решений компания TestDevLab обеспечивает инновационные возможности тестирования и оценки качества звука и видео, тестирования функций, регрессии, безопасности и интеграций, а также услуги автоматизации тестирования для пакетов средств для разработки ПО, следуя рекомендациям и используя стандартные в отрасли инструменты тестирования и пользовательские решения для тестирования.
При оценке качества Video SDK необходимо учитывать множество различных аспектов, включая:
Пользовательские устройства: В задачи TestDevLab входило тестирование одних и тех же устройств на всех SDK, чтобы обеспечить возможность их сравнения.
Ограничения сети: Чтобы провести сравнительный анализ, условия сети должны быть контролируемыми. TestDevLab сосредоточился на четырех сетевых ограничениях, включая неограниченную, ограниченную полосу пропускания для отправителя, ограниченную полосу пропускания для получателя и случайную потерю 25% пакетов. Каждое устройство подключается к отдельному маршрутизатору, чтобы обеспечить качественное соединение.
Предсказуемость & Повторяемость: TestDevLab выполнила восемь тестов, разбитых на тестовые прогоны по четыре теста. Каждый тест проводился в разное время, чтобы уменьшить влияние возможных перегрузок глобальной сети/неожиданных замедлений в работе сервиса и т.д. Из этих тестов TestDevLab отобрал пять тестов с наиболее стабильным поведением.
Анализ: Для того чтобы проанализировать результаты, TestDevLab провела проверку в процессе работы. Они просматривают результаты за определенное время по всем тестам, а также выборочно проверяют видео, чтобы подтвердить достоверность данных по сравнению с субъективным взглядом.
TestDevLab проводила тесты для каждого сценария несколько раз. В каждом тесте и для всех производителей TestDevLab показал стабильные результаты при многократном выполнении одного и того же сценария. Анализируя результаты, TestDevLab обратил внимание на:
Качество исполнения. TestDevLab проанализировал качество задержки звука и видео при различных условиях сети. Они также изучили сравнение частоты кадров, количество кадров в секунду (FPS), а также метод оценки видео (Video Multimethod Assessment Fusion, VMAF).
Управление ресурсами в неидеальных условиях сети. TestDevLab проверил, как производители управляют ресурсами в ситуации потери пакетов.
Использование процессора/оперативной памяти. TestDevLab изучил, как производители потребляют ресурсы, когда приложение находится под нагрузкой, например. Видео многих участников отображаются в виде галереи.
Качество работы играет важную роль в различных условиях сети. TestDevLab протестировала задержку звука и видео, а также частоту кадров в неограниченной сети.
Тестирование задержки звука у разных поставщиков показало, что по всем направлениям существует сопоставимая задержка, за исключением Chime — там задержка была немного больше.
При сравнении задержки видео в Zoom, Agora, Twilio и Chime задержка видео составила в основном меньше 250 мс. При этом задержка видео Vonage TokBox колебалась в диапазоне от 250 до 1000 мс.
При сравнении частоты кадров тестирование показало, что наивысшую частоту кадров во время видеовызовов обеспечивает Zoom.
Результаты также показали, что качество видео Zoom было наиболее стабильным во всех тестируемых условиях сети. Тестирование началось без ограничений пропускной способности. После этого в равной степени ко всем поставщикам была применена низкая пропускная способность: сначала со стороны отправителя, затем со стороны получателя.
Затем компания TestDevLab изучила устойчивость источников в случае, когда потеря пакетов составляет 25%. Потеря пакетов может замедлить работу сети, привести к возникновению сложностей, отрицательно повлиять на пропускную способность сети и привести к увеличению расходов. Потеря пакетов может быть обусловлена различными причинами, и многие из них являются непреднамеренными. Например, это может быть перегрузка сети, ненадежные сети, особенно мобильные, программные ошибки и перегруженные устройства.
В рамках тестов, предусматривающих 25%-ю потерю пакетов, Zoom отлично удалось сохранить пропускную способность, а также поддерживать низкий показатель использования ЦП и памяти. Zoom обеспечивает интеллектуальное управление и является консервативным, сохраняя при этом качество связи.
С другой стороны, тестирование показало, что Agora, похоже, по-другому относится к потере пакетов - она тратит много пропускной способности, чтобы попытаться справиться с потерей пакетов. Если причиной потери пакетов является ограниченный битрейт, то попытка потреблять больше полосы пропускания может вызвать проблемы.
При сравнении качества звука во время 25%-й потери пакетов Zoom и Agora показали удовлетворительное качество обработки звука на уровне выше 4,00 MOS (средняя экспертная оценка разборчивости речи). Однако качество звука Twilio было непригодным для использования, а качество звука Chime было близко к непригодному для использования, при этом качество звука было ниже 3,00 MOS.
Если рассматривать задержку звука при потере 25% пакетов, то Zoom увеличил ее примерно на 100 мс по сравнению с Agora, у которой задержка при потере пакетов увеличилась на 200 - 250 мс.
При сравнении скорости сети тестирование показало, что Twilio и Chime были нестабильными и снизили скорость до очень низкого значения по умолчанию. С другой стороны, скорость Agora была очень высокой, а это свидетельствует о том, что продукт может не учитывать перегрузку сети при определении причины потери пакетов.
Что касается использования ЦП, решение Zoom использовало наименьшее количество ресурсов ЦП по сравнению с четырьмя другими поставщиками в рамках сценариев тестирования.
У Zoom также был самый низкий показатель использования ОЗУ. Как показано на диаграмме ниже, Twilio и Chime использовали примерно 500 Мб ОЗУ при 25%-й потере пакетов, в то время как решение Agora использовало более 3 Гб для видеовызовов.
Преимущества более низкого показателя использования ЦП и ОЗУ включают:
- более удобное использование;
- повышение производительности приложения благодаря большему количеству доступных ресурсов;
- более экономный расход заряда аккумулятора приложением;
- возможность использовать другие приложения на видеоконференции.
Более низкие показатели использования ЦП и ОЗУ — это идеальный сценарий использования встроенных возможностей аудио и видео другими приложениями, потребляющими много ресурсов, такими как видеоигры и приложения для ведения коллективной работы с графическими объектами, например система автоматизированного проектирования и 3D-дизайн.
Компания TestDevLab проверила показатель использования ЦП на количество пользователей, использования ЦП в динамике и использования памяти в динамике. По результатам тестирования решение Zoom Video SDK использовало небольшое количество ресурсов ЦП. Как упоминалось выше, более низкий показатель использования ЦП может обеспечить более удобную работу пользователей, повышение производительности приложения благодаря большему количеству доступных ресурсов и более экономный расход заряда аккумулятора приложением.
Во время тех же тестов в Agora не удалось отобразить 32 видео в сетке вида галереи. Кроме того, решение Vonage TokBox постоянно потребляло больше ресурсов ЦП, чем другие поставщики.
Zoom Video SDK отлично подойдет для любой сети, включая сети с ограниченными ресурсами, такими как пропускная способность, ЦП и ОЗУ.
Тесты TestDevLab проводились несколько раз по каждому сценарию, и каждый раз компания получала надлежащие результаты. Пакет Zoom Video SDK выделялся по результатам благодаря:
- качеству работы;
- стабильной пропускной способности;
- показателям использования ЦП и ОЗУ.
Узнайте, как ускорить разработку и создать полностью настраиваемые приложения на основе видео, посетив страницу Zoom video SDK.
Тестовая среда
Пакеты Video SDK, в том числе Zoom Video SDK и пакеты от поставщиков Agora, Vonage TokBox, Chime и Twilio, прошли тестирование в ряде предварительно определенных сценариев.
Компания TestDevLab тестировала всех пятерых поставщиков по трем типам тестов с двумя различными количествами участников и четырьмя различными ограничениями сети, включая отсутствие ограничений, примененное ограничение на стороне отправителя, примененное ограничение на стороне получателя и 25%-ю потерю пакетов. Компания TestDevLab провела восемь тестов, разделенных на четыре тестовых запуска, которые выполнялись в разное время. После этого компания TestDevLab отобрала из них пять тестов с наиболее стабильным поведением для дальнейшего анализа и определения результатов.
Чтобы протестировать использование ЦП и ОЗУ с различными уровнями нагрузки, TestDevLab создала нагрузочный тест, который начинается с вызова с участием 48 пользователей. В время трансляции видео TestDevLab изменяла количество пользователей в сетке каждые 60 секунд, чтобы протестировать сценарии с отображением 32, 16, 8*, 4 и 2 пользователей.
С целью тестирования производительности для платформы TestDevLab были заданы указанные далее настройки.
- Устройство отправителя: MSI Katana GF66 11UD i7-11800H, 8 Гб, SSD-накопитель на 512 Гб, GeForce RTX 3050 Ti на 4 Гб.
- Устройство получателя: Lenovo ThinkPad E495|R5 3500U|16 Гб|512SSD|Vega 8 (20NE-001GMH).
- Разрешение видеозвонков: 1080×720
- Разрешение экрана: 1920×1080 (разрешение экрана)
- Частота кадров видео: 30 кадров в секунду
- Скорость видео: 3000 кбит/с.
Компания TestDevLab провела тестирование видеовызова, а также динамической и статической демонстрации экрана для анализа производительности. Каждый сценарий прошел тестирование пять раз с разным количеством участников. Применялся описанный далее процесс.
- Применение ограничения сети.
- Совершение вызова с помощью устройства отправителя.
- Присоединение к вызову с помощью устройства получателя с другими участниками.
- Запуск трансляции видео или демонстрации экрана.
- Параллельно - собирайте необработанные тестовые данные
- По завершении трансляции видео отключение от вызова в обратном порядке очередности действий для присоединения.
- Обработка необработанных данных.
- Проверка обработанных данных.
* Программа тестирования TestDevLab также включала тестирование галереи с 8 участниками, однако реализация этого теста происходила с неверным разрешением, поэтому полученные результаты не включены в анализ и отчет.