Como otimizar a resolução e a taxa de bits do Jitsi Meet para baixa largura de banda

O que você deve alterar primeiro em uma implantação do Jitsi Meet com baixa largura de banda?

Comece com três controles, nesta ordem: diminua a resolução de captura da câmera, reduza a quantidade de vídeos remotos que cada cliente recebe e só então restrinja os limites de taxa de bits específicos do codec. Essa sequência é importante porque a resolução e o número de fluxos recebidos geralmente têm o efeito mais visível no consumo de largura de banda, enquanto limites de taxa de bits agressivos podem deixar o movimento borrado sem resolver a perda de pacotes ou a instabilidade do Wi-Fi.

A Jitsi documenta os controles de vídeo do lado do cliente em sua referência de configuração atual . A partir de 6 de outubro de 2026, a documentação afirma que o constraintsobjeto tem como padrão uma altura de captura ideal de 720p, channelLastNé ilimitado por padrão -1e startLastNpode iniciar uma conferência com menos vídeos recebidos antes que o usuário altere a configuração "Gerenciar Qualidade de Vídeo".

Para um escritório remoto com recursos limitados, um ponto de acesso móvel, uma conexão rural ou uma rede Wi-Fi sobrecarregada, uma meta inicial prática costuma ser 360p em vez de 720p. A página de requisitos de infraestrutura do Jitsi fornece estimativas aproximadas de planejamento de cerca de 200 kbit/s para 180p, 500 kbit/s para 360p e 2,5 Mbit/s para 720p, alertando também que os requisitos reais variam de acordo com diversos fatores. Considere esses valores como referências para planejamento de capacidade, e não como taxas garantidas por usuário. Consulte o guia oficial de requisitos do Jitsi Meet .

Visão ilustrativa da reunião mostrando uma opção de qualidade 360p para uma conexão com recursos limitados; o layout exato dos controles pode variar de acordo com a versão do Jitsi Meet.

Você deve limitar a resolução antes da taxa de bits?

Geralmente, sim. Diminuir a altura de captura reduz o número de pixels que o codificador precisa processar antes mesmo de começar a alocação da taxa de bits. A referência de configuração atual do Jitsi separa o vídeo W3C constraintsdo resolutionvalor preferido anterior e observa que as restrições são definidas por padrão para uma altura de captura ideal de 720p.

Para um site onde a estabilidade do vídeo é mais importante do que detalhes faciais precisos, teste um limite de captura de 360p como este:

constraints: {
    video: {
        height: {
            ideal: 360,
            max: 360,
            min: 180
        }
    }
},

Este é um perfil de exemplo, não um padrão do Jitsi. Ele instrui o navegador a priorizar 360p e não exceder essa resolução, permitindo ainda que a taxa de captura seja reduzida para até 180p, se necessário. Evite presumir que isso min: 180garante um fluxo estável em 180p sob forte congestionamento; o WebRTC ainda pode se adaptar à largura de banda disponível, à carga da CPU, à perda de pacotes, às capacidades do dispositivo e ao comportamento do codec.

Exemplo de configuração Jitsi auto-hospedada com limite de captura de 360p e valores LastN conservadores.

Quantas transmissões de vídeo remotas cada participante deve receber?

Se um participante receber oito vídeos remotos simultaneamente, reduzir apenas a resolução da câmera local não resolve o problema de download em sua totalidade. O Jitsi oferece controles LastN específicos para definir quantas transmissões de vídeo remotas são encaminhadas para um participante.

O valor padrão documentado channelLastNé -1, o que significa ilimitado. A startLastNopção documentada permite que uma conferência comece com um valor LastN menor, e o Jitsi observa que ela channelLastNé usada quando o usuário altera o nível de qualidade com o controle deslizante Gerenciar Qualidade de Vídeo.

Um ponto de partida cauteloso para um ambiente com largura de banda limitada é:

channelLastN: 2,
startLastN: 1,

Neste exemplo, um participante começa recebendo um vídeo remoto e pode passar a receber até dois vídeos remotos, dependendo da qualidade do aplicativo. Não considere esses valores 2como 1recomendações universais. Uma sala de aula onde os alunos assistem principalmente a um apresentador pode usar um LastN menor do que uma reunião de revisão de design com quatro pessoas, onde todos precisam permanecer visíveis.

