Wie man die Auflösung und Bitrate von Jitsi Meet für geringe Bandbreite optimiert

Was sollten Sie bei einer Jitsi Meet-Bereitstellung mit geringer Bandbreite als Erstes ändern?

Beginnen Sie mit drei Einstellungen in dieser Reihenfolge: Verringern Sie die Kameraauflösung, reduzieren Sie die Anzahl der von jedem Client empfangenen Remote-Videos und passen Sie erst dann die Bitratenbegrenzungen für die einzelnen Codecs an. Diese Reihenfolge ist wichtig, da Auflösung und Anzahl der empfangenen Streams in der Regel den größten Einfluss auf den Bandbreitenverbrauch haben, während zu hohe Bitratenbegrenzungen Bewegungen unscharf erscheinen lassen können, ohne Paketverluste oder WLAN-Instabilität zu beheben.

Jitsi dokumentiert die clientseitigen Videosteuerungen in seiner aktuellen Konfigurationsreferenz . Laut Dokumentation vom 6. Oktober 2026 ist die constraintsAufnahmehöhe des Objekts standardmäßig auf 720p eingestellt, die Anzahl der empfangenen Videos channelLastNist standardmäßig unbegrenzt -1, und startLastNeine Konferenz kann mit weniger empfangenen Videos gestartet werden, bevor der Benutzer die Einstellung „Videoqualität verwalten“ ändert.

Für ressourcenbeschränkte Zweigstellen, mobile Hotspots, ländliche Verbindungen oder überlastete WLAN-Netzwerke ist 360p oft ein sinnvoller Ausgangspunkt anstelle von 720p. Auf der Seite mit den Infrastrukturanforderungen von Jitsi finden sich grobe Planungswerte von ca. 200 kbit/s für 180p, 500 kbit/s für 360p und 2,5 Mbit/s für 720p. Gleichzeitig wird darauf hingewiesen, dass der tatsächliche Bedarf von vielen Faktoren abhängt. Diese Werte dienen als Richtwerte für die Kapazitätsplanung und stellen keine garantierten Datenraten pro Nutzer dar. Weitere Informationen finden Sie im offiziellen Jitsi Meet-Leitfaden .

Beispielhafte Meeting-Ansicht mit 360p-Qualitätsoption für eine eingeschränkte Verbindung; das genaue Bedienfeld-Layout kann je nach Jitsi Meet-Version variieren.

Sollte die Auflösung vor der Bitrate begrenzt werden?

In der Regel ja. Durch die Verringerung der Aufnahmehöhe reduziert sich die Anzahl der Pixel, die der Encoder verarbeiten muss, bevor die Bitratenzuweisung überhaupt beginnt. Die aktuelle Konfigurationsreferenz von Jitsi unterscheidet zwischen dem W3C-Video constraintsund dem älteren bevorzugten resolutionWert und weist darauf hin, dass die Einschränkungen standardmäßig auf eine ideale Aufnahmehöhe von 720p eingestellt sind.

Für eine Umgebung, in der Videostabilität wichtiger ist als feine Gesichtsdetails, testen Sie eine 360p-Aufnahmehöhe wie diese:

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

Dies ist ein Beispielprofil, keine Jitsi-Standardeinstellung. Es weist den Browser an, 360p zu bevorzugen und diese Auflösung nicht zu überschreiten, ermöglicht aber bei Bedarf eine Auflösung bis auf 180p. Gehen Sie nicht davon aus, dass dies min: 180einen stabilen 180p-Stream bei starker Auslastung garantiert; WebRTC kann weiterhin auf verfügbare Bandbreite, CPU-Auslastung, Paketverluste, Gerätefunktionen und das Verhalten des Codecs reagieren.

Beispiel einer selbstgehosteten Jitsi-Konfiguration mit einer maximalen Aufnahmeauflösung von 360p und konservativen LastN-Werten.

Wie viele Video-Streams sollte jeder Teilnehmer erhalten?

