Scenario illustrativo: Morgan utilizza un vecchio laptop per una videochiamata su Jitsi Meet. La ventola diventa rumorosa e l'utilizzo della CPU da parte del browser rimane elevato quando diverse persone hanno la videocamera accesa. Questo è un esempio fittizio, non una segnalazione di un utente reale o un risultato di un test. Ci fornisce un modo pratico per distinguere le cause più probabili: decodifica di più flussi video in ingresso, codifica della videocamera di Morgan, effetti video o un problema del browser e della scheda grafica.
Inizia identificando quale parte della chiamata incide maggiormente sul consumo di CPU. Quindi modifica un'impostazione alla volta e confronta i risultati in condizioni di riunione simili. Un client Jitsi Meet può utilizzare una quantità significativa di CPU anche quando il server Jitsi funziona correttamente; questa guida si concentra sul browser e sul dispositivo, non sulla capacità del server Videobridge.
Le schermate illustrate di seguito mostrano alcuni esempi di controlli e caselle di spunta. L'aspetto e la disponibilità dei controlli possono variare a seconda dell'installazione di Jitsi, del browser e della versione.
Mentre il problema si verifica, apri Gestione attività, Monitoraggio attività o Monitor di sistema del tuo sistema operativo. Cerca il processo del browser e, se lo strumento suddivide l'attività del browser in schede o attività, la scheda Jitsi Meet. Verifica se l'utilizzo della CPU è costante o se presenta solo brevi picchi quando qualcuno si unisce alla riunione o cambia video. Controlla anche se un'altra applicazione, come un programma di registrazione dello schermo, un gioco o un editor video, sta utilizzando una maggiore quantità di processore.
Per Morgan, questo primo controllo risponde a una domanda utile: è il browser a gestire la maggior parte del carico o la ventola sta rispondendo a un'applicazione diversa? Annota il numero di partecipanti alla riunione, se la webcam locale è attiva e se gli effetti sono in esecuzione. Questi dettagli renderanno significativi i confronti successivi.
Se possibile, confronta lo stesso dispositivo in una chiamata uno a uno e in una chiamata con più partecipanti. Nella riunione con più partecipanti, osserva se l'utilizzo della CPU aumenta con l'aumentare del numero di telecamere visibili o quando passi a un layout con molte finestre a riquadri. Il rendering e la decodifica di più flussi video in movimento possono sovraccaricare il client rispetto a un singolo video remoto. Questo è un indizio diagnostico, non una prova definitiva: anche le dimensioni della chiamata, la risoluzione video, i driver del dispositivo e altre applicazioni influiscono sul carico.
Se l'utilizzo della CPU rimane elevato anche durante una chiamata uno a uno con effetti video disattivati, concentrati sulla fotocamera locale, sul browser e sul percorso grafico. Se l'aumento si verifica principalmente con un elevato numero di riquadri in entrata, dai priorità ai controlli di qualità della ricezione e al layout o ai criteri dell'host.
Apri il menu "Altre azioni" della riunione e cerca "Gestisci qualità video" . Se la tua implementazione prevede un cursore per la qualità, scegli un'impostazione inferiore e verifica se i riquadri in ingresso diventano meno dettagliati e il browser più reattivo. Questa impostazione riguarda il video che ricevi; non riduce necessariamente la risoluzione del flusso video della tua videocamera.
La guida di configurazione attuale di Jitsi descrive startLastNcome controllo il numero di video dei partecipanti ricevuti e afferma che il cursore della qualità viene utilizzato quando channelLastNè configurato. Pertanto, non dare per scontato che ogni sala Jitsi disponga di questo controllo o che si comporti in modo identico ovunque. Se non è presente, procedere con gli altri passaggi o chiedere all'amministratore della riunione se l'implementazione supporta la gestione della qualità di ricezione.
Disattiva brevemente la tua videocamera, mantenendo il resto della chiamata il più possibile invariato. Se noti una differenza evidente, il carico potrebbe essere dovuto all'acquisizione o alla codifica video sul tuo dispositivo. Ciò non elimina il lavoro di decodifica dei video degli altri partecipanti, quindi una galleria video affollata potrebbe comunque risultare impegnativa.
Se il video non è essenziale, tenete la telecamera spenta. Se invece dovete inviare un video, migliorate l'illuminazione e inquadrate la telecamera in modo stabile, così che l'immagine rimanga utilizzabile anche a una risoluzione inferiore; evitate di modificare contemporaneamente diversi parametri di qualità, perché ciò rende il risultato più difficile da interpretare.
Se la sfocatura o uno sfondo virtuale sono attivi, disattivali per un breve confronto. Gli effetti aggiungono elaborazione al flusso video locale e potrebbero non essere adatti a dispositivi meno recenti. La documentazione di configurazione di Jitsi include un'opzione per disabilitare gli sfondi virtuali per una distribuzione, ma la possibilità per un partecipante di attivare o disattivare questa funzione dipende dalla configurazione del sito.
Morgan dovrebbe testare questa soluzione dopo il confronto tra le fotocamere: prima la fotocamera spenta, poi la fotocamera accesa con gli effetti disattivati. Se la seconda configurazione risulta meno impegnativa per il portatile rispetto a quella originale, l'effetto è un valido candidato per essere lasciato disattivato. Non dedurre che l'effetto sia la causa se la differenza non è riproducibile.
Chiudi le schede e le applicazioni che consumano molte risorse e non sono correlate al problema, quindi assicurati di utilizzare un browser aggiornato e supportato dalla tua installazione di Jitsi. La pagina di supporto browser di Jitsi elenca i browser desktop supportati, ma il supporto può cambiare; verifica l'elenco aggiornato per la versione che utilizzi. Se il problema persiste, prova temporaneamente a utilizzare un profilo pulito senza estensioni del browser, laddove le policy della tua organizzazione lo consentano.
L'accelerazione hardware è una variabile diagnostica, non una soluzione universale. In Chrome, le istruzioni di supporto di Google descrivono la disattivazione dell'accelerazione grafica e il riavvio come una procedura di risoluzione dei problemi. Se sospetti un problema con la GPU o i driver, annota l'impostazione originale, modificala, riavvia il browser e confrontala durante la stessa riunione. Il rendering software può trasferire parte del lavoro alla CPU, quindi ripristina l'impostazione se le prestazioni peggiorano. Aggiorna il browser e i driver grafici tramite la normale procedura di aggiornamento supportata; evita di installare driver da fonti non attendibili.
Gli amministratori di un'implementazione Jitsi self-hosted possono rivedere la configurazione video dopo aver testato le opzioni lato partecipante. I documenti di riferimento della configurazione resolutionspecificano l'altezza video locale preferita e documentano constraintsseparatamente l'acquisizione. Ad esempio, un amministratore potrebbe testare un target di acquisizione inferiore come questo nell'oggetto di configurazione valido:
resolution: 360,
constraints: {
video: {
height: { ideal: 360, max: 360, min: 240 }
}
},Questo è un esempio, non una patch universale da applicare immediatamente: verifica la sintassi e le opzioni supportate in base alla versione e alla configurazione di Jitsi utilizzate nella tua implementazione. Un target di acquisizione inferiore sacrifica il dettaglio dell'immagine a favore di una minore quantità di dati video da elaborare e inviare. Testa la qualità dell'immagine, il comportamento della telecamera e l'utilizzo della CPU da parte del client su dispositivi rappresentativi prima di applicare la modifica su larga scala. La documentazione di riferimento specifica che i vincoli di acquisizione sono indipendenti dall'impostazione resolution.
Per gli amministratori i cui utenti segnalano un elevato utilizzo della CPU principalmente nelle visualizzazioni a riquadri di grandi dimensioni, si consiglia di rivedere maxFullResolutionParticipants. Jitsi documenta questa opzione come il numero di partecipanti visualizzati a piena risoluzione prima che il video ricevuto venga ridotto da HD a SD nella visualizzazione a riquadri. Una configurazione come questa maxFullResolutionParticipants: 4è solo un valore di esempio, non un'impostazione consigliata per ogni organizzazione.
Questa impostazione influisce sulla qualità video per i partecipanti e dovrebbe essere valutata come policy per l'intero sito. Consultare la documentazione di configurazione corrente per la semantica esatta nella propria versione, implementare la modifica gradualmente e chiedere agli utenti di confrontare le prestazioni in stanze con dimensioni e layout simili. Non confondere questa impostazione con un aumento della capacità del server; essa modifica ciò che i client ricevono.
Ripeti il confronto in condizioni simili: stesso dispositivo, browser, numero di partecipanti alla riunione, layout e stato della videocamera. Verifica se l'utilizzo della CPU del browser si stabilizza, se l'audio rimane chiaro, se il video remoto è utilizzabile e se il tuo video soddisfa ancora le esigenze della riunione. Modifica un'impostazione alla volta e annota il risultato. Se l'utilizzo della CPU rimane elevato anche con la videocamera spenta, gli effetti disabilitati e solo pochi video remoti, prova un profilo browser supportato e controlla i limiti della scheda grafica o della temperatura del sistema; questo comportamento indica che il problema non è legato a una singola opzione video di Jitsi e potrebbe richiedere una diagnostica del dispositivo o del browser.
Per un problema lato client, le soluzioni meno invasive consistono solitamente nel ridurre la qualità del video in ingresso, quando possibile, rimuovere l'elaborazione video locale non necessaria e chiudere i carichi di lavoro concorrenti. Le modifiche alla configurazione self-hosted possono essere utili quando il problema interessa molti partecipanti, ma modificano anche l'esperienza per tutti. Consultare la guida utente ufficiale di Jitsi per i controlli avanzati delle riunioni , il riferimento alla configurazione di Jitsi e l' elenco dei browser supportati . Per la risoluzione dei problemi di accelerazione di Chrome, seguire le linee guida ufficiali di Google Chrome sull'accelerazione grafica . Queste pagine sono state verificate il 6 ottobre 2026; il manuale di Jitsi viene aggiornato periodicamente, quindi verificare le opzioni in base alla versione installata.
Diagnostica i picchi di utilizzo della CPU del browser Jitsi Meet e riduci il carico del client controllando i riquadri video, gli effetti della fotocamera, la grafica del browser e le impostazioni dell'host.
Monitora lo stato di salute, il carico della conferenza e il traffico di Jitsi Videobridge con il suo endpoint Prometheus integrato, quindi esplora e visualizza i dati in Grafana.
Configura un dominio personalizzato per Jitsi Meet Docker con DNS, URL pubblico, HTTPS, Let's Encrypt, porte del firewall, impostazioni NAT e verifica end-to-end.
Fix Zimbra Admin Console 404 errors after SSL renewal by checking the correct URL and port, proxy routing, service status, deployed certificates, and logs.
Scopri come diagnosticare e risolvere l'avviso di configurazione di PHP OPcache di Nextcloud controllando l'SAPI PHP attivo, i limiti di dimensionamento, i commenti e le impostazioni di riconvalida.
Risolvere i problemi di migrazione del database Kopano dopo un aggiornamento di MySQL o MariaDB verificando i backup, le versioni del server, le modalità SQL, il set di caratteri, lo stato dello schema e i log.
Collega Nextcloud a LDAP o Active Directory con trasporto sicuro, filtri per utenti e gruppi, attributi di accesso e un'implementazione collaudata.
Risolvi i problemi di notifiche di Element Android sui telefoni senza Google configurando UnifiedPush, le autorizzazioni Android, le impostazioni della batteria ed eseguendo test di verifica affidabili.
Risolvi l'avviso di Nextcloud relativo agli indici del database mancanti utilizzando il comando ufficiale occ. Prima di procedere, esegui un backup, visualizza in anteprima le modifiche, avvia la riparazione e verifica il risultato.
Configura l'SSO di Keycloak per Element Web collegando OIDC a Synapse, impostando l'URL di callback esatto, mappando le attestazioni utente e testando il logout.
