Prestandarapport för Zoom Video SDK

En jämförande analys av Zoom Video SDK

Prestandarapport för Zoom Video SDK

Översikt

TestDevLab – en utvecklingsleverantör för kvalitetssäkring av programvara och anpassade testverktyg – utförde en analys av Zoom Video SDK och fyra andra Video SDK-leverantörer: Agora, Vonage TokBox, Chime och Twilio. Målet var att förstå hur varje plattform beter sig och vilken den resulterande kvaliteten blir för varje Video SDK. Analysen beställdes av Zoom Video Communications, Inc. Resultaten som tillhandahålls i denna rapport speglar TestDevLabs testresultat från 12 maj 2022.

Rapporten beskriver först de faktorer som tagits med vid bedömningen av Video SDK-kvaliteten. Sedan presenteras en analys av resultaten, som specifikt tittar på prestandakvaliteten, bandbreddsbeständigheten och hur väl plattformen klarar av att hålla användningen av CPU (processor) och RAM (random-access memory) låg under en paketförlust på 25 %. Detaljerna kring testmiljön presenteras i bilagan.

Zoom har lagt ner mycket arbete på att skapa en Video SDK av hög kvalitet som är utformad för att vara resursbesparande, enkel att anpassa och lätt att använda. Även under bristfälliga nätverksförhållanden, användningsfall med mobilanvändning och simulerade lantliga eller avlägsna platser var testresultaten för Zoom Video SDK mycket goda.

TestDevLab körde även test för att se hur Video SDK hanterar begränsade resurser som bandbredd, CPU och RAM. Zoom Video SDK fortsatte att prestera väl.

TestDevLab hjälper startups och Fortune 500-företag över hela världen att snabba på sina lanseringscykler, förbättra produktkvaliteten och förbättra användarupplevelsen. Som en del av sina tjänster och lösningar erbjuder TestDevLab innovativa test för ljud- och videokvalitet, test för benchmarking, funktionalitet, regression, säkerhet och integrering samt testautomatiseringstjänster för SDK, som följer bästa praxis och använder anpassade testlösningar och testverktyg som följer branschstandarden.

Utvärdera Video SDK-kvalitet

När kvaliteten hos Video SDK utvärderas finns det många aspekter som måste tas med i beräkningen, såsom:

Användarenheter: TestDevLabs analys baserades på att samma enheter skulle testas med alla SDK:er för att säkerställa en rättvisande jämförelse.

Nätverksbegränsningar: Nätverksförhållandena måste kunna kontrolleras för att en jämförande analys ska kunna utföras. TestDevLab fokuserade på fyra nätverksbegränsningar, som bestod av obegränsad respektive begränsad bandbredd för avsändaren, begränsad bandbredd för mottagaren och slumpmässig paketförlust på 25 %. Alla enheter ansluts till olika routrar för att säkerställa en god anslutning.

Förutsägbarhet och repeterbarhet: TestDevLab utförde åtta test som delades upp i testomgångar om fyra test. Varje test kördes vid olika tider för att minska inverkan från eventuella globala nätverksöverbelastningar/oväntad nedsaktning av tjänsten osv. Av dessa test valde TestDevLab ut de fem test som uppvisade det mest stabila beteendet.

Analys: TestDevLab gjorde en validering under processens gång för att analysera resultaten. De gick igenom resultaten över tid för alla test samt gjorde stickprov av videor för att bekräfta datagiltigheten jämfört med en subjektiv kontroll.

Prestandaresultat och -analys

TestDevLab körde testen flera gånger för varje scenario. I varje test och för alla leverantörer såg TestDevLab stabila resultat för samma scenario när det kördes flera gånger. När resultaten analyserades tittade TestDevLab på:

Prestandakvalitet. TestDevLab analyserade kvaliteten på ljud- och videofördröjningar under olika nätverksförhållanden. De tittade också på bildhastighetsjämförelser, bildrutor per sekund (FPS) och Video Multimethod Assessment Fusion (VMAF).

Resurshantering under icke idealiska nätverksförhållanden. TestDevLab tittade på hur leverantörer hanterade resurser under situationer med paketförluster.

