低帯域幅向けにJitsi Meetの解像度とビットレートを最適化する方法

低帯域幅のJitsi Meet環境で最初に変更すべき点は何ですか？

まず、カメラのキャプチャ解像度を下げ、各クライアントが受信するリモートビデオの数を減らし、最後にコーデック固有のビットレート制限を厳しくするという、3つの設定を順番に行ってください。この順番が重要なのは、解像度と受信ストリームの数が帯域幅の消費に最も明確な影響を与える一方、ビットレート制限を厳しく設定すると、パケットロスやWi-Fiの不安定性を解決することなく、動きがぼやけて見える可能性があるためです。

Jitsi は、現在の構成リファレンスでクライアント側のビデオ制御について説明しています。2026 年 10 月 6 日現在、このドキュメントによると、constraintsオブジェクトのデフォルトのキャプチャ高さは理想的な 720p であり、channelLastNデフォルトでは無制限で-1、startLastNユーザーが [ビデオ品質の管理] 設定を変更する前に、受信ビデオの数が少なくても会議を開始できます。

制約のある支店、モバイルホットスポット、地方のリンク、または過負荷状態の Wi-Fi ネットワークの場合、実用的な開始目標は 720p ではなく 360p であることが多いです。Jitsi のインフラストラクチャ要件ページには、180p で約 200 kbit/s、360p で 500 kbit/s、720p で 2.5 Mbit/s という大まかな計画数値が記載されていますが、実際の要件は多くの要因によって変動するとも警告しています。これらの数値は、ユーザーごとの保証されたレートではなく、容量計画の参考値として扱ってください。Jitsi Meet の公式要件ガイドを参照してください。

接続環境が限られている場合の360p画質オプションを示す会議画面の例です。実際のコントロールレイアウトは、Jitsi Meetのビルドによって異なる場合があります。

解像度をビットレートより先に制限すべきでしょうか？

通常はそうです。キャプチャ高さを下げると、ビットレート割り当てが始まる前にエンコーダが処理しなければならないピクセル数が減ります。Jitsiの現在の設定リファレンスでは、W3Cビデオconstraintsと以前の推奨resolution値を区別し、制約のデフォルト設定は理想的な720pのキャプチャ高さであると述べています。

動画の安定性が顔の細かい描写よりも重要なサイトの場合は、次のような360pキャプチャの上限をテストしてください。

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

これはJitsiのデフォルト設定ではなく、あくまでもサンプルプロファイルです。ブラウザに対し、360pを優先し、それを超えないように指示する一方で、必要に応じてキャプチャパスを180pまで下げることも許可します。ただし、min: 180深刻な混雑状況下でも安定した180pストリームが保証されるとは限りません。WebRTCは、利用可能な帯域幅、CPU負荷、パケット損失、デバイスの性能、コーデックの動作などに応じて変化する可能性があるため、ご注意ください。

360pのキャプチャ上限と保守的なLastN値を使用した、自己ホスト型Jitsi構成の例。

各参加者はいくつの遠隔ビデオストリームを受信すべきでしょうか？

参加者が一度に8つのリモートビデオを受信する場合、ローカルカメラの解像度を下げるだけではダウンロード側の問題全体を解決できません。Jitsiは、参加者に転送されるリモートビデオストリームの数を具体的に制御するためのLastNコントロールを提供しています。

ドキュメントに記載されているchannelLastNデフォルト値は で-1、これは無制限を意味します。ドキュメントに記載されているstartLastNオプションを使用すると、会議をLastNのより小さい値で開始できます。Jitsiは、channelLastNユーザーが「ビデオ品質の管理」スライダーで品質レベルを変更するときに が使用されることを指摘しています。

帯域幅が制限された環境における慎重な出発点としては、次の点が挙げられます。

channelLastN: 2,
startLastN: 1,

この例では、参加者は最初に1つのリモートビデオを受信し、アプリケーションの品質動作に応じて最大2つのリモートビデオを受信する状態に移行できます。 と を2普遍的な1推奨事項として扱わないでください。学生が主に1人のプレゼンターを視聴する教室では、全員が画面に表示される必要がある4人による設計レビューよりも小さなLastNを使用できます。

