Come ottimizzare la risoluzione e il bitrate di Jitsi Meet per connessioni a bassa larghezza di banda

Cosa dovresti modificare per prima cosa in un'installazione di Jitsi Meet con larghezza di banda ridotta?

Iniziate con tre controlli, in quest'ordine: riducete la risoluzione di acquisizione della telecamera, diminuite il numero di video remoti che ogni client riceve e solo successivamente inasprite i limiti di bitrate specifici per ciascun codec. Questa sequenza è importante perché la risoluzione e il numero di flussi ricevuti hanno solitamente l'effetto più evidente sul consumo di banda, mentre limiti di bitrate troppo stringenti possono rendere le immagini sfocate senza risolvere i problemi di perdita di pacchetti o instabilità del Wi-Fi.

Jitsi documenta i controlli video lato client nel suo riferimento di configurazione corrente . Al 6 ottobre 2026, la documentazione afferma che l' constraintsoggetto utilizza per impostazione predefinita un'altezza di acquisizione ideale di 720p, channelLastNè illimitato per impostazione predefinita -1e startLastNpuò avviare una conferenza con un numero inferiore di video ricevuti prima che l'utente modifichi l'impostazione Gestisci qualità video.

Per una filiale con risorse limitate, un hotspot mobile, un collegamento rurale o una rete Wi-Fi sovraccarica, un obiettivo di partenza pratico è spesso 360p anziché 720p. La pagina dei requisiti infrastrutturali di Jitsi fornisce cifre di pianificazione approssimative di circa 200 kbit/s per 180p, 500 kbit/s per 360p e 2,5 Mbit/s per 720p, avvertendo tuttavia che i requisiti reali variano in base a molti fattori. Considerate questi valori come riferimenti per la pianificazione della capacità, non come velocità garantite per utente. Consultate la guida ufficiale ai requisiti di Jitsi Meet .

Visualizzazione a scopo illustrativo della riunione, che mostra la scelta di una qualità a 360p per una connessione limitata; la disposizione esatta dei controlli può variare a seconda della versione di Jitsi Meet.

È meglio limitare la risoluzione prima del bitrate?

Solitamente sì. Abbassare l'altezza di acquisizione riduce il numero di pixel che il codificatore deve elaborare prima ancora che inizi l'allocazione del bitrate. La configurazione di riferimento attuale di Jitsi separa il video W3C constraintsdal resolutionvalore preferito precedente e osserva che i vincoli predefiniti si basano su un'altezza di acquisizione ideale di 720p.

Per un sito in cui la stabilità video è più importante dei dettagli facciali, provate una telecamera a soffitto per riprese a 360p come questa:

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

Questo è un profilo di esempio, non un'impostazione predefinita di Jitsi. Richiede al browser di preferire 360p e di non superarlo, consentendo comunque al flusso di acquisizione di scendere fino a 180p se necessario. Evitate di dare per scontato che ciò min: 180garantisca uno streaming stabile a 180p in caso di forte congestione; WebRTC può comunque adattarsi alla larghezza di banda disponibile, al carico della CPU, alla perdita di pacchetti, alle capacità del dispositivo e al comportamento del codec.

Esempio di configurazione Jitsi self-hosted con un limite di acquisizione di 360p e valori LastN conservativi.

Quanti flussi video remoti dovrebbe ricevere ciascun partecipante?

Se un partecipante riceve otto video remoti contemporaneamente, ridurre solo la risoluzione della telecamera locale non risolve completamente il problema del download. Jitsi offre controlli LastN specifici per quanti flussi video remoti vengono inoltrati a un partecipante.

Il valore predefinito documentato channelLastNè -1, ovvero illimitato. L' startLastNopzione documentata consente a una conferenza di iniziare con un valore LastN inferiore, e Jitsi nota che channelLastNviene utilizzata quando l'utente modifica il livello di qualità con il cursore Gestisci qualità video.

Un punto di partenza prudente per un ambiente con larghezza di banda limitata è:

channelLastN: 2,
startLastN: 1,

Con questo esempio, un partecipante inizia ricevendo un video remoto e può passare a uno stato in cui riceve fino a due video remoti, a seconda del comportamento qualitativo dell'applicazione. Non considerare 2e 1come raccomandazioni universali. In un'aula in cui gli studenti guardano principalmente un relatore, si può utilizzare un LastN inferiore rispetto a una revisione di progettazione con quattro persone in cui tutti devono rimanere visibili.

