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

バックアップの頻度は Jellyfin のリカバリーポイントの品質にどのような影響を与えますか?
バックアップ間隔を短くするとJellyfinの状態喪失を抑えられますが、復旧ポイントの品質は、一貫性のある取得、保持履歴、復元テストにも左右されます。

安全なJellyfinアップグレードの境界とは何か、なぜ重要なのか?
安全な Jellyfin のアップグレードでは、イメージを元に戻してもスキーマ、データ、プラグインの変更は元に戻らないため、ランタイムと永続状態を復旧可能な形で連携させておきます。

Jellyfinはデバイス間の変更をどのように検出し、整合させるのか?
デバイス間でJellyfinの状態を一貫させる仕組みはサーバー中心です。サーバーが変更を検出または受け取り、状態を確定して保存し、クライアントはその共有された正本から更新します。