Jitsiは現在、どのビットレート値を使用していますか？

Jitsi の現在のconfig.jsテンプレートと設定リファレンスでは、コーデック固有のmaxBitratesVideoレベルが明示されています。2026 年 10 月 6 日時点のプロジェクトマスター設定では、AV1 は低レベルに 100,000 ビット/秒、標準レベルに 300,000 ビット/秒、高レベルに 1,000,000 ビット/秒を使用しています。VP9 は 100,000、300,000、1,200,000 ビット/秒を使用しています。VP8 と H.264 は、同じレベルで 200,000、500,000、1,500,000 ビット/秒を使用しています。実際のテンプレートは、Jitsi Meet の公式 GitHub リポジトリで確認できます。

これらの値は、上流のデフォルト値またはテンプレート値であり、すべての通話が必ずしもこれらのレートで送信されることを保証するものではありません。WebRTCの帯域幅推定、輻輳制御、選択されたコーデック、サイマルキャストまたはスケーラブルな符号化動作、シーンの複雑さ、フレームレート、および受信側の制約など、すべてが実際に送信されるデータに影響を与えます。

上限を引き下げるのが妥当なのはどのような場合でしょうか？

ネットワーク予算が既知で、ディテールよりも安定したビデオが重要な場合は、上限値を下げてください。たとえば、次のようなVP8プロファイルをテストできます。

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

これらの数値は、Jitsiのデフォルト値ではなく、テスト用の例として意図的に記載されています。これらの数値は、対象となるエンドポイントで実際にVP8がネゴシエートされている場合にのみ意味を持ちます。デスクトップクライアントがAV1またはVP9を優先する場合、VP8オブジェクトのみを調整しても期待どおりの効果は得られません。

制約のあるネットワーク環境におけるVP8ビットレート制限の例です。展開前に、ご自身のデバイスと通話パターンでテストしてください。

帯域幅を節約するために、特定のコーデックを強制的に使用すべきでしょうか？

自動的にはそうはなりません。最新のJitsiビルドでは、AV1、VP9、VP8、H.264のコーデックの優先順位とデフォルトのビットレート設定が異なります。AV1とVP9は効率的ですが、コーデックの選択はCPUコスト、デバイスサポート、ブラウザサポート、スケーラビリティ機能にも影響します。より複雑なコーデックのエンコードに苦労する低性能のノートパソコンでは、理論上は効率的なコーデックであっても、会議のパフォーマンスが低下する可能性があります。

より安全な運用ルールとしては、問題を示す測定結果がない限り、Jitsiの現在のコーデック優先順位設定を維持することです。コーデックの順序を変更する場合は、組織で実際に使用されているChrome、Firefox、Safari、Android、iOSの組み合わせでテストしてください。単一のデスクトップブラウザからコーデックのパフォーマンスを推測しないでください。

低速回線での画面共有はどうでしょうか？

画面共有は、カメラ映像とは異なる品質上のトレードオフがあります。テキストやスライドは読みやすい解像度で表示できますが、滑らかな動きにはより多くのフレームレートが必要です。JitsiのドキュメントにはdesktopSharingFrameRate、デフォルト値として が記載されています{ min: 5, max: 5 }。プレゼンテーションが多い会議では、画面共有を5fps程度に設定することで、不要な動きに帯域幅を浪費することなく、読みやすさを維持できます。

ユーザーがアニメーション、CAD回転、またはビデオクリップを共有する場合、5 fpsでは遅く感じられるかもしれません。その場合は、フレームレートを慎重に上げて、解像度やパケットロスが劣化しないか確認してください。現在サポートされているオプション名については、Jitsiの公式設定ドキュメントを参照してください。

変更が実際に効果があったかどうかは、どうすればわかるのでしょうか？

画像が「問題なさそう」かどうかだけで判断しないでください。ネットワークの動作を確認してください。Jitsi の IFrame API はgetConnectionStats()、ローカル接続品質、利用可能な帯域幅、アップロードおよびダウンロードのビットレート、オーディオおよびビデオのビットレート、パケット損失、コーデック情報、フレームレート、デコードされたフレーム、解像度、およびトランスポートの詳細を返す機能を提供します。公式の IFrame API 関数リファレンスを参照してください。

