Report sulle prestazioni Video SDK di Zoom

Panoramica

TestDevLab – fornitore specializzato nella garanzia della qualità dei software che offre uno strumento di testing personalizzato – ha condotto un’analisi su Video SDK di Zoom e altri quattro fornitori di Video SDK: Agora, Vonage TokBox, Chime e Twilio. L’obiettivo era capire il comportamento di ogni piattaforma e il livello di qualità di ogni Video SDK. Questa analisi è stata commissionata da Zoom Video Communications, Inc. I risultati forniti in questo report rispecchiano i risultati dei test TestDevLab del 12 maggio 2022.

In questo report vengono innanzitutto descritte le considerazioni relative alla valutazione della qualità del Video SDK. In seguito viene presentata un’analisi dei risultati, con un’attenzione particolare alla qualità delle prestazioni, la stabilità della larghezza di banda e il mantenimento dell’utilizzo basso dell’unità centrale di elaborazione (CPU) e della memoria ad accesso casuale (RAM) durante una perdita di pacchetti del 25%. L’appendice contiene le informazioni relative all’ambiente di prova.

Zoom si è impegnato molto per raggiungere la qualità complessiva del suo Video SDK, offrendo un prodotto facile da usare, leggero e altamente personalizzabile. Anche nei scenari di rete insufficiente, casi d’uso su dispositivi mobili e località rurali o remote simulate, i risultati dei test del Video SDK di Zoom sono stati eccezionali.

Inoltre TestDevLab ha eseguito dei test per vedere la capacità dei Video SDK di gestire risorse limitate come larghezza di banda, CPU e RAM. Il video SDK di Zoom ha mantenuto delle buone prestazioni.

TestDevLab aiuta le startup e le aziende Fortune 500 in tutto il mondo a velocizzare i cicli di rilascio, aumentare la qualità dei prodotti e migliorare le esperienze degli utenti. Come parte dei servizi e delle soluzioni offerte, TestDevLab fornisce test di qualità audio/video e parametri di riferimento innovativi, test funzionali, di regressione, sicurezza e integrazione, nonché servizi di automazione dei test per SDK, seguendo le best practice e utilizzando strumenti di testing standard del settore e soluzioni di testing personalizzate.

Quando si valuta la qualità del Video SDK è necessario considerare molteplici aspetti, tra cui:

Dispositivi utente: lo scopo di TestDevLab era testare gli stessi dispositivi su tutti gli SDK per renderne possibile la comparazione.

Limitazioni di rete: per condurre un’analisi comparativa, le condizioni della rete devono essere controllabili. L’analisi TestDevLab si è concentrata su quattro limitazioni di rete, tra cui larghezza di banda illimitata e limitata applicata al mittente, larghezza di banda limitata al destinatario e perdita casuale di pacchetti del 25%. Ogni dispositivo è collegato a un router diverso per garantire una connessione di qualità.

Prevedibilità e ripetibilità: TestDevLab ha eseguito otto test suddivisi in esecuzioni di quattro test. Ogni test è stato eseguito in momenti diversi per ridurre l’impatto di eventuali congestioni della rete globale/rallentamenti imprevisti del servizio, ecc. Da questi test, TestDevLab ha eseguito cinque test con il comportamento più stabile.

Analisi: per analizzare i risultati, TestDevLab ha eseguito una convalida in-process. Per confermare la validità dei dati rispetto a un’osservazione soggettiva, si esaminano i risultati nel tempo su tutti i test e su video a campione.

TestDevLab ha eseguito i test per ogni scenario più volte. In ogni test e per tutti i fornitori, TestDevLab ha riscontrato risultati stabili nello stesso scenario quando i test sono stati ripetuti. Durante l’analisi dei risultati, TestDevLab ha esaminato:

Qualità delle prestazioni. TestDevLab ha analizzato la qualità del ritardo dell’audio e del video in diverse condizioni di rete. Inoltre sono stati esaminati il confronto della frequenza dei fotogrammi, i fotogrammi al secondo (FPS) e VMAF (Video Multimethod Assessment Fusion).

Gestione delle risorse in condizioni di rete non ottimali. TestDevLab ha esaminato la modalità in cui i fornitori hanno gestito le risorse in una situazione di perdita di pacchetti.

Utilizzo CPU/RAM. TestDevLab ha esaminato la modalità in cui i fornitori utilizzano le risorse mentre un’applicazione è sottoposta a uno stress test, ad esempio rendering video di molti partecipanti con vista galleria.

Quando le condizioni di rete sono varie, la qualità delle prestazioni è un fattore importante. TestDevLab ha testato il ritardo audio, il ritardo video e le frequenze fotogrammi in una rete illimitata.

Il test del ritardo audio tra i fornitori ha rilevato un ritardo comparabile su tutta la linea, ad eccezione di Chime, che ha funzionato con un ritardo leggermente maggiore.

Mettendo a confronto il ritardo video, Zoom, Agora, Twilio e Chime hanno un ritardo video per lo più inferiore a 250 ms. Vonage TokBox, tuttavia, ha avuto ritardi video tra 250ms e 1.000ms.

Confrontando le frequenze fotogrammi, il test ha rilevato che Zoom ha la frequenza fotogrammi più alta sulle videochiamate.

Inoltre, secondo i risultati, Zoom ha dimostrato una qualità video più costante in tutte le condizioni di rete testate. Durante la parte iniziale del test non erano presenti restrizioni sulla larghezza di banda; in seguito a tutti i fornitori è stata applicata una restrizione bassa sulla larghezza di banda, prima sul lato mittente, poi su quello destinatario.