Quais são os valores de bitrate que o Jitsi usa atualmente?

O modelo atual e a referência de configuração do Jitsi config.jsexpõem níveis específicos de codec maxBitratesVideo. Na configuração principal do projeto visualizada em 6 de outubro de 2026, o AV1 usa 100.000 bits/s para baixa taxa de bits, 300.000 para taxa de bits padrão e 1.000.000 para alta taxa de bits; o VP9 usa 100.000, 300.000 e 1.200.000; o VP8 e o H.264 usam 200.000, 500.000 e 1.500.000 para esses mesmos níveis. Você pode verificar o modelo em produção no repositório oficial do Jitsi Meet no GitHub .

Esses valores são padrões ou valores de modelo do servidor, não uma garantia de que todas as chamadas serão transmitidas exatamente nessas taxas. A estimativa de largura de banda do WebRTC, o controle de congestionamento, o codec selecionado, o comportamento de transmissão simultânea ou codificação escalável, a complexidade da cena, a taxa de quadros e as restrições do receptor afetam o que é realmente enviado.

Quando faz sentido reduzir os limites máximos?

Reduza os limites quando o orçamento da sua rede for conhecido e a estabilidade do vídeo for mais importante do que os detalhes. Por exemplo, você pode testar um perfil VP8 como:

videoQuality: {
    vp8: {
        maxBitratesVideo: {
            low: 150000,
            standard: 300000,
            high: 800000
        }
    }
},

Esses números são deliberadamente rotulados como um exemplo para testes, não como valores padrão do Jitsi. Eles só fazem sentido se o VP8 for realmente negociado nos endpoints que você utiliza. Se seus clientes desktop preferem AV1 ou VP9, ​​ajustar apenas o objeto VP8 não produzirá o efeito esperado.

Exemplos de limites de taxa de bits VP8 para uma rede com recursos limitados; teste-os em seus próprios dispositivos e padrões de chamadas antes da implementação.

Você deve forçar um codec específico para economizar largura de banda?

Não automaticamente. As versões modernas do Jitsi expõem a ordem de preferência de codecs e diferentes níveis de bitrate padrão para AV1, VP9, ​​VP8 e H.264. AV1 e VP9 podem ser eficientes, mas a escolha do codec também afeta o custo da CPU, a compatibilidade com dispositivos e navegadores, e os recursos de escalabilidade. Um laptop com recursos limitados que tenha dificuldades para codificar um codec mais complexo pode resultar em uma reunião de pior qualidade, mesmo que o codec seja eficiente em teoria.

Uma regra operacional mais segura é manter o comportamento atual de preferência de codecs do Jitsi, a menos que você tenha medições que mostrem algum problema. Se você alterar a ordem dos codecs, teste nas combinações reais de Chrome, Firefox, Safari, Android e iOS usadas pela sua organização. Não tire conclusões sobre o desempenho de codecs com base em um único navegador de desktop.

E quanto ao compartilhamento de tela em uma conexão lenta?

O compartilhamento de tela apresenta uma relação de compromisso com a qualidade diferente da gravação de vídeo por câmera. Textos e slides se beneficiam de uma resolução legível, enquanto movimentos fluidos exigem mais quadros por segundo. O Jitsi documenta desktopSharingFrameRatee atualmente lista um valor padrão de { min: 5, max: 5 }5 fps. Para uma reunião com muitas apresentações, manter o compartilhamento de tela em torno de 5 fps pode preservar a legibilidade sem desperdiçar largura de banda com movimentos desnecessários.

Se os usuários compartilharem animações, rotações CAD ou videoclipes, 5 fps podem parecer muito lentos. Nesse caso, aumente a taxa de quadros com cuidado e observe se a resolução ou a perda de pacotes pioram. A documentação oficial de configuração do Jitsi é a referência correta para os nomes das opções atualmente suportadas.

Como saber se as mudanças realmente ajudaram?

Não julgue apenas pela aparência da imagem. Valide o comportamento da rede. A API IFrame do Jitsi expõe getConnectionStats()informações que podem retornar a qualidade da conexão local, a largura de banda disponível, a taxa de bits de upload e download, a taxa de bits de áudio e vídeo, a perda de pacotes, informações do codec, a taxa de quadros, os quadros decodificados, a resolução e detalhes de transporte. Consulte a referência oficial das funções da API IFrame .