Wenn ein Teilnehmer acht Remote-Videos gleichzeitig empfängt, reicht es nicht aus, lediglich die Auflösung der lokalen Kamera zu verringern, um das Problem beim Download zu beheben. Jitsi bietet daher spezielle Steuerungsmöglichkeiten, um festzulegen, wie viele Remote-Videostreams an einen Teilnehmer weitergeleitet werden.

Der dokumentierte channelLastNStandardwert ist -1„unbegrenzt“. Die dokumentierte startLastNOption ermöglicht es, eine Konferenz mit einem kleineren LastN-Wert zu beginnen. Jitsi weist darauf hin, dass diese Option channelLastNverwendet wird, wenn der Benutzer die Qualitätsstufe mit dem Schieberegler „Videoqualität verwalten“ ändert.

Ein vorsichtiger Ausgangspunkt für eine bandbreitenbeschränkte Umgebung ist:

channelLastN: 2,
startLastN: 1,

In diesem Beispiel empfängt ein Teilnehmer zunächst ein Remote-Video und kann, abhängig von der Qualität der Anwendung, in einen Zustand wechseln, in dem bis zu zwei Remote-Videos empfangen werden. Die angegebenen Werte sind nicht als allgemeingültige Empfehlungen zu verstehen 2. 1In einem Klassenzimmer, in dem die Studierenden hauptsächlich einem Präsentator zusehen, kann ein kleinerer LastN-Wert verwendet werden als bei einer Designbesprechung mit vier Personen, bei der alle sichtbar bleiben müssen.

Welche Bitratenwerte verwendet Jitsi aktuell?

Die aktuelle Vorlage und Konfigurationsreferenz von Jitsi config.jszeigen codecspezifische maxBitratesVideoStufen an. In der Masterkonfiguration des Projekts vom 6. Oktober 2026 verwendet AV1 100.000 Bit/s für niedrig, 300.000 für Standard und 1.000.000 für hoch; VP9 verwendet 100.000, 300.000 und 1.200.000 Bit/s; VP8 und H.264 verwenden 200.000, 500.000 und 1.500.000 Bit/s für dieselben Stufen. Sie können die Live-Vorlage im offiziellen GitHub-Repository von Jitsi Meet überprüfen .

Diese Werte sind vordefinierte Standardwerte oder Vorlagenwerte und keine Garantie dafür, dass jeder Anruf exakt mit diesen Datenraten übertragen wird. Die Bandbreitenschätzung von WebRTC, die Staukontrolle, der gewählte Codec, das Verhalten bei Simulcast oder skalierbarer Codierung, die Szenenkomplexität, die Bildrate und die Empfängerbeschränkungen beeinflussen die tatsächlich gesendeten Daten.

Wann ist es sinnvoll, die Obergrenzen zu senken?

Reduzieren Sie die Begrenzungen, wenn Ihr Netzwerkbudget bekannt ist und eine stabile Videoübertragung wichtiger ist als Detailgenauigkeit. Sie könnten beispielsweise ein VP8-Profil wie folgt testen:

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

Diese Werte dienen lediglich als Beispiel für Testzwecke und stellen keine Jitsi-Standardwerte dar. Sie sind nur dann sinnvoll, wenn VP8 auf den relevanten Endpunkten tatsächlich ausgehandelt wird. Bevorzugen Ihre Desktop-Clients AV1 oder VP9, ​​führt die Anpassung des VP8-Objekts allein nicht zum gewünschten Ergebnis.

Beispielhafte VP8-Bitratenbegrenzungen für ein Netzwerk mit begrenzten Ressourcen; testen Sie diese vor der Veröffentlichung anhand Ihrer eigenen Geräte und Anrufmuster.

Sollte man einen bestimmten Codec erzwingen, um Bandbreite zu sparen?

