Cenário ilustrativo: Morgan usa um laptop antigo para uma chamada do Jitsi Meet. O ventilador fica barulhento e o uso da CPU pelo navegador permanece alto quando várias pessoas estão com as câmeras ligadas. Este é um exemplo fictício, não um relato de um usuário real ou o resultado de um teste. Ele nos fornece uma maneira prática de separar as causas prováveis: decodificação de vários fluxos de vídeo recebidos, codificação da câmera de Morgan, efeitos de vídeo ou um problema com o navegador e os gráficos.
Comece identificando qual parte da chamada é a mais custosa. Em seguida, altere uma configuração por vez e compare os resultados em condições de reunião semelhantes. Um cliente Jitsi Meet pode usar uma quantidade significativa de CPU mesmo quando o servidor Jitsi está funcionando corretamente; este guia se concentra no navegador e no dispositivo, não na capacidade do Videobridge no servidor.
As ilustrações de tela abaixo mostram exemplos de controles e verificações. A aparência e a disponibilidade exatas dos controles podem variar de acordo com a implantação do Jitsi, o navegador e a versão.
Enquanto o problema estiver ocorrendo, abra o Gerenciador de Tarefas, o Monitor de Atividade ou o monitor do sistema operacional. Procure o processo do navegador e, se a ferramenta dividir a atividade do navegador em guias ou tarefas, a guia do Jitsi Meet. Observe se o uso da CPU é constante ou se aumenta apenas brevemente quando alguém entra na reunião ou troca de vídeo. Verifique também se outro aplicativo — como um gravador de tela, um jogo ou um editor de vídeo — está usando mais recursos do processador.
Para Morgan, essa primeira verificação responde a uma pergunta útil: o navegador está consumindo a maior parte da carga ou o ventilador está respondendo a um aplicativo diferente? Registre o tamanho da reunião, se a câmera local está ligada e se os efeitos estão ativos. Esses detalhes tornam as comparações posteriores significativas.
Compare o mesmo dispositivo em uma chamada individual e em uma chamada maior, se possível. Na reunião maior, observe se o uso da CPU aumenta à medida que mais câmeras ficam visíveis ou quando você muda para um layout com muitos mosaicos. Renderizar e decodificar vários fluxos de vídeo em movimento pode sobrecarregar o cliente mais do que um único vídeo remoto. Isso é um indício, não uma prova definitiva: o tamanho da chamada, a resolução do vídeo, os drivers do dispositivo e outros aplicativos também influenciam a carga.
Se o uso da CPU permanecer alto mesmo em uma chamada individual com efeitos de vídeo desativados, concentre-se na câmera local, no navegador e no processamento gráfico. Se o aumento ocorrer principalmente com muitas imagens recebidas, priorize os controles de qualidade de recebimento e o layout ou a política do host.
Abra o menu Mais ações da reunião e procure por Gerenciar qualidade de vídeo . Se a sua configuração exibir um controle deslizante de qualidade, escolha uma configuração mais baixa e observe se os mosaicos recebidos ficam menos detalhados e o navegador fica mais responsivo. Esse controle se refere ao vídeo que você recebe; ele não necessariamente diminui a resolução da sua própria transmissão de vídeo.
O guia de configuração atual do Jitsi descreve startLastNo controle da quantidade de vídeos dos participantes recebidos e afirma que o controle deslizante de qualidade é usado quando channelLastNconfigurado. Portanto, não presuma que todas as salas do Jitsi tenham esse controle ou que ele se comporte da mesma maneira em todos os lugares. Se ele estiver ausente, continue com as outras etapas ou pergunte ao administrador da reunião se a implantação oferece suporte ao gerenciamento da qualidade de recebimento.
Desligue brevemente a sua câmera, mantendo o restante da chamada o mais semelhante possível. Se isso fizer uma diferença significativa, a carga pode estar relacionada à captura ou codificação da câmera no seu dispositivo. Isso não elimina o trabalho de decodificação dos vídeos dos outros participantes, portanto, uma galeria movimentada ainda pode exigir bastante processamento.
Se o vídeo não for essencial, deixe a câmera desligada. Se precisar enviar vídeo, melhore a iluminação e enquadre a câmera de forma estável para que a imagem permaneça útil mesmo em uma resolução mais baixa; evite alterar vários controles de qualidade simultaneamente, pois isso dificulta a interpretação do resultado.
Se o desfoque ou um fundo virtual estiverem ativos, desative-os para uma breve comparação. Os efeitos adicionam processamento ao caminho de vídeo local e podem não ser adequados para dispositivos mais antigos. A referência de configuração do Jitsi inclui uma opção para desativar fundos virtuais para uma implementação, mas a possibilidade de um participante ativar ou desativar esse recurso depende da configuração do site.
Morgan deve testar isso após a comparação das câmeras: primeiro com a câmera desligada e depois com a câmera ligada e os efeitos desativados. Se a segunda configuração for mais leve para o laptop do que a configuração original, o efeito é um candidato viável para ser deixado desativado. Não conclua que o efeito é a causa se a diferença não for repetível.
Feche abas e aplicativos que consomem muitos recursos e verifique se você está usando um navegador compatível com a sua instalação do Jitsi. A página de suporte a navegadores do Jitsi lista os navegadores de desktop compatíveis, mas o suporte pode mudar; confirme a lista atual para a versão que você usa. Se o problema persistir, faça um teste temporário sem extensões do navegador em um perfil limpo, onde a política da sua organização permitir.
A aceleração por hardware é uma variável de diagnóstico, não uma solução universal. No Chrome, as instruções de suporte do Google descrevem desativar a aceleração gráfica e reiniciar o navegador como uma etapa de solução de problemas. Se você suspeitar de um problema na GPU ou no driver, anote a configuração original, altere-a, reinicie o navegador e compare o desempenho. A renderização por software pode transferir o trabalho de volta para a CPU, portanto, restaure a configuração se o desempenho piorar. Atualize o navegador e o driver gráfico seguindo o processo de atualização oficial; evite instalar drivers de fontes não confiáveis.
Os administradores de uma implementação Jitsi autohospedada podem revisar a configuração de vídeo após testar as opções do lado do participante. Os documentos de referência de configuração resolutiondefinem a altura de vídeo local preferencial e documentam a captura constraintsseparadamente. Por exemplo, um administrador pode testar uma meta de captura mais baixa, como esta, no objeto de configuração válido:
resolution: 360,
constraints: {
video: {
height: { ideal: 360, max: 360, min: 240 }
}
},Este é um exemplo, não uma solução universal pronta para uso: confirme a sintaxe e as opções suportadas com a versão e configuração do Jitsi utilizadas em sua implementação. Um limite de captura menor sacrifica detalhes da imagem em troca de menos dados de vídeo para processar e enviar. Teste a qualidade da imagem, o comportamento da câmera e o uso da CPU do cliente em dispositivos representativos antes de aplicar a alteração de forma abrangente. A documentação observa que as restrições de captura são independentes da resolutionconfiguração.
Para administradores cujos usuários relatam alto uso de CPU, principalmente em visualizações em mosaico grandes, consulte maxFullResolutionParticipantsa documentação do Jitsi sobre essa opção, que define o número de participantes exibidos em resolução total antes que o vídeo recebido seja reduzido de HD para SD na visualização em mosaico. Uma configuração como essa maxFullResolutionParticipants: 4é apenas um exemplo e não uma recomendação para todas as organizações.
Essa configuração afeta a qualidade de vídeo para os participantes e deve ser avaliada como uma política para todo o site. Consulte a documentação de configuração atual para obter a semântica exata em sua versão, implemente a alteração e peça aos usuários que comparem o mesmo tamanho e layout de sala. Não confunda essa configuração com um aumento na capacidade do servidor; ela altera o que os clientes recebem.
Repita a comparação em condições semelhantes: mesmo dispositivo, navegador, tamanho da reunião, layout e estado da câmera. Verifique se o uso da CPU do navegador se estabiliza, se o áudio permanece nítido, se o vídeo remoto é utilizável e se o seu próprio vídeo ainda atende às necessidades da reunião. Altere uma configuração por vez e anote o resultado. Se o uso da CPU permanecer alto com a câmera desligada, os efeitos desativados e apenas alguns vídeos remotos, tente um perfil de navegador compatível e verifique os limites gráficos ou térmicos do sistema; esse padrão indica que o problema não está na opção de vídeo do Jitsi e pode exigir diagnósticos do dispositivo ou do navegador.
Para problemas no lado do cliente, as soluções menos disruptivas geralmente envolvem reduzir a qualidade do vídeo recebido (quando disponível), remover o processamento de vídeo local desnecessário e encerrar cargas de trabalho concorrentes. Alterações na configuração do servidor podem ajudar quando o padrão afeta muitos participantes, mas também alteram a experiência de todos. Consulte o guia do usuário oficial do Jitsi para obter informações sobre controles avançados de reuniões , a referência de configuração do Jitsi e a lista de navegadores compatíveis . Para solucionar problemas de aceleração no Chrome, siga as orientações oficiais do Google Chrome sobre aceleração gráfica . Estas páginas foram verificadas em 6 de outubro de 2026; o manual do Jitsi é atualizado periodicamente, portanto, verifique as opções em relação à sua versão instalada.
Diagnostique picos de uso da CPU no navegador do Jitsi Meet e reduza a carga do cliente verificando os mosaicos de vídeo, os efeitos da câmera, os gráficos do navegador e as configurações do host.
Monitore a integridade, a carga da conferência e o tráfego do Jitsi Videobridge com seu endpoint Prometheus integrado e, em seguida, explore e visualize os dados em gráficos no Grafana.
Configure um domínio personalizado para o Jitsi Meet Docker com DNS, URL pública, HTTPS, Let's Encrypt, portas de firewall, configurações de NAT e verificação de ponta a ponta.
Corrija os erros 404 do Console de Administração do Zimbra após a renovação do SSL, verificando o URL e a porta corretos, o roteamento do proxy, o status do serviço, os certificados implantados e os logs.
Aprenda a diagnosticar e corrigir o aviso de configuração do PHP OPcache do Nextcloud, verificando o PHP SAPI ativo, os limites de tamanho, os comentários e as configurações de revalidação.
Solucione problemas de falhas na migração do banco de dados Kopano após uma atualização do MySQL ou MariaDB, verificando backups, versões do servidor, modos SQL, conjunto de caracteres, estado do esquema e logs.
Conecte o Nextcloud ao LDAP ou Active Directory com transporte seguro, filtros de usuários e grupos, atributos de login e uma implementação testada.
Corrija as notificações do Element no Android em telefones sem serviços do Google configurando o UnifiedPush, as permissões do Android, as configurações de bateria e realizando testes de verificação confiáveis.
Remova o aviso de índices de banco de dados ausentes do Nextcloud com o comando oficial occ. Primeiro, faça um backup, visualize as alterações, execute o reparo e verifique o resultado.
Configure o SSO do Keycloak para o Element Web conectando o OIDC ao Synapse, definindo a URL de retorno de chamada exata, mapeando as declarações do usuário e testando o logout.
