Informe de rendimiento del SDK de vídeo de Zoom

Descripción general

TestDevLab, un proveedor de control de calidad de software y desarrollo de herramientas de prueba personalizadas, realizó un análisis del SDK de vídeo de Zoom y otros cuatro proveedores de SDK de vídeo: Agora, Vonage TokBox, Chime y Twilio. El objetivo era comprender el comportamiento de cada plataforma y la calidad resultante de cada SDK de vídeo. Este análisis fue encargado por Zoom Video Communications, Inc. Los hallazgos que se presentan en este informe reflejan los resultados de las pruebas de TestDevLab del 12 de mayo de 2022.

En primer lugar, en este informe, se describen las consideraciones que se deben tener en cuenta al evaluar la calidad del SDK de vídeo. En segundo lugar, se presenta un análisis de los resultados, en el que se examina específicamente la calidad del rendimiento, la perseverancia del ancho de banda y el mantenimiento de un bajo uso de la unidad central de procesamiento (CPU) y de la memoria de acceso aleatorio (RAM) durante una pérdida de paquetes del 25 %. Los detalles sobre el entorno de prueba se proporcionan en el apéndice.

Zoom ha puesto mucho esfuerzo en la calidad general de su SDK de vídeo, el cual está diseñado para ser fácil de usar, liviano y altamente personalizable. Incluso en escenarios de red deficientes, casos de uso móvil y ubicaciones rurales o remotas simuladas, los resultados de la prueba del SDK de vídeo de Zoom fueron sólidos.

TestDevLab también ejecutó pruebas para comprobar cómo los SDK de vídeo manejaban recursos limitados, como ancho de banda, CPU y RAM. El SDK de vídeo de Zoom siguió teniendo un buen rendimiento.

TestDevLab ayuda a las startups y a las empresas de la lista Fortune 500 de todo el mundo a acelerar los ciclos de lanzamiento, mejorar la calidad de los productos y mejorar las experiencias de los usuarios. Como parte de sus servicios y soluciones, TestDevLab ofrece evaluaciones comparativas y pruebas innovadoras de calidad de audio/vídeo, pruebas funcionales, de regresión, seguridad e integración, así como servicios de automatización de pruebas para SDK, de acuerdo con las prácticas recomendadas y mediante el uso de herramientas de prueba estándar del sector y soluciones de prueba personalizadas.

Al evaluar la calidad del SDK de vídeo, hay muchos aspectos diferentes que se deben tener en cuenta, entre ellos, los siguientes:

Dispositivos del usuario: el objetivo de TestDevLab fue probar los mismos dispositivos en todos los SDK para garantizar que se puedan comparar.

Limitaciones de la red: para llevar a cabo un análisis comparativo, las condiciones de la red deben ser controlables. TestDevLab se centró en cuatro limitaciones de la red, entre ellas, el ancho de banda limitado e ilimitado aplicado al transmisor, el ancho de banda limitado al receptor y la pérdida aleatoria de paquetes del 25 %. Cada dispositivo está conectado a un enrutador diferente para garantizar una conexión de calidad.

Previsibilidad y repetibilidad: TestDevLab ejecutó ocho pruebas divididas en series de cuatro pruebas. Cada prueba se realizó en diferentes momentos para reducir el impacto de cualquier posible congestión de la red global/ralentizaciones inesperadas del servicio, etc. De esas pruebas, TestDevLab seleccionó cinco pruebas con el comportamiento más estable.

Análisis: para analizar los resultados, TestDevLab ejecutó una validación en proceso. Revisan los resultados a lo largo del tiempo de todas las pruebas, así como los vídeos de verificación puntual para confirmar la validez de los datos en comparación con una mirada subjetiva.

TestDevLab realizó las pruebas para cada escenario varias veces. En cada prueba y para todos los proveedores, TestDevLab observó resultados estables en el mismo escenario al ejecutarla varias veces. Al analizar los resultados, TestDevLab examinó lo siguiente:

calidad del rendimiento. TestDevLab analizó la calidad del retraso de audio y el retraso de vídeo en diversas condiciones de red. También analizaron la comparación de la velocidad de fotogramas, los fotogramas por segundo (FPS) y la fusión de evaluación multimétodo de vídeo (VMAF).

Administración de recursos en condiciones de red poco ideales. TestDevLab analizó cómo los proveedores administraban los recursos en una situación de pérdida de paquetes.

Uso de la CPU/RAM. TestDevLab analizó cómo los proveedores consumen recursos mientras una aplicación está bajo estrés, por ejemplo, se reproduce un vídeo de muchos participantes en una vista de galería.

La calidad del rendimiento es importante en una variedad de condiciones de red. TestDevLab probó el retraso de audio, el retraso de vídeo y las velocidades de fotogramas con una red ilimitada.

La prueba de retraso de audio entre proveedores reveló que había un retraso comparable en todos los proveedores, con la excepción de Chime, que funcionó con un retraso ligeramente más largo.

Al comparar el retraso de vídeo, Zoom, Agora, Twilio y Chime tienen un retraso de vídeo en su mayoría inferior a 250 ms. Sin embargo, Vonage TokBox tenía retrasos de vídeo que iban desde los 250 ms hasta los 1000 ms.

Al comparar las velocidades de fotogramas, la prueba reveló que Zoom tiene la velocidad de fotogramas más alta en videollamadas.

Los resultados también mostraron que Zoom tenía la calidad de vídeo más uniforme en todas las condiciones de red probadas. La prueba comenzó sin restricciones de ancho de banda. Después, se aplicó una restricción de ancho de banda baja por igual a todos los proveedores, primero en el lado del envío y luego en el lado del receptor.

