Comment optimiser la résolution et le débit binaire de Jitsi Meet pour une faible bande passante

Que faut-il modifier en premier lors d'un déploiement Jitsi Meet à faible bande passante ?

Commencez par ajuster trois paramètres, dans cet ordre : réduisez la résolution de capture de la caméra, puis le nombre de flux vidéo distants reçus par chaque client, et enfin, seulement après, limitez le débit binaire spécifique au codec. Cet ordre est important car la résolution et le nombre de flux reçus ont généralement l’impact le plus direct sur la consommation de bande passante, tandis que des limites de débit binaire trop élevées peuvent rendre l’image floue sans pour autant résoudre les problèmes de perte de paquets ou d’instabilité du Wi-Fi.

Jitsi décrit les commandes vidéo côté client dans sa documentation de configuration actuelle . Au 6 octobre 2026, cette documentation indique que l' constraintsobjet est configuré par défaut avec une hauteur de capture idéale de 720p, channelLastNune résolution illimitée par défaut -1et startLastNqu'il est possible de démarrer une conférence avec un nombre réduit de vidéos reçues avant que l'utilisateur ne modifie le paramètre « Gérer la qualité vidéo ».

Pour un bureau secondaire aux ressources limitées, un point d'accès mobile, une liaison rurale ou un réseau Wi-Fi saturé, il est souvent plus judicieux de viser une résolution de 360p plutôt que de 720p. La page relative aux exigences d'infrastructure de Jitsi fournit des estimations de débit d'environ 200 kbit/s pour 180p, 500 kbit/s pour 360p et 2,5 Mbit/s pour 720p, tout en précisant que les besoins réels varient en fonction de nombreux facteurs. Ces chiffres sont à considérer comme des références pour la planification de la capacité et non comme des débits garantis par utilisateur. Consultez le guide officiel des exigences de Jitsi Meet .

Vue d'illustration d'une réunion montrant un choix de qualité 360p pour une connexion limitée ; la disposition exacte des commandes peut varier selon la version de Jitsi Meet.

Faut-il limiter la résolution avant le débit binaire ?

En général, oui. Diminuer la hauteur de capture réduit le nombre de pixels que l'encodeur doit traiter avant même le début de l'allocation du débit binaire. La documentation de configuration actuelle de Jitsi distingue la valeur vidéo W3C constraintsde l'ancienne resolutionvaleur recommandée et précise que les contraintes sont par défaut configurées pour une hauteur de capture idéale de 720p.

Pour un site où la stabilité vidéo importe plus que la finesse des détails du visage, testez une limite de capture 360p comme celle-ci :

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

Il s'agit d'un profil d'exemple, et non d'un profil par défaut de Jitsi. Il configure le navigateur pour privilégier une résolution de 360p et ne pas la dépasser, tout en autorisant une résolution de capture minimale de 180p si nécessaire. Attention : ce profil min: 180ne garantit pas un flux 180p stable en cas de forte congestion. WebRTC peut toujours s'adapter à la bande passante disponible, à la charge du processeur, aux pertes de paquets, aux capacités du périphérique et au comportement du codec.

Exemple de configuration Jitsi auto-hébergée avec une limite de capture de 360p et des valeurs LastN conservatrices.

Combien de flux vidéo à distance chaque participant doit-il recevoir ?

Si un participant reçoit huit flux vidéo distants simultanément, la simple réduction de la résolution de la caméra locale ne résout pas le problème du téléchargement. Jitsi propose des commandes LastN permettant de contrôler précisément le nombre de flux vidéo distants transmis à un participant.

La channelLastNvaleur par défaut documentée est -1illimitée. L' startLastNoption documentée permet de démarrer une conférence avec une valeur LastN plus petite, et Jitsi précise que cette valeur channelLastNest utilisée lorsque l'utilisateur modifie le niveau de qualité avec le curseur « Gérer la qualité vidéo ».

Un point de départ prudent pour un environnement à bande passante limitée est :

channelLastN: 2,
startLastN: 1,

Dans cet exemple, un participant commence par recevoir une vidéo à distance et peut passer à un état où il en reçoit jusqu'à deux, selon la qualité de l'application. Ces valeurs ne constituent pas 2des 1recommandations universelles. Une salle de classe où les étudiants suivent principalement un seul présentateur peut utiliser un nombre LastN plus faible qu'une réunion de conception à quatre personnes où chacun doit rester visible.

