Cum să optimizezi rezoluția și rata de biți Jitsi Meet pentru lățime de bandă redusă

Ce ar trebui să schimbi mai întâi la o implementare Jitsi Meet cu lățime de bandă redusă?

Începeți cu trei controale, în această ordine: reduceți rezoluția de captură a camerei, reduceți numărul de videoclipuri la distanță pe care le primește fiecare client și abia apoi strângeți limitele de rată de biți specifice codecului. Această secvență contează deoarece rezoluția și numărul de fluxuri primite au de obicei cel mai clar efect asupra consumului de lățime de bandă, în timp ce limitele agresive de rată de biți pot face ca mișcarea să pară confuză fără a rezolva pierderea de pachete sau instabilitatea Wi-Fi.

Jitsi documentează controalele video pe partea de client în referința sa de configurare actuală . Începând cu 6 octombrie 2026, documentația precizează că constraintsobiectul are implicit o înălțime de captură ideală de 720p, channelLastNimplicit o rezoluție nelimitată cu -1și startLastNpoate începe o conferință cu mai puține videoclipuri primite înainte ca utilizatorul să modifice setarea Gestionare calitate video.

Pentru o sucursală cu restricții, un hotspot mobil, o legătură rurală sau o rețea Wi-Fi supraîncărcată, o țintă de pornire practică este adesea 360p, mai degrabă decât 720p. Pagina cu cerințe de infrastructură Jitsi oferă cifre aproximative de planificare de aproximativ 200 kbit/s pentru 180p, 500 kbit/s pentru 360p și 2,5 Mbit/s pentru 720p, avertizând totodată că cerințele reale variază în funcție de mulți factori. Tratați aceste cifre ca referințe pentru planificarea capacității, nu ca rate garantate per utilizator. Consultați ghidul oficial cu cerințe Jitsi Meet .

Vizualizare ilustrativă a întâlnirii care prezintă o opțiune de calitate 360p pentru o conexiune restricționată; aspectul exact al comenzilor poate varia în funcție de versiunea Jitsi Meet.

Ar trebui să limitezi rezoluția înainte de rata de biți?

De obicei, da. Reducerea înălțimii de captură reduce numărul de pixeli pe care codificatorul trebuie să îi proceseze înainte de a începe alocarea ratei de biți. Referința de configurare actuală a lui Jitsi separă videoclipul W3C constraintsde valoarea preferată mai veche resolutionși menționează că restricțiile sunt implicite la o înălțime de captură ideală de 720p.

Pentru un site în care stabilitatea video contează mai mult decât detaliile faciale fine, testați un plafon de captură 360p ca acesta:

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

Acesta este un exemplu de profil, nu un profil implicit Jitsi. Acesta solicită browserului să prefere 360p și să nu îl depășească, permițând în același timp ca traseul de captură să scadă până la 180p, dacă este necesar. Evitați să presupuneți că acest lucru min: 180garantează un flux stabil de 180p în condiții de congestie severă; WebRTC poate răspunde în continuare la lățimea de bandă disponibilă, încărcarea procesorului, pierderea de pachete, capacitățile dispozitivului și comportamentul codecului.

Exemplu de configurație Jitsi auto-găzduită cu un plafon de captură de 360p și valori LastN conservatoare.

Câte fluxuri video la distanță ar trebui să primească fiecare participant?

Dacă un participant primește opt videoclipuri de la distanță simultan, reducerea doar a rezoluției camerei locale nu acoperă întreaga parte a descărcărilor. Jitsi oferă controale LastN specifice pentru câte fluxuri video de la distanță sunt redirecționate către un participant.

Valoarea implicită documentată channelLastNeste -1, adică nelimitat. startLastNOpțiunea documentată permite începerea unei conferințe cu o valoare LastN mai mică, iar Jitsi notează că aceasta channelLastNeste utilizată atunci când utilizatorul modifică nivelul de calitate cu ajutorul cursorului Gestionare calitate video.

Un punct de plecare precaut pentru un mediu cu lățime de bandă limitată este:

channelLastN: 2,
startLastN: 1,

În acest exemplu, un participant începe prin a primi un videoclip la distanță și poate trece la o stare în care sunt primite până la două videoclipuri la distanță, în funcție de comportamentul calitativ al aplicației. Nu tratați 2și 1ca recomandări universale. O sală de clasă în care studenții urmăresc în principal un prezentator poate utiliza un LastN mai mic decât o evaluare de design cu patru persoane, unde toată lumea trebuie să rămână vizibilă.

