Jak zoptymalizować rozdzielczość i szybkość transmisji danych w Jitsi Meet przy niskiej przepustowości

Co należy zmienić w pierwszej kolejności w przypadku wdrożenia Jitsi Meet o niskiej przepustowości?

Zacznij od trzech ustawień, w następującej kolejności: obniż rozdzielczość przechwytywania obrazu z kamery, zmniejsz liczbę zdalnych filmów odbieranych przez każdego klienta, a dopiero potem zaostrz limity przepływności dla poszczególnych kodeków. Ta kolejność ma znaczenie, ponieważ rozdzielczość i liczba odbieranych strumieni zazwyczaj mają najwyraźniejszy wpływ na zużycie pasma, podczas gdy agresywne limity przepływności mogą sprawić, że ruch będzie wyglądał niewyraźnie, nie rozwiązując problemu utraty pakietów ani niestabilności Wi-Fi.

Jitsi dokumentuje sterowanie wideo po stronie klienta w swoim aktualnym dokumencie referencyjnym dotyczącym konfiguracji . Według stanu na 6 października 2026 r. constraintsobiekt domyślnie ma idealną wysokość przechwytywania 720p, channelLastNdomyślnie jest nieograniczony -1i startLastNmoże rozpocząć konferencję z mniejszą liczbą odebranych filmów, zanim użytkownik zmieni ustawienie „Zarządzaj jakością wideo”.

W przypadku ograniczonego oddziału, mobilnego punktu dostępowego, łącza na wsi lub przeciążonej sieci Wi-Fi, praktycznym celem początkowym jest często rozdzielczość 360p zamiast 720p. Strona Jitsi poświęcona wymaganiom infrastrukturalnym podaje przybliżone wartości planistyczne: około 200 kb/s dla rozdzielczości 180p, 500 kb/s dla rozdzielczości 360p i 2,5 Mb/s dla rozdzielczości 720p, ostrzegając jednocześnie, że rzeczywiste wymagania zależą od wielu czynników. Należy traktować te wartości jako wartości orientacyjne do planowania przepustowości, a nie gwarantowane stawki na użytkownika. Zapoznaj się z oficjalnym przewodnikiem po wymaganiach Jitsi Meet .

Przykładowy widok spotkania pokazujący wybór jakości 360p w przypadku ograniczonego połączenia. Dokładny układ elementów sterujących może się różnić w zależności od wersji Jitsi Meet.

Czy należy ograniczać rozdzielczość przed szybkością transmisji danych?

Zazwyczaj tak. Obniżenie wysokości przechwytywania zmniejsza liczbę pikseli, które koder musi przetworzyć, zanim rozpocznie się alokacja przepływności. Aktualny dokument konfiguracyjny Jitsi oddziela wideo W3C constraintsod starszej preferowanej resolutionwartości i zaznacza, że ​​ograniczenia domyślnie dotyczą idealnej wysokości przechwytywania 720p.

W przypadku witryny, w której stabilność nagrania wideo ma większe znaczenie niż drobne szczegóły twarzy, przetestuj sufitowe urządzenie do przechwytywania obrazu 360p w następujący sposób:

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

To przykładowy profil, a nie domyślny profil Jitsi. Prosi on przeglądarkę o preferowanie rozdzielczości 360p i nieprzekraczanie jej, jednocześnie pozwalając ścieżce przechwytywania na ustawienie rozdzielczości nawet na 180p w razie potrzeby. Nie zakładaj, że min: 180gwarantuje to stabilny strumień 180p przy dużym obciążeniu; WebRTC nadal reaguje na dostępną przepustowość, obciążenie procesora, utratę pakietów, możliwości urządzenia i zachowanie kodeka.

Przykładowa samodzielnie hostowana konfiguracja Jitsi z maksymalnym zakresem przechwytywania 360p i konserwatywnymi wartościami LastN.

Ile zdalnych transmisji wideo powinien otrzymać każdy uczestnik?

Jeśli uczestnik odbiera osiem zdalnych strumieni wideo jednocześnie, obniżenie rozdzielczości tylko lokalnej kamery nie rozwiązuje problemu z pobieraniem całości. Jitsi oferuje funkcje LastN, które pozwalają kontrolować liczbę zdalnych strumieni wideo przesyłanych do uczestnika.

Udokumentowana channelLastNwartość domyślna to -1, co oznacza nieograniczony czas. Udokumentowana startLastNopcja pozwala rozpocząć konferencję z mniejszą wartością LastN, a Jitsi zaznacza, że channelLastN​​jest ona używana, gdy użytkownik zmienia poziom jakości za pomocą suwaka „Zarządzaj jakością wideo”.

Ostrożny punkt wyjścia dla środowiska o ograniczonej przepustowości jest następujący:

channelLastN: 2,
startLastN: 1,