Quelles valeurs de débit binaire Jitsi utilise-t-il actuellement ?

config.jsLe modèle et la documentation de configuration actuels de Jitsi exposent maxBitratesVideoles niveaux de débit spécifiques à chaque codec. Dans la configuration principale du projet consultée le 6 octobre 2026, AV1 utilise 100 000 bits/s pour le niveau bas, 300 000 pour le niveau standard et 1 000 000 pour le niveau élevé ; VP9 utilise 100 000, 300 000 et 1 200 000 bits/s ; VP8 et H.264 utilisent respectivement 200 000, 500 000 et 1 500 000 bits/s pour ces mêmes niveaux. Vous pouvez consulter le modèle en direct sur le dépôt GitHub officiel de Jitsi Meet .

Ces valeurs correspondent aux valeurs par défaut ou aux valeurs modèles du réseau en amont ; elles ne garantissent pas que chaque appel sera transmis à ces débits précis. L’estimation de la bande passante WebRTC, le contrôle de la congestion, le codec sélectionné, le comportement de codage en simultané ou adaptatif, la complexité de la scène, la fréquence d’images et les contraintes du récepteur influent tous sur les données réellement transmises.

Quand est-il judicieux d'abaisser les plafonds ?

Réduisez les limites lorsque votre budget réseau est connu et que la stabilité vidéo prime sur la qualité des détails. Par exemple, vous pouvez tester un profil VP8 comme :

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

Ces valeurs sont volontairement données à titre d'exemple pour les tests et ne correspondent pas aux valeurs par défaut de Jitsi. Elles ne sont pertinentes que si le protocole VP8 est effectivement négocié sur les terminaux concernés. Si vos clients de bureau privilégient AV1 ou VP9, ​​la modification du seul paramètre VP8 ne produira pas l'effet escompté.

Exemples de limites de débit VP8 pour un réseau limité ; testez-les avec vos propres appareils et modèles d’appels avant le déploiement.

Faut-il imposer un codec particulier pour économiser de la bande passante ?

Pas automatiquement. Les versions récentes de Jitsi permettent de définir l'ordre de préférence des codecs et proposent différents débits binaires par défaut pour AV1, VP9, ​​VP8 et H.264. AV1 et VP9 peuvent être performants, mais le choix du codec influe également sur la charge du processeur, la compatibilité avec les périphériques et les navigateurs, ainsi que sur la scalabilité. Un ordinateur portable peu puissant, peinant à encoder un codec complexe, risque de fournir une réunion de qualité inférieure, même si le codec est théoriquement performant.

Par mesure de sécurité, il est recommandé de conserver les préférences de codec actuelles de Jitsi, sauf si des mesures révèlent un problème. Si vous modifiez l'ordre des codecs, effectuez des tests sur les différentes configurations de navigateurs (Chrome, Firefox, Safari, Android et iOS) utilisées au sein de votre organisation. Ne tirez aucune conclusion quant aux performances des codecs à partir d'un seul navigateur de bureau.

Qu'en est-il du partage d'écran avec une connexion lente ?

Le partage d'écran présente un compromis de qualité différent de celui de la vidéo. Le texte et les diapositives bénéficient d'une résolution lisible, tandis que des mouvements fluides nécessitent un nombre d'images par seconde plus élevé. Jitsi documente desktopSharingFrameRateet indique actuellement une valeur par défaut de { min: 5, max: 5 }5 ips. Pour une réunion comportant de nombreuses présentations, limiter le partage d'écran à environ 5 ips permet de préserver la lisibilité sans gaspiller de bande passante pour des mouvements inutiles.

Si les utilisateurs partagent des animations, des rotations CAO ou des clips vidéo, un taux de 5 images par seconde peut s'avérer trop lent. Dans ce cas, augmentez progressivement la fréquence d'images et observez si la résolution ou la perte de paquets se dégradent. La documentation officielle de configuration de Jitsi constitue la référence pour connaître les noms des options actuellement prises en charge.

Comment savoir si les changements ont réellement été utiles ?

Ne vous fiez pas uniquement à l'apparence de l'image. Vérifiez le comportement du réseau. L'API IFrame de Jitsi expose des fonctions getConnectionStats()permettant d'obtenir des informations sur la qualité de la connexion locale, la bande passante disponible, les débits de téléchargement et d'envoi, les débits audio et vidéo, la perte de paquets, les informations sur les codecs, la fréquence d'images, les images décodées, la résolution et les détails de transport. Consultez la documentation officielle de l'API IFrame .