Quali valori di bitrate utilizza attualmente Jitsi?

Il modello e la configurazione di riferimento di Jitsi attualmente disponibili config.jsmostrano i livelli specifici per ciascun codec maxBitratesVideo. Nella configurazione master del progetto visualizzata il 6 ottobre 2026, AV1 utilizza 100.000 bit/s per il livello basso, 300.000 per il livello standard e 1.000.000 per il livello alto; VP9 utilizza 100.000, 300.000 e 1.200.000; VP8 e H.264 utilizzano 200.000, 500.000 e 1.500.000 per gli stessi livelli. È possibile verificare il modello live nel repository GitHub ufficiale di Jitsi Meet .

Questi valori sono valori predefiniti o modelli a monte, non una garanzia che ogni chiamata verrà trasmessa esattamente a quelle velocità. La stima della larghezza di banda WebRTC, il controllo della congestione, il codec selezionato, il comportamento di simulcast o di codifica scalabile, la complessità della scena, la frequenza dei fotogrammi e i vincoli del ricevitore influiscono tutti su ciò che viene effettivamente inviato.

Quando ha senso abbassare i limiti massimi?

Riduci i limiti quando il budget di rete è noto e la stabilità del video è più importante della qualità dei dettagli. Ad esempio, potresti testare un profilo VP8 come:

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

Questi valori sono indicati appositamente come esempio a scopo di test, non come impostazioni predefinite di Jitsi. Hanno senso solo se VP8 viene effettivamente negoziato sugli endpoint di vostro interesse. Se i vostri client desktop preferiscono AV1 o VP9, ​​la sola modifica dell'oggetto VP8 non produrrà l'effetto desiderato.

Esempio di limiti di bitrate VP8 per una rete con risorse limitate; testateli sui vostri dispositivi e sui vostri modelli di chiamata prima dell'implementazione.

È opportuno forzare l'utilizzo di un codec specifico per risparmiare larghezza di banda?

Non automaticamente. Le versioni moderne di Jitsi mostrano l'ordine di preferenza dei codec e diverse scale di bitrate predefinite per AV1, VP9, ​​VP8 e H.264. AV1 e VP9 possono essere efficienti, ma la scelta del codec influisce anche sul consumo di CPU, sul supporto dei dispositivi, sul supporto dei browser e sulle funzionalità di scalabilità. Un laptop con prestazioni limitate che fatica a codificare un codec più complesso potrebbe produrre una riunione di qualità inferiore, anche se il codec è efficiente sulla carta.

Una regola operativa più sicura è quella di mantenere l'attuale comportamento di preferenza dei codec di Jitsi, a meno che non si disponga di misurazioni che mostrino un problema. Se si modifica l'ordine dei codec, eseguire dei test sulle combinazioni effettive di Chrome, Firefox, Safari, Android e iOS utilizzate dalla propria organizzazione. Non dedurre le prestazioni dei codec da un singolo browser desktop.

E per quanto riguarda la condivisione dello schermo con una connessione lenta?

La condivisione dello schermo presenta un compromesso di qualità diverso rispetto al video della videocamera. Testo e diapositive beneficiano di una risoluzione leggibile, mentre un movimento fluido richiede un numero maggiore di fotogrammi al secondo. Jitsi documenta desktopSharingFrameRatee attualmente indica un valore predefinito di { min: 5, max: 5 }. Per una riunione con molte presentazioni, mantenere la condivisione dello schermo intorno ai 5 fps può preservare la leggibilità senza sprecare larghezza di banda con movimenti non necessari.

Se gli utenti condividono animazioni, rotazioni CAD o clip video, 5 fps potrebbero risultare troppo lenti. In tal caso, aumentare con cautela la frequenza dei fotogrammi e verificare se si verifica un degrado della risoluzione o una perdita di pacchetti. La documentazione ufficiale di configurazione di Jitsi è il riferimento corretto per i nomi delle opzioni attualmente supportate.

Come si fa a sapere se i cambiamenti apportati hanno effettivamente dato i loro frutti?

Non giudicare solo in base all'aspetto visivo dell'immagine. Verifica il comportamento della rete. L'API IFrame di Jitsi espone getConnectionStats()informazioni che possono restituire la qualità della connessione locale, la larghezza di banda disponibile, il bitrate di upload e download, il bitrate audio e video, la perdita di pacchetti, le informazioni sul codec, la frequenza dei fotogrammi, i fotogrammi decodificati, la risoluzione e i dettagli di trasporto. Consulta la documentazione ufficiale delle funzioni dell'API IFrame .

