Jellyfinに必要な帯域幅は、同時に配信されるストリームのピークビットレートの合計に、プロトコルのオーバーヘッドと余裕を加えたものです。通常、より厳しい制限となるのはリモート接続時のアップロード帯域幅です。
ホームサーバーでは、ギガビットイーサネット経由で複数のローカルDirect Playセッションを処理できても、同じ構成をリモートで利用すると、すべてのストリームや家庭内のタスクでアップロード帯域幅を共有するため、処理しきれない場合があります。安全なマルチユーザー上限を見積もる際は、ストリームのビットレート、クライアントの画質設定、通信経路の方向、バースト挙動を分けて考えてください。
ファイルサイズではなく配信ビットレートから始める
複数のユーザーが、ソースサイズやコーデックの異なるファイルを視聴します。重要なのは、ネットワークが運ぶのはソースファイルのストレージサイズではなく、Direct Play、リマックス、またはトランスコードで配信されるビットレートだという関係です。
実際には、再生時間が似ている2つのファイルでも、エンコード時のビットレートと品質が異なるため、必要な帯域幅は大きく異なることがあります。そのため、記載された条件によって結果が変わります。配信ビットレート
注意すべき点は、平均値ではピークの多いシーンやセグメント単位のバーストが見えないことです。実際には、セッションごとの出力ビットレートと通信方向を記録してください。
プロトコルのオーバーヘッドとセグメントのバーストを加える
セッションごとのビットレートが分かっています。重要なのは、セグメント配信とネットワークプロトコルによってヘッダーが追加され、メディアの平均ビットレートを上回る短時間のバーストが発生するという関係です。
実際には、平均スループットを通過できるリンクでも、バーストがキューやアップロード帯域幅の余裕を超えるとバッファリングが発生することがあります。そのため、記載された条件によって結果が変わります。バースト需要
注意すべき点は、オーバーヘッドがプロトコル、クライアント、暗号化、セグメントサイズによって変わることです。限界に近い場合は、安全係数を使い、実際の通信経路を測定してください。
LANストリームとリモートストリームを分けて計算する
保守的な1ストリームあたりの需要は把握できます。重要なのは、ローカルセッションがLANとサーバーの送信帯域幅を消費する一方、リモートセッションではWANのアップロード帯域幅、プロキシ、VPN、場合によってはリレーの容量も消費するという関係です。
実際には、ローカル再生は問題なくても、アップロード帯域幅の上限に達するとリモートセッションでバッファリングが発生します。そのため、記載された条件によって結果が変わります。リモートアップロードの上限
注意すべき点は、ギガビットLANが20 Mbpsの上り回線を高速化するわけではないことです。実際には、ローカルの合計値とリモートアップロードの合計値を別々に計算してください。
最低限ではなく余裕を確保する
LANとリモートの合計値が計算できました。重要なのは、余裕によってビットレートのピーク、TCP/TLSのオーバーヘッド、バックグラウンド通信、測定誤差を吸収できるという関係です。
実際には、測定されたピーク需要が選択したリンク予算を下回っている間はストリームが安定しますが、キューが余裕を使い切るとバッファリングが始まります。そのため、記載された条件によって結果が変わります。同時スループットテスト
注意すべき点は、すべてのISP、VPN、クライアントに適用できる固定の割合はないことです。記録した余裕を確保し、同時再生で検証してください。
テック&AIハブ
もっと読む

ローカルAIゲートウェイは、GPUの割り当て前に厳格なコンテキスト上限を適用できますか?
ハードコンテキストゲートの仕組みを優先した説明、その共有リソースに関するトレードオフ、クエリファンアウトに関する3つのよくある質問、そして実践的な検証プロトコル。

ホームAIサーバーは、2.5GbE経由でリモートNASのモデル重みをメモリマップできますか?
リモートNASモデルのメモリマッピングに関するメカニズム重視の説明、共有リソースのトレードオフ、クエリのファンアウトに関する3つのFAQ、そして実践的な検証手順。

複数のコンテナで1つの内蔵GPUを共有しても、ワークロードが漏洩することはない?
共有iGPUコンテナ分離のメカニズムを第一にした説明、共有リソースのトレードオフ、クエリファンアウトに関する3つのFAQ、そして実践的な検証手順。