Pour les déploiements embarqués, une vérification simple peut ressembler à ceci :

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

Effectuez le même test de réunion avant et après vos modifications. Un test pertinent comporte au moins trois conditions : bande passante normale au bureau, bande passante volontairement réduite et appel réaliste avec plusieurs participants. Notez si l’audio reste intelligible, si la vidéo se fige, si la perte de paquets augmente, si la résolution des participants diminue ou si l’utilisation du processeur devient excessive.

Vue illustrative des statistiques de connexion montrant le type de résolution, de fréquence d'images, de débit binaire et de valeurs de perte à comparer lors de la validation.

Par quel profil à faible bande passante devriez-vous commencer ?

Il s'agit de profils de départ, et non de valeurs optimales garanties. La configuration appropriée dépend de l'asymétrie entre les liaisons montante et descendante, du nombre de participants, du contenu des caméras, du codec choisi, du processeur du terminal et de la qualité attendue par les utilisateurs.

Où devez-vous modifier la configuration sur un serveur auto-hébergé ?

Lors d'une installation via un paquet Debian, Jitsi stocke généralement la configuration web de l'hôte virtuel dans le répertoire `/etc/ jitsi/web` /etc/jitsi/meet/<your-hostname>-config.js. La documentation d'authentification de Jitsi utilise ce chemin dans ses exemples. Dans les déploiements Docker, le guide officiel indique que config.jsles fichiers générés à l'intérieur du conteneur sont recréés au démarrage ; les paramètres personnalisés doivent donc être placés dans le fichier `/etc/jitsi/web` côté hôte CONFIG/web/custom-config.js. Consultez le guide officiel d'auto-hébergement Docker .

Avant toute modification, copiez la configuration existante, modifiez les paramètres un par un et vérifiez la syntaxe JavaScript. Évitez de coller un exemple complet config.jssur un déploiement fonctionnel, car les modèles en amont évoluent et peuvent inclure des valeurs spécifiques à chaque déploiement.

Quel est l'ordre d'accordage le plus sûr ?

1. Commencez par mesurer. Reproduisez le problème de faible bande passante avec un nombre réaliste de participants et notez la perte de paquets, le débit binaire, la résolution et la charge du processeur.
2. Capturez l'image à 360p avec la caméra. Testez cette fonction constraints.video.heightpour voir si la stabilité vidéo s'améliore.
3. Réduisez le nombre de flux reçus. Diminuez startLastN-le, si nécessaire, channelLastNafin que chaque participant ne télécharge pas de vignettes inutiles.
4. Préservez la lisibilité du partage d'écran. Limitez la fréquence d'images lors du partage d'écran pour les diapositives et les documents, sauf si le cas d'utilisation nécessite du mouvement.
5. Ajustez les limites de débit des codecs en dernier. Modifiez uniquement les profils de codecs réellement négociés par vos clients et comparez la qualité avant et après.
6. Effectuez un nouveau test en situation de forte affluence. Une configuration qui fonctionne correctement sur un réseau local peut échouer sur le Wi-Fi d'un hôtel ou via un point d'accès mobile.

Que faut-il éviter ?

Ne désactivez pas les fonctions de diffusion simultanée ou de retransmission simplement pour réduire la bande passante ; ces paramètres influent sur la manière dont Jitsi s’adapte et récupère en cas de perte, et leur modification peut engendrer de nouveaux problèmes. N’imposez pas la résolution 180p à tous les utilisateurs, sauf si le cas d’utilisation le justifie réellement. Ne considérez pas une limite de débit comme une réservation de bande passante. Enfin, n’optimisez pas uniquement la liaison serveur en négligeant la connexion finale à chaque point de terminaison.

La meilleure configuration Jitsi pour une faible bande passante n'est donc pas celle avec les valeurs les plus basses. C'est celle qui garantit un son fiable, une voix claire pour l'intervenant, limite le flux vidéo entrant inutile et laisse suffisamment de marge d'adaptation à l'encodeur. Commencez par une résolution de 360p, des valeurs LastN prudentes et les codecs par défaut de Jitsi ; n'augmentez les limites de débit que si vos mesures montrent que cela améliore la réunion au lieu de simplement dégrader la qualité d'image.