組み込み環境への展開の場合、簡単なチェックは次のようになります。

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

変更前と変更後で、同じ会議パターンを実行してください。効果的なテストには、少なくとも次の3つの条件が必要です。通常のオフィス帯域幅、意図的に制限された帯域幅、そして現実的な複数参加者による通話です。音声が聞き取りやすいか、ビデオがフリーズするか、パケットロスが増加するか、参加者の解像度が低下するか、CPU使用率が過剰になるかを記録してください。

検証時に比較する解像度、フレームレート、ビットレート、および損失値の種類を示す、接続統計情報の例示的なビュー。

どの低帯域幅プロファイルから始めるべきでしょうか？

これらは初期プロファイルであり、最適な値を保証するものではありません。最適な設定は、アップリンクとダウンリンクの非対称性、参加者数、カメラコンテンツ、選択したコーデック、エンドポイントCPU、およびユーザーが期待する品質によって異なります。

自己ホスト型サーバーの設定はどこで編集すればよいですか？

Debianパッケージでのインストールでは、Jitsiは通常、仮想ホストのWeb設定を に保存します/etc/jitsi/meet/<your-hostname>-config.js。Jitsiの認証に関するドキュメントでも、例としてこのパスが使用されています。Dockerデプロイメントでは、公式のDockerガイドによると、config.jsコンテナ内で生成されたファイルは起動時に再作成されるため、カスタム設定はホスト側のCONFIG/web/custom-config.jsファイルに記述する必要があります。公式のDockerセルフホスティングガイドを参照してください。

編集する前に、既存の設定をコピーし、パラメータのグループを1つずつ変更し、JavaScript構文を検証してください。config.js上流のテンプレートは進化し、デプロイメント固有の値が含まれる可能性があるため、動作中のデプロイメントにサンプル全体を貼り付けることは避けてください。

最も安全なチューニング順序は何ですか？

1. まず測定を行いましょう。現実的な参加者数で低帯域幅の問題を再現し、パケット損失、ビットレート、解像度、CPU負荷を記録してください。
2. カメラの撮影解像度を360pに制限してください。使用してconstraints.video.height、ビデオの安定性が向上するかどうかをテストしてください。
3. 受信ストリームを削減します。startLastN必要に応じて、channelLastN各参加者が不要なサムネイルをダウンロードしないように、レベルを下げます。
4. 画面共有の読みやすさを維持してください。スライドやドキュメントの画面共有フレームレートは、動きが必要な場合を除き、低く保ってください。
5. コーデックのビットレート制限は最後に調整してください。クライアントが実際にネゴシエートするコーデックプロファイルのみを変更し、変更前後の画質を比較してください。
6. 混雑状況下で再テストしてください。LAN上では問題なく動作する設定でも、ホテルのWi-Fiやモバイルホットスポットでは動作しない場合があります。

避けるべきことは何ですか？

帯域幅を削減しようとしているという理由だけで、同時送信機能や再送信機能を無効にしないでください。これらの制御は、Jitsi が損失から適応し回復する方法に影響するため、変更すると新たな障害モードが発生する可能性があります。ユースケースが本当に許容する場合を除き、すべてのユーザーに対して 180p を強制しないでください。ビットレートの上限を帯域幅の予約として扱わないでください。また、各エンドポイントのラストマイル接続を無視して、サーバーリンクのみを最適化しないでください。

したがって、低帯域幅のJitsiに最適な設定は、数値が最小のものではありません。音声の安定性を維持し、発言者を明瞭に表示し、不要なビデオ入力を制限しつつ、エンコーダーが適応できる十分な余裕を持たせる設定です。まずは360p、控えめなLastN値、Jitsiの現在のコーデックのデフォルト設定から始め、ビットレート制限を厳しくすることで、単に画質が低下するのではなく、会議が改善されることが測定結果で示された場合にのみ、厳しく設定してください。