Para implantações incorporadas, uma verificação simples pode ser feita da seguinte forma:

api.getConnectionStats().then(stats => {
    console.log(stats.bitrate);
    console.log(stats.packetLoss);
    console.log(stats.resolution);
    console.log(stats.connectionQuality);
});

Execute o mesmo padrão de reunião antes e depois das alterações. Um teste útil tem pelo menos três condições: largura de banda normal de escritório, largura de banda deliberadamente limitada e uma chamada realista com vários participantes. Registre se o áudio permanece inteligível, se o vídeo congela, se a perda de pacotes aumenta, se os participantes reduzem a resolução ou se o uso da CPU se torna excessivo.

Visualização ilustrativa das estatísticas de conexão, mostrando o tipo de resolução, taxa de quadros, taxa de bits e valores de perda a serem comparados durante a validação.

Com qual perfil de baixa largura de banda você deve começar?

Esses são perfis iniciais, não valores ideais garantidos. A configuração correta depende da assimetria de uplink e downlink, do número de participantes, do conteúdo da câmera, do codec escolhido, da CPU do dispositivo final e da qualidade esperada pelos usuários.

Onde devo editar a configuração em um servidor auto-hospedado?

Em uma instalação de pacote Debian, o Jitsi geralmente mantém a configuração web do host virtual em `/etc/jitsi.conf` /etc/jitsi/meet/<your-hostname>-config.js. A própria documentação de autenticação do Jitsi usa esse caminho em seus exemplos. Em implantações Docker, o guia oficial do Docker afirma que config.jsos arquivos gerados dentro do contêiner são recriados na inicialização, portanto, as configurações personalizadas devem ser colocadas no arquivo do host CONFIG/web/custom-config.js. Consulte o guia oficial de auto-hospedagem do Docker .

Antes de editar, copie a configuração existente, altere um grupo de parâmetros por vez e valide a sintaxe do JavaScript. Evite colar um exemplo inteiro config.jssobre uma implantação em funcionamento, pois os modelos originais evoluem e podem incluir valores específicos da implantação.

Qual é a ordem de afinação mais segura?

1. Primeiro, faça as medições. Reproduza o problema de baixa largura de banda com um número realista de participantes e anote a perda de pacotes, a taxa de bits, a resolução e a carga da CPU.
2. Limite a captura da câmera a 360p. Use constraints.video.heighte teste para verificar se a estabilidade do vídeo melhora.
3. Reduza o número de fluxos recebidos. Diminua o volume startLastNe, se necessário, channelLastNajuste para que cada participante não baixe miniaturas desnecessárias.
4. Mantenha a legibilidade do compartilhamento de tela. Mantenha a taxa de quadros do compartilhamento de tela baixa para slides e documentos, a menos que o caso de uso exija movimento.
5. Ajuste os limites de taxa de bits dos codecs por último. Altere apenas os perfis de codec efetivamente negociados pelos seus clientes e compare a qualidade antes e depois da alteração.
6. Teste novamente em condições de congestionamento. Uma configuração que parece boa em uma rede local (LAN) pode falhar em uma rede Wi-Fi de hotel ou em um ponto de acesso móvel.

O que você deve evitar?

Não desative os recursos de transmissão simultânea ou retransmissão apenas para reduzir a largura de banda; esses controles afetam a forma como o Jitsi se adapta e se recupera de perdas, e alterá-los pode criar novos modos de falha. Não force 180p para todos os usuários, a menos que o caso de uso realmente o tolere. Não trate um limite de taxa de bits como uma reserva dessa largura de banda. E não otimize apenas o link do servidor, ignorando a conexão do último quilômetro em cada ponto de extremidade.

A melhor configuração do Jitsi com baixa largura de banda não é, portanto, aquela com os menores números. É aquela que mantém o áudio confiável, garante que o orador ativo permaneça legível, limita o vídeo de entrada desnecessário e ainda oferece ao codificador espaço suficiente para adaptação. Comece com 360p, valores conservadores de LastN e as configurações padrão de codec do Jitsi; em seguida, reduza os limites de bitrate somente quando suas medições mostrarem que isso melhora a reunião em vez de simplesmente diminuir a qualidade da imagem.