はい、2.5GbEは通常、複数の4Kダイレクト再生ストリームを伝送できます。ただし、それらの合計ピークビットレートが、最も遅い安定した経路の帯域幅を下回っている必要があります。
ダイレクト再生では動画のエンコードを回避できますが、ネットワーク、ストレージ、コンテナ、スイッチ、クライアントの制限がなくなるわけではありません。ホームメディアサーバーは、すべてのソースを十分な速度で読み取り、実際にネゴシエートされたリンクを通じてすべてのセッションを送信し、プレーヤーのバッファーを使い果たさずにビットレートの急増にも対応する必要があります。したがって、答えは固定されたストリーム数ではなく、代表的なファイルと完全な経路上で最も弱いデバイスを基準に測定した同時再生数の上限です。
すべてのテストセッションが本当にダイレクト再生であることを確認する
使用する各クライアントで代表的な4Kタイトルを1本ずつ再生し、メディアサーバーのダッシュボードを確認します。動画、音声、字幕が「ダイレクト再生」「ダイレクトストリーム」「トランスコード」のどれで処理されているか、表示された理由と現在のビットレートとともに記録してください。
「4Kストリーミング」に見えるセッションでも、音声の変換、コンテナの再多重化、字幕の動画への焼き込みが行われている場合があります。Jellyfin Android TVの報告では、クライアントのビットレート設定を変更したことで、大容量ファイルがダイレクトストリーミングまたはトランスコードのどちらになるかが変化した例が示されています。
サーバーが動画をエンコードしている場合、そのセッションをダイレクト再生のネットワークテストに含めないでください。まず互換性のある音声と字幕を選び、クライアントをオリジナル画質に設定し、シークや再開後もダッシュボードが意図した経路のままであることを確認します。
ファイルサイズだけでなくピークビットレートを測定する
各ファイルの再生時間、平均ビットレート、再生中に観測されたピーク値を記録します。ファイルサイズを再生時間で割ると平均値は求められますが、アクションシーン、ロスレス音声、高精細な映像シーケンスでは、一時的に必要な帯域幅が大幅に増えることがあります。
高ビットレートの4Kタイトルでは、平均値が低くても100Mbpsを超えるバーストが発生することがあります。Plexコミュニティのトラブルシューティングガイドでは、4Kのビットレートバーストが100Mbpsを超える可能性が説明されています。そのため、2.5GbEのサーバーリンクが混雑する前に、テレビの100Mbps Ethernetポートが限界に達することがあります。
テスト対象には、圧縮されたデモ用クリップを1本だけ選ぶのではなく、実際に視聴されるファイルの中で最も高ビットレートのものを含めてください。各タイトルを最もデータ密度の高いシーンまで再生し、クライアントのバッファーが消費または補充されるまで十分な時間、安定したネットワーク使用量を記録します。
ストリームを合算し、十分な余裕を持たせる
同時再生するすべてのストリームについて、測定したピークビットレートまたは高パーセンタイルのビットレートを合計し、初期需要を見積もります。音声、プロトコルのオーバーヘッド、ライブラリの閲覧、字幕の配信、同じサーバーインターフェースを共有するその他の通信も加算してください。
2.5GbEリンクは2,500Mbpsを公称しますが、アプリケーションを継続的にその数値近くで動作させる設計にはしないでください。EthernetとTCPのオーバーヘッド、ビットレートの変動、再送、ストレージの遅延、既存のピーク中に別のユーザーが再生を開始する状況に備えて、余裕を確保します。
たとえば、ピークが約100Mbpsのセッションが10本ある場合、オーバーヘッドやその他の通信を含める前で、およそ1,000Mbpsになります。この合計値は健全な2.5GbEサーバーリンクの範囲内ですが、個々のクライアントが100Mbpsに制限されている場合、同じソースでバッファリングが発生する可能性があります。
| ストリームあたりの測定ピーク | 4ストリーム | 8ストリーム | 次に確認する項目 |
|---|---|---|---|
| 50Mbps | 200Mbps | 400Mbps | クライアントのリンクとストレージの遅延 |
| 100Mbps | 400Mbps | 800Mbps | 100MbpsのテレビポートとWi-Fiの安定性 |
| 150Mbps | 600Mbps | 1,200Mbps | スイッチのアップリンク、ディスク、継続的な余裕 |
これらは計画用の例であり、ストリーム数を保証するものではありません。ライブラリから実際のピーク値を取得し、バッファリング、再送、ストレージ待ち、リンクの飽和が始まった時点で同時再生数の増加を止めてください。
サーバーとクライアント間のすべてのネゴシエート済みリンクを確認する
メディアサーバー、スイッチポート、アップリンク、アクセスポイント、クライアントアダプター、テレビのインターフェースを確認します。サーバーが2.5GbEでネゴシエートしていても、スイッチのアップリンクが1GbEで動作していたり、テレビのEthernetポートが100Mbpsに制限されていたりする場合があります。
4K再生では、クライアントの制限が頻繁にボトルネックになります。Plexのトラブルシューティング事例では、高ビットレートの4K再生が、サーバーのファイル読み取り能力ではなく、クライアントのネットワーク経路によって制限されていました。
ポートの表示名だけに頼らず、ネゴシエートされた速度とエラーカウンターを確認してください。サーバーインターフェースが期待されるリンクモードに達しない場合は、2.5GbEポートが1GbEでネゴシエートされる場合についてのZimaSpaceガイドを次の確認項目にしてください。
ストレージが合計読み取り量を供給できるかテストする
同じ同時再生テストを実行しながら、ディスクスループット、キューの深さ、遅延、キャッシュの動作、ファイルシステムエラーを監視します。ダイレクト再生は主にシーケンシャル処理ですが、異なるディスク領域にある複数のファイルを読み取ると、競合する読み取りが発生することがあります。
通常、数本のストリームであればストレージには十分なシーケンシャル帯域幅があります。しかし、劣化したアレイ、実行中のスクラブ処理、SMRドライブ、リモートマウント、同時実行されるサムネイル生成などによって遅延が発生し、ネットワークグラフには現れない場合があります。2.5GbEリンクが飽和していないのにバッファリングが起きる場合は、この症状が疑われます。
メディアを十分に高速なローカルSSDにコピーして、テストを繰り返します。クライアントやネットワーク経路を変更せずに再生が安定するなら、Ethernetを再びアップグレードするのではなく、ライブラリのストレージ、マウント、アレイの負荷を調査してください。
サーバーの容量とクライアント固有の障害を切り分ける
1台のテレビだけがバッファリングし、ノートパソコンやストリーミングボックスが安定している場合は、正常なセッションを維持したまま、問題のクライアントだけを別の有線デバイスに置き換えます。これにより、サーバー全体の経路が一杯なのか、それとも1つのエンドポイントがストリームを維持できないのかを判断できます。
120Mbpsのダイレクト再生ファイルは、ギガビットLAN上であっても、コーデックやクライアントの動作が経路の一部であるため、特定のプレーヤーで再生に失敗することがあります。Jellyfinの事例では、ローカルストレージとギガビットネットワークを使用していても、高ビットレートのクライアント再生に失敗した例が記録されています。
デバイス、ファイル、音声トラック、字幕トラック、接続方式ごとに障害を記録してください。1台の制限されたクライアントを交換した後に同じ合計負荷で再生が成功するなら、サーバー全体の画質を下げたり、2.5GbEが不十分だと判断したりしないでください。
段階的な負荷テストで実際の同時再生数の上限を見つける
まず高ビットレートのタイトルを1本再生し、次にセッションを1本ずつ追加します。それぞれ開始時刻をずらして、ピークが予測不能な形で重なるようにしてください。サーバーの送信速度、スイッチの使用率、再送、ストレージ遅延、CPU使用率、クライアントのバッファーイベントを監視します。
サーバーを再起動した後と、ライブラリスキャンなど通常のバックグラウンドタスクを1つ実行している状態でテストを繰り返します。ZimaSpaceのホームメディアサーバー検証手順では、セットアップ完了と判断する前に、複数の実際のクライアントで再生をテストすべき理由が説明されています。
意図した数のダイレクト再生セッションがピークシーンでも安定したバッファーと十分な余裕を維持できるなら、2.5GbEで十分です。クライアントのポート、スイッチのアップリンク、ストレージ、意図しないトランスコードを除外した後も、測定上サーバーリンクがボトルネックになっている場合にのみ、アップグレードまたは通信の分離を検討してください。
サポートとヒント
もっと読む

Plexは別のDockerコンテナとGPUを共有できますか?
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。

Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。

Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。

