Ridurre il carico sui client

[ebobferraris]

come noto a tutti, il carico su banda e risorse dei client, con le impostazioni di default, diventa insostenibile dopo un certo numero di partecipanti.

Noi del Jitsi Club stiamo testando alcune configurazioni che permettano di ridurre il carico sui client e, conseguentemente, consentano di tenere videoconferenze con un alto numero di partecipanti con webcam attiva.

La guida è in costante aggiornamento (sul punto v. sez. "tuning"), ma cerco di condividere anche qui i miei test in modo tale che sia più facile collaborare nella ricerca della configurazione ottimale.

Le modifiche al file /etc/jitsi/meet/*-config.js che ho provato ieri sono le seguenti:

→ Selezione Codec H264

di default Jitsi sembra usare VP8: impostare la preferenza per H264 dovrebbe ridurre il carico per i client senza accelerazione hardware per VP8.

    // If set to true, prefer to use the H.264 video codec (if supported).
    // Note that it's not recommended to do this because simulcast is not
    // supported when  using H.264. For 1-to-1 calls this setting is enabled by
    // default and can be toggled in the p2p section.
    preferH264: true,

→ Riduzione della risoluzione

il parametro resolution pare funzionare solo sui browser più vecchi, quindi bisogna agire anche sulla sezione constraints. (Ok, 480 normalmente non è 16:9. Da valutare 360 e 540).

    // Sets the preferred resolution (height) for local video. Defaults to 720.
    resolution: 480,

    // w3c spec-compliant video constraints to use for video capture. Currently
    // used by browsers that return true from lib-jitsi-meet's
    // util#browser#usesNewGumFlow. The constraints are independency from
    // this config's resolution value. Defaults to requesting an ideal aspect
    // ratio of 16:9 with an ideal resolution of 720.
    constraints: {
        video: {
             aspectRatio: 16 / 9,
             height: {
                 ideal: 480,
                 max: 480,
                 min: 240
             }
         }
     },

→ Sospensione dei layer inutilizzati

Il funzionamento è spiegato qui.

    // Enable / disable layer suspension.  If enabled, endpoints whose HD
    // layers are not in use will be suspended (no longer sent) until they
    // are requested again.
    enableLayerSuspension: true,

→ Riduzione del numero di stream ricevuti

Ispirandomi al funzionamento di Teams (che visualizza solo gli ultimi 4 ad aver parlato), ho trovato questo studio e queste istruzioni ufficiali. L'ideale forse è 4 (unico "problema" è che la schermata visualizza comunque tutti i parecipanti, anche quelli "spenti" - bisognerebbe vedere se si riesce a modificare l'interfaccia).

    // Default value for the channel "last N" attribute. -1 for unlimited.
    channelLastN: 6,

---

con queste impostazioni ieri ho tenuto una conferenza con 14 partecipanti (12 con video attivo) senza alcun problema né per il server (2 core 4gb ram 4gb swap) né per i client (la maggior parte smartphone, 1 tablet, 1 mac e qualche PC).

la cosa migliore sarebbe poterle testare in scenari diversi e con server più potenti e, per questo, chiedo il vostro aiuto (non è semplice mettere assieme 15/20 persone per un test).

un ulteriore parametro da testare è disableSimulcast, nel caso in cui non non si attivi preferH264.

downside: impostando una risoluzione massima lato server anche le conference con 2-3-4 partecipanti saranno in low-res

---

edit 28/03 h. 9.39: precisazioni sul codec H264

[feroda]

grazie mille @ebobferraris di quest'ottima sintesi e di rinnovarci il puntatore al Jitsi Club. NOI faremo delle prove, tu continua ad inserire commenti se raggiungete risultati interessanti, grazie!

[nicolapippa]

Buongiorno, posto la configurazione che utilizzo, il consumo di banda risulta essere poco meno di 1Mb/s ed è testato con 150/200 partecipanti sullo stesso server.

resolution : 360 constraints : { video: { aspectRatio: 16 / 9, height: { ideal : 360, max : 360, min : 180 } } }, preferH264 : false, enableLayerSuspension : true, channelLastN : 4

Impostando a true "preferH264" vedo che il consumo di banda aumenta più del doppio.

Purtroppo superati i 200 partecipanti in un server gli utenti lamentano video call di bassa qualità, sembra che superati un tot di persone connesse i flussi non vengano gestiti molto bene. Qualcuno ha idee su come configurare al meglio il software lato server per poter ospitare molti partecipanti?

[ebobferraris]

Ciao Nicola, 200 nella stessa stanza e con webcam accesa? È un numero mai raggiunto da nessuno qui e che non si pensava potesse essere raggiunto... Hai delle metriche da postare? Che caratteristiche ha il server?

[nicolapippa]

non nella stessa stanza, in stanze differenti (20/25 persone l'una, sono delle classi con docente e studenti) ma sullo stesso server. I docenti partono con webcam accesa mentre per gli studenti parte spenta, ma lascio loro l'opzione di attivare il video. Il server ((1 CPU Xeon Silver 4116 12 Core (1S, 12C), 32 GB di RAM, Debian 10) era stato pensato per ospitare almeno 800 partecipanti in contemporanea però arrivati a 200/250 utenti connessi sembra che il video bridge non gestisca proprio bene i flussi.

[tapionx]

@nicolapippa sai per caso dirci quale era l'utilizzo di CPU e di banda del server con 250 utenti connessi? Quale è la banda disponibile del server?

[nicolapippa]

L'utilizzo della CPU era intorno al 35%, l'utilizzo di banda era poco meno di 250 Mb/s mentre la banda disponibile è 1Gb/s.