Relatório de desempenho do SDK de Vídeo Zoom

Visão geral

A TestDevLab — desenvolvedora de ferramentas de garantia de qualidade de software e de testes personalizados — conduziu uma análise do SDK de Vídeo Zoom e de quatro outros fornecedores de SDK de vídeo: Agora, Vonage TokBox, Chime e Twilio. O objetivo foi compreender o comportamento de cada plataforma e a qualidade resultante de cada SDK de vídeo. Esta análise foi comissionada pela Zoom Video Communications, Inc. Os achados fornecidos neste relatório refletem os resultados de testes da TestDevLab em 12 de maio de 2022.

Este relatório descreve em primeiro lugar as considerações acerca da avaliação da qualidade do SDK de vídeo. Em seguida, é apresentada uma análise dos resultados, especificamente analisando a qualidade de desempenho, perseverança da largura de banda e a manutenção de um uso baixo da unidade de processamento central (CPU) e da memória de acesso aleatório (RAM) durante uma perda de pacotes de 25%. Detalhes acerca do ambiente de teste são fornecidos no apêndice.

Concebido para ser fácil de usar, leve e altamente personalizável, o Zoom dedicou muito esforço na qualidade do seu SDK de vídeo. Mesmo em cenários de rede adversos, casos de uso móveis e em localidades rurais ou remotas simuladas, os resultados de testes do SDK de Vídeo do Zoom foram satisfatórios.

A TestDevLab também executou testes para verificar como os SDKs de vídeo lidavam com limitação de recursos, como largura de banda, CPU e RAM. O SDK de Vídeo Zoom continuou funcionando bem.

A TestDevLab ajuda de startups a companhias da Fortune 500 de todo o mundo a acelerar ciclos de lançamento, melhorar a qualidade do produto e aperfeiçoar experiências de usuários. Como parte de seus serviços e soluções, a TestDevLab oferece testes inovadores de qualidade de áudio/vídeo, testes de benchmarking, funcionais, de regressão, segurança e integração, bem como serviços de automação de testes para SDKs, seguindo as melhores práticas e por meio das mais avançadas ferramentas do mercado e de soluções personalizadas.

Na avaliação da qualidade do SDK de vídeo, há muitos aspectos diferentes que precisam ser considerados, incluindo:

Dispositivos do usuário: o escopo da TestDevLab incluía testar os mesmos dispositivos em todos os SDKs para garantir que podiam ser comparados.

Limitações de rede: para que se conduza uma análise comparativa, as condições de rede precisam ser controláveis. A TestDevLab concentrou-se em quatro limitações de rede, incluindo largura de banda ilimitada e limitada aplicada ao remetente, largura de banda ao destinatário e perda de pacotes de 25% aleatória. Cada dispositivo foi conectado a um roteador diferente para garantir uma conexão de qualidade.

Previsibilidade e repetibilidade: a TestDevLab executou oito testes divididos em baterias de quatro testes. Cada teste foi feito em um horário diferente a fim de reduzir o impacto de qualquer congestionamento de rede global/lentidão inesperada de serviço, etc. Desses testes, a TestDevLab considerou cinco testes com o comportamento mais estável entre eles.

Análise: a fim de analisar os resultados, a TestDevLab executou uma validação dentro do processo. Foram examinados os resultados ao longo do tempo para todos os teses, bem como vídeos de fiscalização para confirmar a validade dos dados em comparação com uma análise subjetiva.

A TestDevLab conduziu os testes para cada cenário diversas vezes. Em cada teste e, para todos os fornecedores, a TestDevLab observou resultados estáveis no mesmo cenário quando executado várias vezes. Ao analisar os resultados, a TestDevLab observou:

Qualidade do desempenho. A TestDevLab analisou a qualidade do atraso de áudio e do atraso de vídeo em diversas condições de rede. Também foi observada a comparação de taxa de quadros, quadros por segundo (FPS) e a Fusão de Avaliação de Vários Métodos de Vídeo (VMAF).

Gerenciamento de recursos sob condições desfavoráveis. A TestDevLab observou como os fornecedores gerenciavam recursos em situações de perda de pacotes.

Uso de CPU/RAM. A TestDevLab observou como os fornecedores consumiam recursos enquanto o aplicativo estava sob estresse, por exemplo, quando o vídeo de muitos participantes era fornecido em uma exibição de galeria.

A qualidade do desempenho é importante em uma variedade de condições de rede. A TestDevLab testou o atraso de áudio, o atraso de vídeo e as taxas de quadros com uma rede ilimitada.

O teste de atraso de áudio entre os fornecedores constatou que havia atraso comparável em geral, com exceção da Chime, que teve um atraso ligeiramente mais longo.

Na comparação de atraso de vídeo, Zoom, Agora, Twilio e Chime tiveram um atraso de vídeo na maior parte do tempo abaixo de 250 ms. Vonage TokBox, contudo, teve atrasos de vídeo entre 250 ms e mais de 1.000 ms.

Na comparação de taxas de quadros, o teste constatou que o Zoom tinha a taxa de quadros mais alta em chamadas de vídeo.

Os resultados também demonstraram que o Zoom teve a qualidade de vídeo mais consistente em todas as condições de rede testadas. O teste começou sem restrições na largura de banda. Em seguida, uma restrição baixa na largura de banda foi aplicada de maneira igualitária a todos os fornecedores, primeiro no envio e depois no destinatário.