Ce valori ale ratei de biți folosește Jitsi în prezent?

Șablonul actual și referința de configurare Jitsi config.jsexpun niveluri specifice codecurilor maxBitratesVideo. În configurația principală a proiectului vizualizată pe 6 octombrie 2026, AV1 utilizează 100.000 bit/s pentru nivel scăzut, 300.000 pentru standard și 1.000.000 pentru nivel înalt; VP9 utilizează 100.000, 300.000 și 1.200.000; VP8 și H.264 utilizează 200.000, 500.000 și 1.500.000 pentru aceleași niveluri. Puteți verifica șablonul live în depozitul oficial Jitsi Meet GitHub .

Aceste valori sunt valori implicite în amonte sau valori șablon, nu o promisiune că fiecare apel va fi transmis exact la acele rate. Estimarea lățimii de bandă WebRTC, controlul congestiei, codecul selectat, comportamentul de codare simulcast sau scalabilă, complexitatea scenei, rata de cadre și constrângerile receptorului afectează toate ceea ce este trimis efectiv.

Când are sens să se reducă plafonul?

Reduceți limitele atunci când bugetul rețelei este cunoscut și stabilitatea video contează mai mult decât detaliile. De exemplu, puteți testa un profil VP8, cum ar fi:

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

Aceste numere sunt etichetate în mod deliberat ca exemple pentru testare, nu ca valori implicite Jitsi. Au sens doar dacă VP8 este negociat efectiv pe endpoint-urile care vă interesează. Dacă clienții desktop preferă AV1 sau VP9, ​​ajustarea doar a obiectului VP8 nu va produce efectul așteptat.

Exemple de limite de biți VP8 pentru o rețea constrânsă; testați-le pe propriile dispozitive și modele de apeluri înainte de lansare.

Ar trebui să forțezi un anumit codec pentru a economisi lățime de bandă?

Nu automat. Versiunile moderne de Jitsi expun ordinea preferințelor de codec și diferite scale implicite de bitrate pentru AV1, VP9, ​​VP8 și H.264. AV1 și VP9 pot fi eficiente, dar alegerea codecului afectează și costul procesorului, compatibilitatea dispozitivelor, compatibilitatea browserelor și funcțiile de scalabilitate. Un laptop cu putere redusă care are dificultăți în a codifica un codec mai complex poate oferi o întâlnire mai slabă, chiar dacă codecul este eficient pe hârtie.

O regulă operațională mai sigură este să păstrați comportamentul actual al preferințelor de codec Jitsi, cu excepția cazului în care aveți măsurători care arată o problemă. Dacă schimbați ordinea codecurilor, testați pe combinațiile reale de Chrome, Firefox, Safari, Android și iOS utilizate de organizația dvs. Nu deduceți performanța codecurilor dintr-un singur browser desktop.

Dar cum rămâne cu partajarea ecranului pe o conexiune lentă?

Partajarea ecranului are un compromis calitativ diferit față de videoclipul de pe cameră. Textul și diapozitivele beneficiază de o rezoluție lizibilă, în timp ce mișcarea fluidă necesită mai multe cadre pe secundă. Jitsi documentează desktopSharingFrameRateși listează în prezent o valoare implicită de { min: 5, max: 5 }. Pentru o întâlnire cu prezentări intense, menținerea partajării ecranului la aproximativ 5 fps poate păstra lizibilitatea fără a consuma lățime de bandă pentru mișcare inutilă.

Dacă utilizatorii partajează animații, rotații CAD sau clipuri video, 5 fps ar putea fi prea lent. În acest caz, creșteți cu atenție rata de cadre și observați dacă rezoluția sau pierderea de pachete se degradează. Documentația oficială de configurare Jitsi este referința corectă pentru numele opțiunilor acceptate în prezent.

Cum știi dacă schimbările au ajutat cu adevărat?

Nu judecați doar după dacă imaginea „arată bine”. Validați comportamentul rețelei. API-ul IFrame al Jitsi expune getConnectionStats(), care poate returna calitatea conexiunii locale, lățimea de bandă disponibilă, rata de biți la încărcare și descărcare, rata de biți audio și video, pierderea de pachete, informații despre codec, rata de cadre, cadrele decodificate, rezoluția și detaliile despre transport. Consultați referința oficială a funcțiilor API-ului IFrame .