Posteriormente, TestDevLab analizó la perseverancia de las fuentes durante un escenario de pérdida de paquetes del 25 %. La pérdida de paquetes puede disminuir la velocidad de la red, causar cuellos de botella, interrumpir el ancho de banda de su red y puede ser costosa. La pérdida de paquetes se puede producir por diversas razones, y muchas de ellas son involuntarias. La congestión de la red, las redes poco confiables, especialmente las móviles, los errores de software y los dispositivos sobrecargados son algunos ejemplos.

En las pruebas, que incluyeron una pérdida de paquetes del 25 %, Zoom tuvo un buen desempeño en la preservación del ancho de banda y en mantener un bajo uso de la CPU y la memoria en condiciones de pérdida de paquetes y de red restringida. Zoom proporciona una administración inteligente y es conservador, a la vez que mantiene la calidad de las llamadas.

Por otro lado, las pruebas mostraron que Agora parece tener un enfoque diferente para la pérdida de paquetes: gasta mucho ancho de banda para tratar de manejar la pérdida de paquetes. Si la tasa de bits limitada es la causa de la pérdida de paquetes, intentar consumir más ancho de banda puede causar problemas.

Al comparar la calidad de audio durante una pérdida de paquetes del 25 %, Zoom y Agora manejaron bien la calidad de audio, con niveles superiores a 4 MOS. Sin embargo, la calidad de audio de Twilio era inutilizable, y la calidad de Chime era casi inutilizable, con niveles por debajo de 3 MOS.

Al analizar el retraso de audio durante la pérdida de paquetes del 25 %, Zoom aumentó aproximadamente 100 ms en comparación con Agora, que tuvo un aumento más significativo de 200 a 250 ms para manejar la pérdida de paquetes.

Durante la comparación de la tasa de bits de red, la prueba mostró que tanto Twilio como Chime eran inestables y tenían tasas de bits muy bajas de forma predeterminada. Por otro lado, la tasa de bits de Agora fue muy alta, lo que demuestra que el producto puede no tener en cuenta una red congestionada al atribuir la causa de la pérdida de paquetes.

En cuanto al uso de la CPU, Zoom utilizó la menor cantidad de CPU en comparación con los otros cuatro proveedores en los escenarios de prueba.

Zoom también tuvo el menor uso de RAM. Como se muestra en la siguiente tabla, Twilio y Chime usaron alrededor de 500 MB de RAM durante una pérdida de paquetes del 25 %, y Agora usó más de 3 GB en videollamadas.

Los beneficios de un menor uso de CPU y RAM incluyen los siguientes:

Un menor uso de la CPU y de la RAM es el caso de uso perfecto de A/V en tiempo real integrado en otras aplicaciones que consumen muchos recursos, como videojuegos y aplicaciones de colaboración gráfica, como diseño CAD y 3D.

TestDevLab examinó el uso de la CPU por recuento de usuarios, el uso de la CPU a lo largo del tiempo y el uso de memoria a lo largo del tiempo. Durante las pruebas, los resultados mostraron que el SDK de vídeo de Zoom usaba poca CPU. Como se mencionó anteriormente, un menor uso de la CPU se puede traducir en una buena experiencia de usuario, un mejor rendimiento de la aplicación con más recursos disponibles y menos quejas de que la aplicación consume la batería.

Durante las mismas pruebas, Agora no pudo alojar una vista de galería de 32 cuadrículas. Además, Vonage TokBox utilizó sistemáticamente más CPU que los otros proveedores.

El SDK de vídeo de Zoom es una buena opción para todos los escenarios de red, incluidos aquellos con recursos limitados como ancho de banda, CPU y RAM.

Las pruebas de TestDevLab se realizaron para cada escenario varias veces, y los resultados fueron consistentes cada vez. El SDK de vídeo de Zoom se destacó por lo siguiente:

Descubra cómo acelerar su desarrollo y crear aplicaciones basadas en vídeo totalmente personalizables visitando este sitio.

Entorno de prueba

Los SDK de vídeo, incluido el SDK de vídeo de Zoom, y los de Agora, Vonage TokBox, Chime y Twilio, se probaron en un conjunto de escenarios predefinidos.

TestDevLab probó los cinco proveedores, en tres tipos de prueba, con dos cantidades diferentes de participantes y cuatro limitaciones de red diferentes, incluida la restricción ilimitada y aplicada al transmisor, la restricción aplicada al receptor y la pérdida de paquetes del 25 %. TestDevLab ejecutó ocho pruebas divididas en cuatro series de pruebas realizadas en diferentes momentos. A partir de ahí, TestDevLab seleccionó las cinco pruebas con el comportamiento más estable para producir el análisis y los resultados.

Para probar el uso de la CPU y la RAM en diferentes niveles de carga, TestDevLab creó una prueba de esfuerzo que comienza con un total de 48 usuarios en la llamada. Mientras se transmitía el vídeo, TestDevLab cambiaba el número de usuarios en la cuadrícula cada 60 segundos, para probar los escenarios de 32, 16, 8*, 4 y 2 usuarios.

Para las pruebas del rendimiento, la plataforma TestDevLab se configuró de la siguiente manera:

TestDevLab realizó escenarios de prueba de videollamada, pantalla compartida dinámica y pantalla compartida estática para el análisis del rendimiento. Cada escenario se probó cinco veces con diferentes cantidades de participantes. Se aplicó el siguiente proceso:

*El diseño de las pruebas de TestDevLab también incluía una prueba de galería de 8 participantes. Sin embargo, en la implementación de esta prueba se utilizó una resolución incorrecta, y esos resultados no se incluyen en el análisis y el informe.