CPU-/RAM-användning. TestDevLab tittade på hur leverantörer använder resurser när en applikation är under belastning, t.ex. när många deltagares videor renderas i en gallerivy.

Prestandakvalitet

Prestandakvalitet är viktigt för en mängd olika nätverksförhållanden. TestDevLab testade ljudfördröjning, videofördröjning och bildhastighet med ett obegränsat nätverk.

Vid testet av ljudfördröjning mellan olika leverantörer såg man att samtliga hade en jämförbar fördröjning, med undantag för Chime, som uppvisade en något längre fördröjning.

När videofördröjningen jämfördes hade Zoom, Agora, Twilio och Chime en videofördröjning på under 250 ms. Vonage TokBox hade däremot videofördröjningar från 250 ms upp till 1 000 ms.

Vid jämförelse av bildhastighet visade testet att Zoom hade den högsta bildhastigheten för videosamtal.

Jämförelsediagram för obegränsad FPS

Resultaten visade också att Zoom hade den mest konsekventa videokvaliteten under alla testade nätverksförhållanden. Testet började utan bandbreddsbegränsningar och därefter tillämpades en begränsning med låg bandbredd på alla leverantörer, först på sändarsidan och sedan på mottagarsidan.

Återställning av bildhastighet vid test med begränsad mottagare

Resurshantering under icke idealiska nätverksförhållanden

Sedan tittade TestDevLab på källornas beständighet under ett scenario med 25 % paketförlust. Paketförlust kan leda till långsammare nätverkshastighet, orsaka flaskhalsar, avbryta nätverkets bandbreddsgenomströmning och bli kostsamt. Paketförlust kan uppstå av många olika anledningar, och många av dem är oavsiktliga. Nätverksöverbelastning, opålitliga nätverk (särskilt mobila), programvarubuggar och överbelastade enheter är några exempel.

I testen, som inkluderade en paketförlust på 25 %, presterade Zoom väl när det kom till att bevara bandbredd, samt att hålla CPU- och minnesanvändningen låg under paketförlust och begränsade nätverksförhållanden. Zoom har smart hantering och är konservativt när det gäller att upprätthålla samtalskvaliteten.

Å andra sidan visade testen att Agora verkar hantera paketförluster på ett annat sätt, och lägger mycket bandbredd på att försöka hantera paketförluster. Om paketförlusten orsakas av en begränsad bithastighet kan fler problem uppstå om mer bandbredd används.

Vid jämförelsen av ljudkvaliteten vid en paketförlust på 25 % hanterade Zoom och Agora ljudkvaliteten på ett bra sätt, med nivåer över 4,00 MOS. Twilios ljudkvalitet, å andra sidan, var oanvändbar, och Chimes kvalitet var nästan oanvändbar, med nivåer under 3,00 MOS.

POLQA-jämförelsediagram för 25 % paketförlust

Vid ljudfördröjningar under en paketförlust på 25 % ökade Zoom med cirka 100 ms jämfört med Agora, som hade en mer markant ökning på 200–250 ms för att hantera paketförlusten.

Under jämförelsen av nätverksbithastighet visade testet att både Twilio och Chime var instabila och växlade till mycket låga bithastigheter som standard. Agoras bithastighet var å andra sidan mycket hög, vilket visar att produkten kanske inte tar med ett överbelastat nätverk i beräkningen när orsaken till paketförlust ska utvärderas.

Jämförelse av sänd bithastighet vid sändning, 25 % paketförlust

Jämförelse av sänd bithastighet vid mottagande, 25 % paketförlust

När det kommer till CPU-användning förbrukade Zoom minst CPU jämfört med de fyra andra leverantörerna i samtliga testscenarier.

CPU-jämförelse vid 25 % paketförlust

Zoom hade också den lägsta RAM-användningen. Som diagrammet nedan visar använde både Twilio och Chime omkring 500 MB RAM under en paketförlust på 25 % och Agora använde över 3 GB vid videosamtal.

RAM-jämförelse vid 25 % paketförlust

CPU-/RAM-användning