W tym przykładzie uczestnik rozpoczyna od otrzymania jednego zdalnego wideo i może przejść do stanu, w którym otrzymuje maksymalnie dwa zdalne wideo, w zależności od jakości działania aplikacji. Nie należy traktować 2i 1jako uniwersalnych rekomendacji. Klasa, w której uczniowie obserwują głównie jednego prezentera, może użyć mniejszej liczby LastN niż czteroosobowa recenzja projektu, w której wszyscy muszą pozostać widoczni.

Jakich wartości przepływności używa obecnie Jitsi?

Aktualny szablon i referencje konfiguracji Jitsi config.jsujawniają poziomy specyficzne dla kodeków maxBitratesVideo. W konfiguracji głównej projektu, prezentowanej 6 października 2026 roku, AV1 używa 100 000 bitów/s dla niskiego, 300 000 bitów/s dla standardowego i 1 000 000 bitów/s dla wysokiego; VP9 używa 100 000, 300 000 i 1 200 000 bitów/s; VP8 i H.264 używają 200 000, 500 000 bitów/s i 1 500 000 bitów/s dla tych samych poziomów. Szablon na żywo można sprawdzić w oficjalnym repozytorium Jitsi Meet na GitHubie .

Te wartości to domyślne wartości upstream lub wartości szablonowe, a nie obietnica, że ​​każde połączenie będzie transmitowane z dokładnie taką prędkością. Szacowanie przepustowości WebRTC, kontrola przeciążenia, wybrany kodek, symultaniczne lub skalowalne zachowanie kodowania, złożoność sceny, liczba klatek na sekundę i ograniczenia odbiornika – wszystkie te czynniki wpływają na to, co jest faktycznie wysyłane.

Kiedy obniżenie limitów ma sens?

Obniż limity, gdy budżet sieci jest znany, a stabilność obrazu jest ważniejsza niż szczegóły. Na przykład możesz przetestować profil VP8, taki jak:

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

Te liczby zostały celowo oznaczone jako przykładowe do testowania, a nie jako domyślne wartości Jitsi. Mają sens tylko wtedy, gdy VP8 jest faktycznie negocjowany na punktach końcowych, na których Ci zależy. Jeśli Twoi klienci na komputerach stacjonarnych preferują AV1 lub VP9, ​​dostosowanie samego obiektu VP8 nie przyniesie oczekiwanego efektu.

Przykładowe limity przepływności VP8 dla ograniczonej sieci; przed wdrożeniem przetestuj je na własnych urządzeniach i wzorcach połączeń.

Czy należy wymuszać używanie konkretnego kodeka w celu oszczędzania przepustowości?

Nie automatycznie. Nowoczesne kompilacje Jitsi udostępniają preferowaną kolejność kodeków i różne domyślne drabinki bitrate dla AV1, VP9, ​​VP8 i H.264. AV1 i VP9 mogą być wydajne, ale wybór kodeka wpływa również na koszt procesora, obsługę urządzeń, obsługę przeglądarek i funkcje skalowalności. Laptop o niskiej mocy, który ma problemy z kodowaniem bardziej złożonego kodeka, może nie osiągnąć oczekiwanych rezultatów, nawet jeśli kodek jest wydajny na papierze.

Bezpieczniejszą zasadą działania jest zachowanie obecnych preferencji kodeków Jitsi, chyba że pomiary wskazują na problem. Jeśli zmienisz kolejność kodeków, przetestuj ją na rzeczywistych kombinacjach przeglądarek Chrome, Firefox, Safari, Android i iOS używanych w Twojej organizacji. Nie wnioskuj o wydajności kodeków na podstawie pojedynczej przeglądarki na komputerze.

A co z udostępnianiem ekranu przy wolnym połączeniu?

Udostępnianie ekranu wiąże się z innym kompromisem jakościowym niż wideo z kamery. Tekst i slajdy korzystają z czytelnej rozdzielczości, podczas gdy płynny ruch wymaga większej liczby klatek na sekundę. Dokumenty Jitsi desktopSharingFrameRatei obecnie wyświetlają domyślną wartość { min: 5, max: 5 }. W przypadku spotkań z dużą ilością prezentacji, pozostawienie udostępniania ekranu na poziomie około 5 kl./s pozwala zachować czytelność bez marnowania przepustowości na niepotrzebny ruch.

Jeśli użytkownicy udostępniają animacje, rotacje CAD lub klipy wideo, 5 kl./s może wydawać się zbyt wolne. W takim przypadku należy ostrożnie zwiększyć liczbę klatek na sekundę i obserwować, czy nie nastąpi spadek rozdzielczości lub utrata pakietów. Oficjalna dokumentacja konfiguracji Jitsi zawiera właściwe nazwy aktualnie obsługiwanych opcji.

Skąd wiesz, czy zmiany faktycznie pomogły?

Nie oceniaj obrazu tylko na podstawie tego, czy „wygląda dobrze”. Sprawdź działanie sieci. Interfejs API IFrame firmy Jitsi udostępnia funkcję getConnectionStats(), która może zwracać jakość połączenia lokalnego, dostępną przepustowość, szybkość przesyłania i pobierania, szybkość przesyłania danych audio i wideo, utratę pakietów, informacje o kodeku, liczbę klatek na sekundę, zdekodowane klatki, rozdzielczość i szczegóły transportu. Zobacz oficjalne informacje o funkcjach interfejsu API IFrame .