Nicht automatisch. Moderne Jitsi-Versionen legen die Prioritäten für Codecs und unterschiedliche Standard-Bitraten für AV1, VP9, ​​VP8 und H.264 fest. AV1 und VP9 können effizient sein, die Codec-Wahl beeinflusst jedoch auch die CPU-Auslastung, die Geräte- und Browserunterstützung sowie die Skalierbarkeit. Ein leistungsschwacher Laptop, der Schwierigkeiten mit der Codierung eines komplexeren Codecs hat, kann selbst bei einem theoretisch effizienten Codec zu schlechteren Ergebnissen führen.

Eine sicherere Betriebsregel ist, die aktuelle Codec-Präferenz von Jitsi beizubehalten, sofern keine Messwerte ein Problem aufzeigen. Wenn Sie die Codec-Reihenfolge ändern, testen Sie dies mit den in Ihrem Unternehmen tatsächlich verwendeten Kombinationen aus Chrome, Firefox, Safari, Android und iOS. Schließen Sie nicht von der Leistung eines einzelnen Desktop-Browsers auf die Codec-Performance.

Wie sieht es mit der Bildschirmfreigabe bei einer langsamen Internetverbindung aus?

Bildschirmfreigabe erfordert im Vergleich zu Kameravideos unterschiedliche Qualitätsabwägungen. Text und Folien profitieren von einer gut lesbaren Auflösung, während flüssige Bewegungen eine höhere Bildrate benötigen. Jitsi dokumentiert desktopSharingFrameRateund gibt aktuell einen Standardwert von 5 Bildern pro Sekunde an { min: 5, max: 5 }. Bei einer präsentationslastigen Besprechung kann eine Bildschirmfreigabe mit etwa 5 Bildern pro Sekunde die Lesbarkeit gewährleisten, ohne Bandbreite für unnötige Bewegungen zu verschwenden.

Wenn Nutzer Animationen, CAD-Rotationen oder Videoclips teilen, können 5 fps zu langsam erscheinen. Erhöhen Sie in diesem Fall die Bildrate vorsichtig und beobachten Sie, ob sich die Auflösung oder der Paketverlust verschlechtert. Die offizielle Jitsi-Konfigurationsdokumentation enthält die korrekten Informationen zu den aktuell unterstützten Optionsnamen.

Woran erkennt man, ob die Änderungen tatsächlich geholfen haben?

Beurteilen Sie die Bildqualität nicht allein nach dem Bild. Überprüfen Sie das Netzwerkverhalten. Die IFrame-API von Jitsi stellt Funktionen bereit getConnectionStats(), die Informationen wie lokale Verbindungsqualität, verfügbare Bandbreite, Upload- und Download-Bitrate, Audio- und Video-Bitrate, Paketverlust, Codec-Informationen, Framerate, dekodierte Frames, Auflösung und Transportdetails liefern. Weitere Informationen finden Sie in der offiziellen Referenz der IFrame-API-Funktionen .

Bei eingebetteten Systemen kann eine einfache Überprüfung wie folgt aussehen:

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

Führen Sie vor und nach Ihren Änderungen dasselbe Meeting-Muster durch. Ein aussagekräftiger Test umfasst mindestens drei Bedingungen: normale Bürobandbreite, bewusst eingeschränkte Bandbreite und eine realistische Konferenzschaltung mit mehreren Teilnehmern. Notieren Sie, ob die Audioqualität erhalten bleibt, das Video einfriert, der Paketverlust zunimmt, die Auflösung der Teilnehmer sinkt oder die CPU-Auslastung übermäßig ansteigt.

Beispielhafte Ansicht der Verbindungsstatistik, die die Art der Auflösung, Bildrate, Bitrate und Verlustwerte zeigt, die während der Validierung verglichen werden sollen.

Mit welchem ​​Profil für niedrige Bandbreite sollten Sie beginnen?

Dies sind Startprofile, keine garantierten optimalen Werte. Die richtige Konfiguration hängt von der Uplink- und Downlink-Asymmetrie, der Teilnehmerzahl, dem Kamerainhalt, dem gewählten Codec, der CPU des Endgeräts und der von den Nutzern erwarteten Qualität ab.