Em seguida, a TestDevLab analisou a perseverança das fontes em um cenário com perda de pacotes de 25%. A perda de pacotes pode reduzir a velocidade da rede, causar gargalos, interromper a largura de banda de produtividade da rede e gerar custos. Uma variedade de motivos pode causar a perda de pacotes, muitas das quais não são intencionais. Alguns exemplos incluem congestão da rede, redes pouco confiáveis, em especial as móveis, bugs de software e dispositivos sobrecarregados.

Nos testes, que incluíram uma perda de pacotes de 25%, o Zoom funcionou bem na preservação de largura de banda e na manutenção do baixo uso de CPU e memória nas condições de perda de pacotes e rede restringida. O Zoom fornece gerenciamento inteligente e é conservador na manutenção da qualidade da chamada.

Por outro lado, o teste demonstrou que a Agora parece ter uma abordagem diferente para a perda de pacotes: usa muita largura de banda na tentativa de tratamento da perda de pacotes. Se a taxa de bits limitada for a causa da perda de pacotes, tentar consumir mais largura de banda poderá causar problemas.

Na comparação da qualidade de áudio durante uma perda de pacotes de 25%, o Zoom e a Agora se saíram bem na qualidade de áudio, com níveis acima de 4,00 MOS. Contudo, a qualidade de áudio da Twilio foi impraticável, enquanto a qualidade da Chime ficou próxima de impraticável, com níveis abaixo de 3,00 MOS.

Na análise do atraso de áudio durante a perda de pacotes de 25%, o Zoom teve aumento de cerca de 100 ms comparado com a Agora, que alcançou um aumento mais significativo, de 200 a 250 ms, no tratamento da perda de pacotes.

Na comparação da taxa de bits, o teste demonstrou que Twilio e Chime ficaram instáveis e apresentaram taxas de bits muito baixas. Por outro lado, a taxa de bits da Agora foi muito alta, o que demonstra que o produto não pode dar conta de uma rede congestionada ao atribuir a causa da perda de pacotes.

Quanto ao uso de CPU, o Zoom usou a menor quantidade de CPU em comparação com os outros quatro fornecedores nos cenários de testes.

O Zoom teve também o mais baixo uso de RAM. Como mostrado no quadro abaixo, Twilio e Chime usaram cerca de 500 MB de RAM durante uma perda de pacotes de 25%, enquanto a Agora usou mais de 3 GB em chamadas de vídeo.

Os benefícios do uso mais baixo de CPU e RAM incluem:

Um uso baixo de CPU e RAM é o caso de uso perfeito para A/V em tempo real integrado em outros aplicativos pesados no consumo de recursos, como video games e aplicativos de colaboração gráficas do tipo CAD e design 3D.

A TestDevLab examinou o uso de CPU por contagem de usuários, o uso de CPU ao longo do tempo e o uso de memória ao longo do tempo. Durante os testes, os resultados demonstraram que o SDK de vídeo do Zoom teve um uso baixo de CPU. Como já mencionado, o baixo uso de CPU significa boa experiência do usuário, desempenho melhor do aplicativo com mais recursos disponíveis e menos reclamações acerca do esgotamento da bateria pelo aplicativo.

Durante os mesmos testes, a Agora foi incapaz de hospedar uma exibição de galeria com 32 grades. Além disso e de forma consistente, a Vonage TokBox usou mais CPU que os demais fornecedores.

O SDK de Vídeo Zoom é uma opção boa para todos os cenários de rede, incluindo aqueles com limitações de recursos, como largura de banda, CPU e RAM.

Os testes da TestDevLab foram conduzidos para cada cenário diversas vezes e os resultados foram sempre consistentes. O SDK de Vídeo Zoom destacou-se graças a:

Saiba como acelerar seu desenvolvimento e construir aplicativos baseados em vídeo totalmente personalizados visitando este site.

Ambiente de teste

Os SDKs de vídeo, incluindo o SDK de Vídeo Zoom e os da Agora, Vonage TokBox, Chime e Twilio, foram testados em um conjunto de cenários predefinidos.

A TestDevLab avaliou os cinco fornecedores em três tipos de testes com duas quantidades diferentes de participantes e quatro diferentes limitações de rede, incluindo rede ilimitada, restrição aplicada ao remetente, restrição aplicada no destinatário e perda de pacotes de 25%. A TestDevLab conduziu oito testes divididos em quatro baterias de testes feitos em momentos diferentes. Então, a TestDevLab tomou os cinco testes com comportamento mais estável dentre eles para produzir a análise e os resultados.

A fim de examinar o uso de CPU e RAM em diferentes níveis de carga, a TestDevLab criou um teste de estresse que começou com um total de 48 usuários na chamada. Durante a transmissão do vídeo, a TestDevLab mudava o número de usuários na grade a cada 60 segundos a fim de testar os cenários com 32, 16, 8*, 4 e 2 usuários.

Para o teste de desempenho, a plataforma da TestDevLab foi configurada da seguinte maneira:

A TestDevLab conduziu cenários de testes de chamadas de vídeo, compartilhamento de tela dinâmica e compartilhamento de tela estática para a análise de desempenho. Cada cenário foi testado cinco vezes com números diferentes de participantes. O processo a seguir foi aplicado:

* O desenho de teste da TestDevLab também incluía um teste de galeria com 8 participantes, contudo, sua implementação usou uma resolução incorreta e os respectivos resultados não foram incluídos na análise nem no relatório.