Per le implementazioni integrate, un semplice controllo può essere simile a questo:

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

Eseguite lo stesso schema di riunione prima e dopo le modifiche. Un test utile prevede almeno tre condizioni: larghezza di banda standard dell'ufficio, larghezza di banda volutamente limitata e una chiamata realistica con più partecipanti. Registrate se l'audio rimane intelligibile, se il video si blocca, se la perdita di pacchetti aumenta, se i partecipanti passano a una risoluzione inferiore o se l'utilizzo della CPU diventa eccessivo.

Visualizzazione esemplificativa delle statistiche di connessione che mostra i tipi di risoluzione, frequenza dei fotogrammi, bitrate e valori di perdita da confrontare durante la convalida.

Con quale profilo a bassa larghezza di banda dovresti iniziare?

Questi sono profili di partenza, non valori ottimali garantiti. La configurazione corretta dipende dall'asimmetria tra uplink e downlink, dal numero di partecipanti, dal contenuto della telecamera, dal codec scelto, dalla CPU del dispositivo finale e dalla qualità attesa dagli utenti.

Dove si dovrebbe modificare la configurazione su un server self-hosted?

In un'installazione Debian-package, Jitsi solitamente mantiene la configurazione web dell'host virtuale in /etc/jitsi/meet/<your-hostname>-config.js. La documentazione di autenticazione di Jitsi utilizza questo percorso nei suoi esempi. Nelle implementazioni Docker, la guida ufficiale di Docker afferma che config.jsi file generati all'interno del container vengono ricreati all'avvio, quindi le impostazioni personalizzate dovrebbero essere inserite nel CONFIG/web/custom-config.jsfile lato host. Consultare la guida ufficiale all'hosting self-service di Docker .

Prima di apportare modifiche, copiate la configurazione esistente, modificate un gruppo di parametri alla volta e verificate la sintassi JavaScript. Evitate di incollare un intero esempio config.jssu un'implementazione funzionante, poiché i modelli originali si evolvono e potrebbero includere valori specifici dell'implementazione.

Qual è l'ordine di accordatura più sicuro?

1. Misura prima. Riproduci il problema della bassa larghezza di banda con un numero realistico di partecipanti e annota la perdita di pacchetti, il bitrate, la risoluzione e il carico della CPU.
2. Limita la registrazione video a 360p. Utilizza questa impostazione constraints.video.heighte verifica se la stabilità del video migliora.
3. Riduci i flussi ricevuti. Abbassa startLastNe, se necessario, channelLastNin modo che ogni partecipante non scarichi miniature non necessarie.
4. Preservare la leggibilità della condivisione schermo. Mantenere bassa la frequenza dei fotogrammi per diapositive e documenti durante la condivisione dello schermo, a meno che il caso d'uso non richieda del movimento.
5. Regolate per ultimi i limiti del bitrate dei codec. Modificate solo i profili codec effettivamente negoziati dai vostri client e confrontate la qualità prima e dopo.
6. Eseguire nuovamente il test in condizioni di congestione. Una configurazione che funziona correttamente su una rete LAN potrebbe non funzionare su una rete Wi-Fi di un hotel o su un hotspot mobile.

Cosa bisogna evitare?

Non disabilitare le funzionalità di simulcast o ritrasmissione solo per ridurre la larghezza di banda; questi controlli influenzano il modo in cui Jitsi si adatta e si riprende dalle perdite, e modificarli può creare nuove modalità di errore. Non imporre la risoluzione 180p a ogni utente a meno che il caso d'uso non lo richieda effettivamente. Non considerare un limite di bitrate come una prenotazione di quella larghezza di banda. E non ottimizzare solo il collegamento al server ignorando la connessione dell'ultimo miglio a ciascun endpoint.

La migliore configurazione Jitsi a bassa larghezza di banda non è quindi quella con i valori più bassi. È quella che mantiene un audio affidabile, consente di leggere chiaramente l'oratore attivo, limita il flusso video in ingresso non necessario e offre al codificatore un margine di adattamento sufficiente. Iniziate con 360p, valori LastN conservativi e le impostazioni predefinite del codec di Jitsi; poi, restringete i limiti del bitrate solo quando le vostre misurazioni dimostrano che ciò migliora la riunione anziché semplicemente peggiorare la qualità dell'immagine.