Successivamente, TestDevLab ha esaminato la stabilità delle origini durante uno scenario di perdita di pacchetti del 25%. La perdita di pacchetti può rallentare la velocità di rete, causare colli di bottiglia, interrompere la larghezza di banda del throughput di rete e risultare costosa. La perdita di pacchetti può essere causata da una serie di motivi e molti di essi non sono intenzionali. Alcuni esempi: congestione della rete, reti inaffidabili (soprattutto reti mobili), bug del software e dispositivi sovraccarichi.

Nei test, che includevano una perdita di pacchetti del 25%, Zoom ha ottenuto buoni risultati nel mantenimento della larghezza di banda e garantendo un utilizzo basso della CPU e della memoria nella perdita di pacchetti e nelle condizioni di rete limitate. Zoom offre una gestione intelligente e ha un approccio conservativo pur mantenendo la qualità delle chiamate.

D’altra parte, i test hanno dimostrato che Agora sembra avere un approccio diverso rispetto alla perdita di pacchetti, utilizzando molta larghezza di banda per cercare di gestirne la perdita. Se la velocità di trasmissione limitata è la causa della perdita di pacchetti, il tentativo di consumare più larghezza di banda può generare problemi.

Confrontando la qualità audio durante una perdita di pacchetti del 25%, Zoom e Agora hanno gestito bene la qualità audio, con livelli superiori a 4,00 MOS. Tuttavia, la qualità audio di Twilio è risultata inutilizzabile e la qualità di Chime quasi inutilizzabile, con livelli inferiori a 3,00 MOS.

Esaminando il ritardo audio durante la perdita di pacchetti del 25%, Zoom è aumentato di circa 100 ms rispetto ad Agora, che ha registrato un aumento più significativo, di 200-250 ms, per gestire la perdita di pacchetti.

Durante il confronto sulla velocità di trasmissione della rete, il test ha dimostrato che sia Twilio che Chime erano instabili e che avevano velocità di trasmissione molto basse per impostazione predefinita. D’altra parte, la velocità di trasmissione di Agora è risultata molto alta, dimostrando che il prodotto potrebbe non tenere conto di una congestione di rete quando determina la causa della perdita di pacchetti.

Per quanto riguarda l’utilizzo della CPU, Zoom ha utilizzato la quantità minima di CPU rispetto agli altri quattro fornitori negli scenari di test.

Inoltre Zoom ha registrato l’utilizzo più basso di RAM. Come mostrato nel grafico seguente, Twilio e Chime hanno entrambi utilizzato circa 500 MB di RAM durante una perdita di pacchetti del 25% e Agora ha utilizzato più di 3 GB durante le videochiamate.

I vantaggi di un utilizzo minore di CPU e RAM includono:

Un utilizzo minore di CPU e RAM è il caso d’uso ideale di A/V incorporati in tempo reale in altre applicazioni ad alto consumo di risorse come i videogiochi e le applicazioni di collaborazione grafica come CAD e di progettazione 3D.

TestDevLab ha esaminato l’utilizzo della CPU per numero di utenti, l’utilizzo della CPU nel tempo e l’utilizzo della memoria nel tempo. Durante i test, i risultati hanno dimostrato che il Video SDK di Zoom ha utilizzato una CPU bassa. Come accennato in precedenza, un minore utilizzo della CPU può tradursi in una buona esperienza utente, prestazioni migliori dell’app con più risorse disponibili e meno lamentele sul consumo della batteria dovuto all’app.

Durante gli stessi test, Agora non è stata in grado di ospitare una vista galleria a 32 griglie. Inoltre, Vonage TokBox ha utilizzato costantemente più CPU rispetto agli altri fornitori.

Il Video SDK di Zoom è una buona opzione per tutti gli scenari di rete, inclusi quelli con risorse limitate come larghezza di banda, CPU e RAM.

I test di TestDevLab sono stati condotti per ogni scenario più volte e hanno generato gli stessi risultati ogni volta. Il Video SDK di Zoom si è distinto per:

Visita questo sito per scoprire come accelerare lo sviluppo e creare applicazioni basate su video completamente personalizzabili.

Ambiente di test

I video SDK, inclusi i Video SDK di Zoom e di Agora, Vonage TokBox, Chime e Twilio, sono stati testati in una serie di scenari predefiniti.

TestDevLab ha testato tutti e cinque i fornitori conducendo tre tipi di test, con due numeri diversi di partecipanti e quattro limitazioni di rete differenti, tra cui restrizioni illimitate applicate al mittente, restrizioni applicate sul destinatario e perdita di pacchetti del 25%. TestDevLab ha eseguito otto test, suddivisi in esecuzioni di quattro test, in momenti diversi. Dopodiché, TestDevLab ha preso come riferimento i cinque test che hanno rilevato i comportamenti più stabili per produrre l’analisi e i risultati.

Per testare l’utilizzo della CPU e della RAM in diversi livelli di carico, TestDevLab ha creato uno stress test che inizia con un totale di 48 utenti durante la chiamata. Durante la trasmissione del video, TestDevLab ha cambiato il numero di utenti sulla griglia ogni 60 secondi, al fine di testare diversi scenari, da 32, 16, 8*, 4 e 2 utenti.

Per il test delle prestazioni, la piattaforma TestDevLab è stata configurata nel modo seguente:

TestDevLab ha condotto test su videochiamate, condivisione dinamica dello schermo e condivisione statica dello schermo per l’analisi delle prestazioni. Ogni scenario è stato testato cinque volte e con un numero diverso di partecipanti. È stato applicato il seguente processo:

* Nel progetto di testing TestDevLab è stato incluso anche un test della galleria con 8 partecipanti. Tuttavia, nell’implementazione di questo test è stata utilizzata una risoluzione errata e i risultati prodotti non sono inclusi nell’analisi e nel report.