Pentru implementările încorporate, o verificare simplă poate arăta astfel:

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

Rulați același model de întâlnire înainte și după modificări. Un test util are cel puțin trei condiții: lățime de bandă normală la birou, lățime de bandă limitată în mod deliberat și un apel realist cu mai mulți participanți. Înregistrați dacă sunetul rămâne inteligibil, dacă imaginea video se blochează, dacă pierderea de pachete crește, dacă participanții trec la o rezoluție mai mică sau dacă utilizarea procesorului devine excesivă.

Vizualizare ilustrativă a statisticilor de conexiune care arată tipul de rezoluție, rata de cadre, rata de biți și valorile de pierdere pentru comparare în timpul validării.

Cu ce ​​profil de lățime de bandă redusă ar trebui să începeți?

Acestea sunt profiluri de pornire, nu sunt garantate valori optime. Configurația corectă depinde de asimetria uplink-ului și downlink-ului, numărul de participanți, conținutul camerei, codecul ales, procesorul terminalului și calitatea așteptată de utilizatori.

Unde ar trebui să editezi configurația pe un server auto-găzduit?

Într-o instalare cu pachet Debian, Jitsi păstrează de obicei configurația web virtual-host în /etc/jitsi/meet/<your-hostname>-config.js. Documentația proprie de autentificare Jitsi folosește această cale în exemplele sale. În implementările Docker, ghidul oficial Docker spune că config.jsfișierele generate în interiorul containerului sunt recreate la pornire, așa că setările personalizate ar trebui să fie plasate în fișierul gazdă CONFIG/web/custom-config.js. Consultați ghidul oficial de auto-găzduire Docker .

Înainte de editare, copiați configurația existentă, modificați câte un grup de parametri pe rând și validați sintaxa JavaScript. Evitați să lipiți un întreg exemplu config.jspeste o implementare funcțională, deoarece șabloanele din amonte evoluează și pot include valori specifice implementării.

Care este cea mai sigură ordine de acordare?

1. Măsurați mai întâi. Reproduceți problema lățimii de bandă reduse cu un număr realist de participanți și notați pierderea de pachete, rata de biți, rezoluția și încărcarea procesorului.
2. Limitează captura de cameră la 360p. Folosește constraints.video.heightși testează dacă stabilitatea video se îmbunătățește.
3. Reduceți fluxurile primite. Reduceți startLastNși, dacă este necesar, channelLastNastfel încât fiecare participant să nu descarce miniaturi inutile.
4. Păstrați lizibilitatea partajării ecranului. Mențineți o rată de cadre pe secundă redusă pentru diapozitive și documente, cu excepția cazului în care cazul de utilizare necesită mișcare.
5. Reglați limitele ratei de biți a codecurilor pentru a le menține la zi. Modificați doar profilurile de codecuri negociate efectiv de clienții dvs. și comparați calitatea înainte și după.
6. Repetați testul în condiții de congestie. O configurație care arată bine pe o rețea LAN poate eșua pe Wi-Fi-ul hotelului sau pe un hotspot mobil.

Ce ar trebui să eviți?

Nu dezactivați funcțiile de simulcast sau retransmisie doar pentru că încercați să reduceți lățimea de bandă; aceste controale afectează modul în care Jitsi se adaptează și se recuperează după pierderi, iar modificarea lor poate crea noi moduri de eroare. Nu forțați 180p pentru fiecare utilizator, cu excepția cazului în care acest lucru este cu adevărat tolerat. Nu tratați o limită a ratei de biți ca o rezervare a acelei lățimi de bandă. Și nu optimizați doar legătura serverului, ignorând conexiunea de ultim kilometru la fiecare punct final.

Prin urmare, cea mai bună configurație Jitsi cu lățime de bandă redusă nu este cea cu cele mai mici numere. Este cea care menține sunetul fiabil, menține vorbitorul activ lizibil, limitează videoclipurile primite inutile și totuși oferă codificatorului suficient spațiu de adaptare. Începeți cu 360p, valori LastN conservatoare și setările implicite actuale ale codecului Jitsi; apoi strângeți limitele ratei de biți numai atunci când măsurătorile arată că acest lucru îmbunătățește întâlnirea, în loc să reducă pur și simplu calitatea imaginii.