Analyse comparative du SDK vidéo de Zoom
TestDevLab, prestataire de services d’assurance qualité logicielle et de développement d’outils de test personnalisés, a effectué une analyse du SDK vidéo de Zoom et de quatre autres fournisseurs de SDK vidéo : Agora, Vonage TokBox, Chime et Twilio. L’objectif était de comprendre le comportement de chaque plateforme et la qualité résultante de chaque SDK vidéo. Cette analyse a été effectuée à la demande de Zoom Communications, Inc. Les conclusions présentées dans ce rapport reflètent les résultats des tests effectués par TestDevLab le 12 mai 2022.
Ce rapport décrit tout d’abord les éléments à prendre en compte pour évaluer la qualité du SDK vidéo. Ensuite, une analyse des résultats est présentée, examinant spécifiquement la qualité des performances, la persévérance de la bande passante et le maintien d’une utilisation faible du processeur (CPU) et de la mémoire vive (RAM) lors d’une perte de paquets de 25 %. Les détails relatifs à l’environnement de test sont fournis en annexe.
Conçu pour être facile à utiliser, léger et hautement personnalisable, Zoom a consacré beaucoup d’efforts à la qualité globale de son SDK vidéo. Même dans des scénarios de réseau médiocre, d’utilisation mobile ou d’emplacement rural ou distant, les résultats des tests du SDK vidéo de Zoom étaient bons.
TestDevLab a également effectué des tests pour observer comment les SDK vidéo géraient des ressources (par ex., bande passante, processeur, RAM) limitées. Le SDK vidéo de Zoom a continué de bien fonctionner.
TestDevLab aide les startups et les entreprises du Fortune 500 du monde entier à accélérer leurs cycles de publication, à renforcer la qualité de leurs produits et à améliorer l’expérience utilisateur. Dans le cadre de ses services et solutions, TestDevLab propose des analyses comparatives et des tests innovants de la qualité audio/vidéo, des tests de fonctionnalité, de régression, de sécurité et d’intégration, ainsi que des services d’automatisation des tests pour les SDK, respectant les meilleures pratiques et utilisant des outils de test standard du secteur et des solutions de test personnalisées.
Lors de l’évaluation de la qualité du SDK vidéo, de nombreux aspects doivent être pris en compte, notamment :
Appareils de l’utilisateur : TestDevLab a choisi de tester les mêmes appareils sur tous les SDK pour garantir leur comparabilité.
Limitations du réseau : pour effectuer une analyse comparative, les conditions du réseau doivent pouvoir être contrôlées. TestDevLab s’est concentré sur quatre limitations de réseau, notamment une bande passante illimitée, une bande passante limitée appliquée à l’expéditeur, une bande passante limitée pour le récepteur et une perte de paquets aléatoire de 25 %. Chaque appareil est connecté à un routeur différent pour assurer une connexion de qualité.
Prévisibilité et répétabilité : TestDevLab a exécuté huit tests divisés en séries de quatre tests. Chaque test a été effectué à des moments différents afin de réduire l’impact d’une éventuelle congestion du réseau mondial ou d’un ralentissement inattendu du service, etc. Parmi tous ces tests, TestDevLab en a sélectionné cinq, dont le comportement était le plus stable.
Analyse : pour analyser les résultats, TestDevLab a effectué une validation en cours de processus. Il a examiné les résultats de tous les tests au fil du temps ainsi que des vidéos de contrôle ponctuel pour confirmer la validité des données par rapport à un regard subjectif.
TestDevLab a effectué les tests pour chaque scénario plusieurs fois. Dans chaque test et pour tous les fournisseurs, TestDevLab a constaté des résultats stables pour le même scénario lorsque celui-ci est exécuté plusieurs fois. Lors de l’analyse des résultats, TestDevLab a examiné les éléments suivants :
Qualité des performances. TestDevLab a analysé la qualité du retard audio et du retard vidéo dans diverses conditions de réseau. Il a également examiné la comparaison de fréquence d’image, le nombre d’images par seconde (FPS) et la fusion d’évaluation multiméthode vidéo (VMAF).
Gestion des ressources dans les conditions du réseau Unideal. TestDevLab a examiné la manière dont les fournisseurs géraient les ressources en cas de perte de paquets.
Utilisation processeur/RAM. TestDevLab a examiné la consommation des ressources par les fournisseurs lorsqu’une application était sous pression, par exemple lorsque les vidéos de nombreux participants étaient proposées dans une vue Galerie.
La qualité des performances est importante dans de multiples conditions de réseau. TestDevLab a testé le retard audio, le retard vidéo et les fréquences d’images avec un réseau illimité.
Le test du retard audio chez les différents fournisseurs a révélé qu’il existait un retard comparable à tous les niveaux, à l’exception de Chime qui a fonctionné avec un retard légèrement plus long.
En ce qui concerne le retard vidéo, Zoom, Agora, Twilio et Chime présentaient un retard vidéo généralement inférieur à 250 ms. Vonage TokBox présentait toutefois des retards vidéo pouvant aller de 250 à plus de 1 000 ms.
Pour la comparaison des fréquences d’images, le test a révélé que Zoom présentait la fréquence d’image la plus élevée sur les appels vidéo.
Les résultats ont également montré que Zoom offrait la qualité vidéo la plus constante dans toutes les conditions de réseau testées. Le test a commencé sans restriction de bande passante, puis une restriction de bande passante faible a été appliquée de manière égale à tous les fournisseurs, d’abord côté envoi, puis côté récepteur.
Ensuite, TestDevLab a examiné la persévérance des sources dans un scénario de perte de paquets de 25 %. La perte de paquets peut ralentir la vitesse du réseau, provoquer des goulots d’étranglement, interrompre la bande passante de votre réseau et s’avérer très coûteuse. La perte de paquets peut être causée par divers facteurs, et bon nombre d’entre eux ne sont pas intentionnels. La congestion du réseau, les réseaux peu fiables, en particulier mobiles, les bogues logiciels et les appareils saturés en sont quelques exemples.
Dans les tests, qui comprenaient une perte de paquets de 25 %, Zoom a bien réussi à préserver la bande passante et à maintenir l’utilisation du processeur et de la mémoire à un faible niveau de perte de paquets et de conditions réseau contraintes. Zoom permet une gestion intelligente et conservatrice tout en maintenant la qualité des appels.
D’autre part, les tests ont montré qu’Agora semblait avoir une approche différente de la perte de paquets en consommant beaucoup de bande passante pour tenter de gérer la perte de paquets. Si le débit limité est la cause de la perte de paquets, une consommation plus importante de la bande passante peut entraîner des problèmes.
Pour ce qui est de la qualité audio lors d’une perte de paquets de 25 %, Zoom et Agora ont bien géré la qualité audio, avec des niveaux supérieurs à 4,00 MOS. Cependant, la qualité audio de Twilio était inutilisable et la qualité de Chime était proche de l’inutilisable, avec des niveaux inférieurs à 3,00 MOS.
En ce qui concerne le retard audio pendant la perte de paquets de 25 %, Zoom était plus rapide d’environ 100 ms par rapport à Agora, qui a subi une augmentation plus significative de 200 à 250 ms pour gérer la perte de paquets.
En ce qui concerne la comparaison du débit réseau, le test a montré que Twilio et Chime étaient instables et avaient par défaut des débits en bits très faibles. D’autre part, le débit d’Agora était très élevé, ce qui démontre que le produit peut ne pas tenir compte d’un réseau saturé lors de l’attribution de la cause de la perte de paquets.
En ce qui concerne l’utilisation du processeur, Zoom a eu la plus faible utilisation de processeur par rapport aux quatre autres fournisseurs dans les divers scénarios de test.
Zoom présentait également la plus faible utilisation de RAM. Comme le montre le graphique ci-dessous, Twilio et Chime ont tous deux utilisé environ 500 Mo de RAM lors d’une perte de paquets de 25 %, et Agora a utilisé plus de 3 Go pour les appels vidéo.
Avantages d’une utilisation réduite du processeur et de la RAM :
Une utilisation réduite du processeur et de la RAM est le cas d’utilisation idéal de l’A/V en temps réel intégré dans d’autres applications gourmandes en ressources, telles que les jeux vidéo, et les applications de collaboration graphique, telles que la CAO et la conception 3D.
TestDevLab a examiné l’utilisation du processeur par nombre d’utilisateurs, l’utilisation du processeur au fil du temps et l’utilisation de la mémoire au fil du temps. Au cours des tests, les résultats ont montré que le SDK vidéo de Zoom utilisait peu le processeur. Comme mentionné ci-dessus, une utilisation réduite du processeur peut se traduire par une meilleure expérience utilisateur, de meilleures performances des applications grâce à des ressources disponibles plus nombreuses et une réduction du nombre de plaintes concernant la consommation de la batterie par l’application.
Au cours des mêmes tests, Agora n’a pas permis d’héberger une vue galerie de 32 grilles. En outre, Vonage TokBox a systématiquement utilisé plus de processeur que les autres fournisseurs.
Le SDK vidéo de Zoom est une bonne option pour l’ensemble des scénarios réseau, y compris ceux dont les ressources (bande passante, processeur, RAM, etc.) sont limitées.
Les tests de TestDevLab ont été effectués plusieurs fois pour chaque scénario et les résultats étaient toujours cohérents. Le SDK vidéo de Zoom s’est démarqué pour les éléments suivants :
Découvrez comment accélérer votre développement et apprenez à créer des applications vidéo entièrement personnalisables en visitant la page du SDK vidéo de Zoom.
Les SDK vidéo, notamment les SDK vidéo de Zoom, Agora, Vonage TokBox, Chime et Twilio, ont été testés dans un ensemble de scénarios prédéfinis.
TestDevLab a testé les cinq fournisseurs, sur trois types de tests, avec deux groupes de participants de tailles différentes et quatre limitations de réseau différentes (illimité, restriction appliquée à l’expéditeur, restriction appliquée au destinataire et perte de paquets de 25 %). TestDevLab a mené huit tests, répartis en quatre séries de tests effectuées à différents moments. À partir de là, TestDevLab a pris les cinq tests lors desquels le comportement était le plus stable pour générer l’analyse et les résultats.
Pour tester l’utilisation du processeur et de la RAM sous différents niveaux de charge, TestDevLab a créé un test de contrainte qui commence avec un total de 48 utilisateurs sur l’appel. Au cours de la diffusion de la vidéo, TestDevLab a changé le nombre d’utilisateurs sur la grille toutes les 60 secondes, afin de tester les scénarios pour 32, 16, 8*, 4 et 2 utilisateurs.
Pour les tests de performance, la plateforme TestDevLab a été configurée de la manière suivante :
TestDevLab a mené des scénarios d’appel vidéo, de partage d’écran dynamique et de partage d’écran statique pour l’analyse des performances. Chaque scénario a été testé cinq fois avec un nombre différent de participants. Le processus suivant a été appliqué :
* La conception du test TestDevLab comprenait également un test de galerie à 8 participants. Toutefois, la mise en œuvre de ce test a utilisé une résolution incorrecte et ces résultats ne sont pas inclus dans l’analyse et le rapport.
