小型ホームサーバーでリモート4Kストリーミング向けにPlexを最適化する方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Tune Plex for Remote 4K Streaming on a Small Home Server

小規模なホームサーバーでPlexのリモート4K再生を最適化するなら、サーバーですべての不一致を力ずくで処理するのではなく、一般的なストリームをスムーズに再生できるようにするのが基本です。まず既知のリモートクライアントから始め、クライアントと経路が維持できる場合はDirect Playを優先し、変換が本当に必要な場合だけトランスコードを使います。

「4Kのバッファリング」には、いくつもの異なる制約が隠れている可能性があるため、基準となる状態が重要です。高ビットレートのファイルが実際のアップロード経路の容量を超えている場合もあれば、クライアントの画質設定が変換を要求している場合、字幕や音声によって互換性が変わる場合、避けられないトランスコードが小規模なCPUに過大な負荷をかけている場合もあります。一度に1つの層だけを調整し、同じリモートテストで改善が確認できた変更だけを維持してください。

1つのリモート4K基準から始める

実際にリモートでストリーミングするファイルの中でも高負荷なものを代表する4Kファイルを1つと、繰り返しテストできるクライアントを1つ選びます。ホームネットワークの外部から再生を開始し、PlexがDirect Play、Direct Stream、Transcodeのどれを報告しているか、選択された画質、ファイルのビットレートを記録します。

有用な4K基準を作ることで、メディア経路の問題とサーバーサイズの問題を切り分けられます。詳細な4K再生経路は、クライアントの互換性、ネットワーク容量、Plexがトランスコードする必要があるかどうかに左右されます。そのため、同じ小規模サーバーでも、あるセッションでは余裕で動作し、別のセッションでは負荷が高くなることがあります。

速度テストの数値だけを基準に調整しないでください。このセクションの合格条件は、再生モード、リモート経路、ファイルのビットレート、サーバー負荷を確認できる再現可能なセッションです。症状を再現できない場合は、現在の設定を維持し、ほかを変更する前にテスト方法を整えてください。

まずDirect Playを目標にする

小規模なサーバーでは、Direct Playが正常に再生できる最も低コストな経路です。Plexが映像をデコードして再エンコードするのではなく、保存されているメディアをそのまま送信するためです。リモートクライアントが、基準ファイルで使用されている映像コーデック、音声トラック、コンテナ、HDRの動作、字幕モードに対応しているか確認してください。

クライアントでは、初期設定がソースファイルを要求すると決めつけず、「インターネットストリーミング」、「リモート画質」、「オリジナル」、「最大」などの名前の設定を確認します。経路に十分な帯域幅がある場合、リモート画質を上げることで、不要な低画質リクエストをなくせます。その結果、本来クライアントで再生できるファイルを小規模なサーバーがトランスコードしてしまう事態を防げる場合があります。

クライアントの画質設定だけを変更して、同じファイルを再度テストします。セッションがDirect Playに切り替わり、安定した場合は、そのクライアント設定を維持してください。それでもトランスコードされる場合は、必要に応じて基準の画質に戻し、メディアを変換したりハードウェアを購入したりする前に、Plexが示す理由を確認します。

実際のアップロード経路からリモート画質を設定する

リモート4K再生では、サーバーからの実際のアップロード経路と、クライアント側の受信経路の両方に収まる必要があります。テスト中の持続的なスループットとメディアのビットレートを比較し、これまでに確認した最高速度と同じ値を上限に設定するのではなく、バーストや家庭内のほかの通信のための余裕を残してください。

遅延や経路品質は、単純な帯域幅とは別に考えてください。リモートストリーミングの調査事例では、サーバーがリアルタイムより速くトランスコードできる場合でも、遅延と変動によってトラブルシューティングの方向が変わりました。そのため、Plexの画質設定をさらに変更するより、リモート経路を改善するほうが重要になる場合があります。

Direct Playがリモート経路でのみバッファリングし、ローカル再生が正常な場合は、リモートの目標画質を1段階下げるか、ネットワーク経路を改善して再テストします。画質を下げた結果、小規模なサーバーでは維持できないトランスコードが発生する場合は、ビットレートを闇雲に下げ続けるのではなく、次のセクションが制限要因になります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

クライアントが必要とする場合だけハードウェアトランスコードを使う

リモートクライアントがソース形式に対応していない場合や、経路がソースをそのまま送信できない場合、トランスコードは有効な代替手段です。調整の目的は、すべてのセッションをトランスコーダーに通すことではなく、変換を予測可能かつ効率的にすることです。

対応するIntelシステムでは、Quick Syncによって、対応するエンコードおよびデコード処理を一般的なCPUコアから移せます。機能が動作していると決めつける前に、意図的にトランスコードを実行し、アクティブなセッションに表示されるハードウェアマーカーでハードウェアアクセラレーションを確認してください。

同じリモートトランスコードが再生に先行し続け、CPUを限界まで占有しない場合だけ、その調整を維持します。ハードウェアアクセラレーションを利用できない場合や、トランスコードが再生に追いつかない場合は、すでに限界に達しているハードウェアでトランスコード品質を上げるのではなく、互換性のある事前エンコード版か、より低いリモート目標画質を選んでください。

バックグラウンド処理が再生と競合しないようにする

小規模なサーバーでは、リモート4Kセッション中に、ライブラリスキャン、サムネイル生成、バックアップ、パリティ処理、ダウンロード、その他のコンテナに割ける余力が少なくなります。視聴時間帯を避けて負荷の高い処理をスケジュールするか、再生テストにCPU、ストレージ、ネットワークのリソースを十分に割り当てられるよう制限してください。

リモート視聴中の多くの時間をサーバーがトランスコードに費やしている場合、ハードウェアアクセラレーション対応ストリーミングに関するZimaSpaceのワークフローは、メディアライブラリ自体を変更せずにアクセラレーション経路を確認する次の手順として適しています。

バックグラウンド負荷を一時停止した状態で再テストし、その後、意図的に再開します。ジョブを停止したときだけ再生が安定する場合は、競合するジョブのスケジュールを変更するか、制限してください。再生に変化がない場合は通常のスケジュールに戻し、無関係なバックグラウンドタスクを原因と考えないようにします。

調整を終える前に実際のリモート経路で再テストする

元の制約を回避してしまうローカルブラウザではなく、実際のリモートクライアントで仕上げのテストを行います。基準ファイルに加えて、音声や字幕が異なる別の4Kタイトルもテストし、再生モード、起動時間、サーバーのCPU負荷、バッファリングが再発するかどうかを記録します。

調整が成功した状態には明確な定義があります。クライアントと経路が対応している一般的なリモート4KファイルはDirect Playで再生され、避けられないトランスコードは意図したアクセラレーション経路を使用し、サーバーには残りのホームサーバー処理に十分な余裕があることです。ほかのすべてのタイトルが別の分岐に入るなら、1つのファイルがスムーズに再生できただけでは不十分です。

アップロード容量不足、互換性のないクライアント、ハードウェアが維持できないトランスコードなど、残った問題が明確な限界であると特定できたら、調整を止めます。その時点で無関係なPlex設定をさらに変更すると不確実性が増すだけです。制約となっているクライアント、メディアのバージョン、ネットワーク経路、またはハードウェア層を変更してください。