Fördelarna med lägre CPU- och RAM-användning inkluderar:

  • Bättre användarupplevelse
  • Bättre app-prestanda med fler tillgängliga resurser
  • Färre klagomål om att appen använder mycket batteri
  • Användaren kan använda andra applikationer samtidigt som en videokonferens pågår

Lägre CPU- och RAM-användning är det perfekta användningsfallet för inbäddad realtids-A/V i andra applikationer med hög resursanvändning, som videospel och grafiska samarbetsapplikationer som CAD och 3D design.

TestDevLab undersökte CPU-användning per användarantal, CPU-användning över tid och minnesanvändning över tid. Under testen visade resultaten att Zoom Video SDK hade låg CPU-användning. Som nämns ovan kan lägre CPU-användning leda till en god användarupplevelse, bättre app-prestanda med fler tillgängliga resurser och färre klagomål om att appen använder mycket batteri.

CPU-användning per användarantal

Jämförelse av systemets CPU-nät

CPU-användning över tid – CPU vid obegränsad mottagare

CPU-användning över tid – system-CPU vid obegränsad mottagare

Under vissa test kunde Agora inte hantera en gallerivy med 32 rutor. Dessutom använde Vonage TokBox genomgående mer CPU än andra leverantörer.

Sammanfattning

Zoom Video SDK är ett bra alternativ för alla nätverksscenarier, inklusive de med begränsade resurser som bandbredd, CPU och RAM.

TestDevLabs test kördes flera gånger för varje scenario och resultaten var konsekventa varje gång. Resultaten för Zoom Video SDK utmärkte sig bland de övriga på grund av:

  • Prestandakvalitet
  • Bandbreddspålitlighet
  • CPU-/RAM-användning

Läs om hur du kan påskynda utvecklingen och skapa helt anpassningsbara videobaserade applikationer på den här webbplatsen.

Bilaga

Testmiljö

Video SDK:er, inklusive Zoom Video SDK, Agora, Vonage TokBox, Chime och Twilio, testades i ett antal fördefinierade scenarier.

TestDevLab testade alla fem leverantörerna utifrån tre olika testtyper, med två olika deltagarmängder och fyra olika nätverksbegränsningar, inklusive obegränsat, med begränsningar tillämpade på avsändaren, med begränsningar tillämpade på mottagaren och med 25 % paketförlust. TestDevLab körde åtta test uppdelade i fyra test som kördes vid olika tider. Utifrån det valde TestDevLab ut de fem test som genomgående hade det mest stabila beteendet för att skapa analyser och resultat.

För att testa CPU- och RAM-användningen under olika arbetsbelastningar skapade TestDevLab ett stresstest som började med totalt 48 användare i samtalet. Medan videon streamades ändrade TestDevLab antalet användare i rutnätet var 60:e sekund för att testa scenarier med 32, 16, 8*, 4 och 2 användare.

För prestandatesten konfigurerades TestDevLab-plattformen på följande sätt:

  • Avsändarenhet: MSI Katana GF66 11UD i7-11800H, 8 GB, 512 GB SSD, GeForce RTX 3050 Ti 4 GB
  • Mottagarenhet: Lenovo ThinkPad E495|R5 3500U|16 GB|512 SSD|Vega 8 (20NE-001GMH)
  • Videosamtalsupplösning: 1 080 x 720
  • Skärmdelningsupplösning: 1 920 x 1 080 (skärmupplösning)
  • Videobildhastighet: 30 FPS
  • Videobithastighet: 3 000 kb/s

TestDevLab utförde testscenarier med videosamtal, dynamisk videodelning och statisk skärmdelning för prestandaanalysen. Varje scenario testades fem gånger med olika deltagarantal. Följande process användes:

  • Tillämpa nätverksbegränsning
  • Skapa ett samtal med sändarenheten
  • Gå med i samtalet med mottagarenheten och extra deltagare
  • Börja streama video- eller skärmdelning
  • Parallellt – samla in råtestdata
  • Lämna samtalet i motsatt ordning mot anslutningsordningen när videon avslutas
  • Bearbeta rådata
  • Validera bearbetade data

* TestDevLab-testdesignen inkluderade också ett galleritest med 8 deltagare, men implementeringen av det här testet använde en felaktig upplösning och resultaten av det togs inte med i analysen och rapporten.