Wo sollte man die Konfiguration auf einem selbstgehosteten Server bearbeiten?

Bei einer Debian-Paketinstallation speichert Jitsi die Webkonfiguration des virtuellen Hosts üblicherweise in einem bestimmten Verzeichnis /etc/jitsi/meet/<your-hostname>-config.js. Die Jitsi-eigene Authentifizierungsdokumentation verwendet diesen Pfad in ihren Beispielen. Bei Docker-Bereitstellungen besagt die offizielle Docker-Anleitung, dass die config.jsim Container generierten Dateien beim Start neu erstellt werden. Daher sollten benutzerdefinierte Einstellungen CONFIG/web/custom-config.jsstattdessen in der Datei auf dem Host-System vorgenommen werden. Weitere Informationen finden Sie in der offiziellen Docker-Anleitung zum Selbsthosting .

Vor der Bearbeitung kopieren Sie die bestehende Konfiguration, ändern Sie jeweils nur eine Parametergruppe und überprüfen Sie die JavaScript-Syntax. Vermeiden Sie es, ein komplettes Beispiel config.jsin eine bestehende Produktionsumgebung einzufügen, da sich die vorgelagerten Vorlagen weiterentwickeln und umgebungsspezifische Werte enthalten können.

Was ist die sicherste Reihenfolge beim Stimmen?

1. Messen Sie zuerst. Reproduzieren Sie das Problem der geringen Bandbreite mit einer realistischen Teilnehmerzahl und notieren Sie Paketverluste, Bitrate, Auflösung und CPU-Auslastung.
2. Kameraaufnahme mit 360p. Testen Sie constraints.video.height, ob sich die Videostabilität verbessert.
3. Reduzieren Sie die Anzahl der empfangenen Streams. Verringern Sie die Anzahl startLastNgegebenenfalls, channelLastNdamit kein Teilnehmer unnötige Vorschaubilder herunterlädt.
4. Die Lesbarkeit der Bildschirmfreigabe sollte erhalten bleiben. Halten Sie die Bildwiederholrate für Folien und Dokumente niedrig, es sei denn, der Anwendungsfall erfordert Bewegung.
5. Die Codec-Bitratenbegrenzungen sollten zuletzt angepasst werden. Ändern Sie nur die Codec-Profile, die tatsächlich von Ihren Clients ausgehandelt wurden, und vergleichen Sie die Qualität vorher und nachher.
6. Testen Sie erneut unter hoher Netzwerkauslastung. Eine Konfiguration, die im LAN gut funktioniert, kann im Hotel-WLAN oder auf einem mobilen Hotspot fehlschlagen.

Was sollten Sie vermeiden?

Deaktivieren Sie Simulcast- oder Retransmission-Funktionen nicht nur, um Bandbreite zu sparen. Diese Einstellungen beeinflussen, wie Jitsi sich an Paketverluste anpasst und diese kompensiert. Änderungen daran können neue Fehlerquellen schaffen. Erzwingen Sie 180p nicht für alle Nutzer, es sei denn, der Anwendungsfall erlaubt dies unbedingt. Behandeln Sie eine Bitratenbegrenzung nicht als Bandbreitenreservierung. Und optimieren Sie nicht nur die Serververbindung, sondern vernachlässigen Sie die Anbindung an jedem Endpunkt.

Die beste Jitsi-Konfiguration für geringe Bandbreite ist daher nicht die mit den niedrigsten Werten. Sie gewährleistet eine zuverlässige Audioqualität, hält den aktiven Sprecher gut lesbar, begrenzt unnötige eingehende Videosignale und lässt dem Encoder genügend Spielraum. Beginnen Sie mit 360p, konservativen LastN-Werten und den aktuellen Standardeinstellungen des Jitsi-Codecs. Erhöhen Sie die Bitratenbegrenzung erst dann, wenn Ihre Messungen zeigen, dass dies die Meeting-Qualität verbessert, anstatt sie lediglich zu verringern.