W przypadku wdrożeń osadzonych proste sprawdzenie może wyglądać następująco:

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

Przeprowadź ten sam schemat spotkania przed i po wprowadzeniu zmian. Skuteczny test musi spełniać co najmniej trzy warunki: standardową przepustowość łącza biurowego, celowo ograniczoną przepustowość oraz realistyczną rozmowę wieloosobową. Zanotuj, czy dźwięk pozostaje zrozumiały, obraz się zawiesza, wzrasta utrata pakietów, rozdzielczość uczestników spada, a obciążenie procesora staje się nadmierne.

Ilustratywny widok statystyk połączenia pokazujący rodzaj rozdzielczości, liczbę klatek na sekundę, szybkość transmisji danych i wartości strat, które należy porównać podczas walidacji.

Od którego profilu niskiej przepustowości powinieneś zacząć?

Są to profile początkowe, a nie gwarantowane optymalne wartości. Prawidłowa konfiguracja zależy od asymetrii łącza w górę i w dół, liczby uczestników, zawartości kamery, wybranego kodeka, procesora punktu końcowego oraz jakości oczekiwanej przez użytkowników.

Gdzie należy edytować konfigurację na serwerze hostowanym samodzielnie?

W instalacji pakietu Debian, Jitsi zazwyczaj przechowuje konfigurację hosta wirtualnego w pliku /etc/jitsi/meet/<your-hostname>-config.js. Własna dokumentacja uwierzytelniania Jitsi używa tej ścieżki w przykładach. W przypadku wdrożeń Dockera, oficjalny podręcznik Dockera mówi, że wygenerowane config.jspliki w kontenerze są odtwarzane podczas uruchamiania, dlatego ustawienia niestandardowe powinny być przechowywane w pliku po stronie hosta CONFIG/web/custom-config.js. Zobacz oficjalny podręcznik samodzielnego hostingu Dockera .

Przed edycją skopiuj istniejącą konfigurację, zmień pojedynczo jedną grupę parametrów i sprawdź poprawność składni JavaScript. Unikaj wklejania całego przykładu config.jsdo działającego wdrożenia, ponieważ szablony nadrzędne ewoluują i mogą zawierać wartości specyficzne dla wdrożenia.

Jaka kolejność strojenia jest najbezpieczniejsza?

1. Najpierw zmierz. Odtwórz problem niskiej przepustowości z realistyczną liczbą uczestników i zanotuj utratę pakietów, przepływność, rozdzielczość i obciążenie procesora.
2. Nagrywaj w rozdzielczości 360p. Użyj constraints.video.heighti sprawdź, czy poprawi się stabilność wideo.
3. Zmniejsz liczbę odbieranych strumieni. Zmniejsz startLastNi, jeśli to konieczne, channelLastNaby każdy uczestnik nie pobierał niepotrzebnych miniaturek.
4. Zachowaj czytelność udostępnianego ekranu. Utrzymuj niską liczbę klatek na sekundę podczas udostępniania ekranu dla slajdów i dokumentów, chyba że przypadek użycia wymaga ruchu.
5. Dostosuj limity przepływności kodeków na końcu. Zmieniaj tylko profile kodeków faktycznie wynegocjowane przez klientów i porównuj jakość przed i po.
6. Przetestuj ponownie przy przeciążeniu. Konfiguracja, która wygląda dobrze w sieci LAN, może nie działać w hotelowym Wi-Fi lub mobilnym hotspocie.

Czego należy unikać?

Nie wyłączaj funkcji transmisji równoległej ani retransmisji tylko dlatego, że chcesz zmniejszyć przepustowość; te ustawienia wpływają na sposób, w jaki Jitsi adaptuje się i odzyskuje dane po utracie, a ich zmiana może prowadzić do nowych trybów awarii. Nie wymuszaj 180p dla każdego użytkownika, chyba że przypadek użycia to rzeczywiście toleruje. Nie traktuj limitu przepływności jako rezerwacji tej przepustowości. Nie optymalizuj również wyłącznie łącza serwerowego, ignorując połączenie ostatniej mili w każdym punkcie końcowym.

Najlepsza konfiguracja Jitsi o niskiej przepustowości to zatem nie ta z najmniejszymi wartościami. To taka, która zapewnia niezawodność dźwięku, czytelność aktywnego mówcy, ogranicza zbędny sygnał wideo i jednocześnie daje koderowi wystarczająco dużo miejsca na adaptację. Zacznij od rozdzielczości 360p, zachowawczych wartości LastN i domyślnych ustawień kodeka Jitsi; a następnie zawężaj limity przepływności tylko wtedy, gdy pomiary wykażą, że takie działanie poprawia jakość spotkania, a nie tylko obniża jakość obrazu.