WebRCT P2P vs SFU vs CPU

WebRTC: P2P, SFU e MCU aproximam-se de uma boa comunicação

Hoje, há um número crescente de aplicações que utilizam a tecnologia WebRTC para transmitir streams de áudio/vídeo. O Nextcloud Talk, claro, mas também Jitsi, BigBlueButton e muitos outros. No entanto, existem essencialmente 3 abordagens de streaming e permitindo a escalabilidade, de poucos utilizadores até vários milhares em simultâneo.

WebRTC é essencialmente uma tecnologia peer-to-peer, e é necessário configurar um servidor central separado (ou vários, com um ou mais balanceadores de carga - Load Balancer - upstream) dependendo da finalidade do serviço, como na construção de um serviço de transmissão multimídia em larga escala ou quando o processamento de conteúdo é necessário. Dependendo do caso de uso, a arquitetura pode ser considerada da seguinte forma.

P2P (Peer to Peer) ou Mesh

Este é o modo adotado pelo Nextcloud Talk em sua versão entregue com Nextcloud (e Cloudeezy) por padrão. A conexão direta de ponta a ponta sem servidor(es) central(is) é vantajosa em termos de custo, mas como o número de pares aumenta (estrutura mesh), o sistema e a rede requerem alta capacidade. Em outras palavras, uma conexão ADSL (A = Assimétrica) é adequada para até 4 usuários simultâneos porque é limitada em Uplink (velocidade de uplink). É por isso que, neste modo de ligação, um utilizador com uma boa máquina (CPU + ligação à Internet de fibra simétrica, por exemplo) irá encontrar poucos problemas, enquanto um utilizador com ADSL irá encontrar rapidamente problemas assim que os participantes se juntem à conferência.

Talvez em poucos anos seja possível prescindir dos outros modos (CPUs cada vez mais potentes, fibras muito potentes ou conexões de 5G que são generalizadas globalmente), mas no momento, precisamos de estabelecer centralizações (em datacenter ou "on-premises" se o link - simétrico - for ideal) para superar este problema e transferir a carga dos clientes para os servidores, muito mais potentes.

SFU (Selective Shipping Unit)

Este é um servidor central (ou servidores) que retransmite o tráfego multimídia, e cada par se conecta a ele para o processamento de decriptação/encriptação. É adequado para uma estrutura de serviços de streaming, como o vídeo streaming. Esta modalidade é utilizada, entre outras, por Jitsi.

MCU (Unidade de Controlo Multiponto)

Como um método de servidor central no qual uma pluralidade de meios de transmissão é misturada ou transcodificada por um servidor central e entregue a um lado receptor, a carga no cliente e na rede é consideravelmente reduzida, enquanto que é necessário um alto poder computacional do servidor central. Este é o modo adoptado pelo Nextcloud Talk na sua versão HPB (opcional nas nossas ofertas de alojamento Nextcloud).

Tabela de comparação de necessidades para cada abordagem

  P2P SFU MCU
Taxa de transferência (em upload) Alto Baixo Baixo
Taxa de fluxo (download) Alto Baixo Alto
Utilização da CPU do cliente Alto Baixo Médio
Usando a CPU do servidor - Alto Baixo
Possível latência Depende da largura de banda da rede Depende da potência do processador Depende da largura de banda da rede
Capacidade de transcodificação - Sim Não
Capacidade Simulcast / SVC - - Sim

Conclusão

É necessário um design adaptado aos casos de uso, tais como metas de serviço e custos. Como regra geral :

  • chamadas de voz/vídeo em pequena escala (1:1) são P2P, serviços de transmissão unidirecional de nível médio ou superior (por exemplo, e-Learning, Broadcasting, etc.).
  • serviços para fins como videoconferência são SFU, conversação de voz em larga escala (por exemplo, mistura de vozes)
  • Os sistemas de controle em tempo real (por exemplo, transcodificação de vídeo para rede) são projetados principalmente com MCU.

A opção de malha completa (P2P) é viável desde que o número de participantes seja pequeno. Como mencionado no artigo, o principal problema é a largura de banda. A MCU parece ser uma solução fácil, mas tem problemas de escala e custo.

Existem "soluções" para limitar os problemas, por exemplo, baixas resoluções para cada participante (vídeo de menor qualidade = menores requisitos de CPU para decodificação e menores requisitos de largura de banda para envio/recepção), mas hoje ninguém quer fazer uma conferência "pixelada" com nossas telas de alta resolução.

Uma arquitetura de serviço de videoconferência pode incluir uma combinação das 3 opções ou parte delas e o uso de cada uma dependendo da lógica do serviço e do tipo / número de participantes, por exemplo, uma combinação de malha completa (P2P) e SFU.

Outros artigos semelhantes