字幕付きのJellyfinおよびHDR再生に適したホームサーバーのサイズの決め方

エヴァ・ウォン

IceWhale author

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

How to Size a Home Server for Jellyfin and HDR Playback With Subtitles - Zima Store Online

HDRと字幕に対応するJellyfinサーバーの規模は、Direct Play、トーンマッピング、または焼き付けを引き起こす、実際のクライアント・ファイル・字幕の組み合わせをテストして決めます。

対応クライアントが元の映像、音声、コンテナ、字幕形式をそのまま受け入れられる場合、HDR再生によるサーバー負荷は軽微です。一方、別の画面では同じファイルが高負荷な変換処理になることがあります。小規模な負荷マトリクスを作成し、避けられない映像処理にはハードウェアアクセラレーションを割り当て、フィルタリングやフォールバック処理のためにCPUの余力を確保します。RAMを増設したり、GPUを追加したり、演算処理とストレージを分離したりする前に、家庭内で最も厳しいケースを検証しましょう。

クライアント、HDR形式、字幕タイプからサイジングマトリクスを作成する

重要な画面を一覧にします。メインのHDRテレビ、SDRテレビやプロジェクター、ブラウザ、スマートフォン、タブレット、リモートクライアントなどです。それぞれについて、字幕なし、単純なテキスト字幕、ライブラリに実際に存在する画像ベースまたはスタイル付き字幕を含む、代表的な4K HEVC HDRファイルをテストします。

デバイスの横に「4K対応」と書くのではなく、実際の再生経路を記録します。同じクライアントでも、あるHDRタイトルはDirect Playし、別のタイトルはコンテナや音声の都合でリマックスし、字幕をローカルで描画できない場合は映像変換が必要になることがあります。この経路がサーバーのサイジング基準になります。

実際に保存しているビットレートとフレームレートでテストしてください。短いデモクリップでは、高ビットレートの長編映画、特殊な字幕トラック、リモート再生時の品質制限でも同じ経路になることは証明できません。

ネイティブHDR再生とHDRからSDRへの変換を分けて考える

HDR対応クライアントがソースをそのまま受け入れられる場合、サーバーは主にデータを転送するだけなので、必要な演算能力は控えめです。出力先がSDRや互換性のない別形式を必要とし、サーバーが映像をデコードし、色と明るさを変換して、新しい映像ストリームをエンコードしなければならない場合に負荷が高くなります。

避けられない変換には、ダッシュボードの設定を有効にしただけでGPUが使われていると判断せず、実際のホスト上でハードウェアアクセラレーションによるJellyfinトランスコーディングを設定して検証します。ハードウェアのメディアエンジンによって一般CPUの処理量を大幅に減らせますが、完全な処理経路はコーデック、ドライバー、フィルター、権限、クライアントからの要求にも左右されます。

ライブラリ内のすべてのHDRファイルではなく、本当に必要な変換に合わせてサイジングします。リモートのSDRデバイス1台だけがトーンマッピングを必要とするなら、検証済みの高負荷経路1本が基準になります。家庭内の2人のユーザーが同時にその経路を実行する可能性があるなら、サーバーが十分だと判断する前に、2本同時でテストしてください。

字幕の焼き付けを別のサイジング要因として扱う

字幕はサーバーの予算内で小さな装飾要素として扱えるものではありません。クライアントが描画できるテキストトラックならDirect Playを維持できますが、画像ベースの字幕や互換性のない字幕では、サーバーがすべての映像フレームに字幕を描画する必要があり、低負荷のセッションがフルの映像処理パイプラインに変わることがあります。

字幕によるトランスコーディングについての別ガイドでは、クライアントが直接描画できない場合に、PGSやVobSubがJellyfinを焼き付け処理へ移行させる代表的なケースとして挙げられています。コンテンツに適している場合はテキストベースのSRTを用意しつつ、品質やスタイルが重要なら元の字幕トラックも保持し、焼き付けが必要なクライアントを基準にサーバーをサイジングします。

字幕は同じHDRファイルでテストしてください。2つの要件が重なる可能性があるためです。1つのリクエストで、デコード、字幕描画、HDRからSDRへのトーンマッピング、スケーリング、エンコードが必要になる場合があります。「4K」だけではなく、この複合経路こそが、性能不足または一部しかアクセラレーションされていない構成を最も露呈しやすいシナリオです。

Featured

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

ZimaCube2

CPU、メディアエンジン、メモリを異なる役割として割り当てる

プラットフォームが対応している場合は、対応するデコード、フィルタリング、トーンマッピング、エンコードの各段階にハードウェア映像エンジンを使用します。Jellyfin本体、音声変換、ソフトウェアにフォールバックする字幕関連処理、データベース処理、ホスト上で共有されるその他のサービスのために、CPUの処理能力を確保してください。

HDR再生では通常、メモリが最初のボトルネックになることはないため、32GBを映像品質の向上と考えないでください。負荷の大半がDirect Playであれば、Jellyfin中心のホストは控えめな構成でも運用できます。ほかのコンテナ、仮想マシン、大容量キャッシュ、同時実行されるバックグラウンドサービスによって実測上の負荷が高まった場合に、メモリを増設します。

サイジングの停止条件は、対象パイプライン実行時のリソース動作です。GPUや映像エンジンに余力があり、フォールバック処理によってCPUが張り付かず、メモリスワップも発生せず、再生バッファに余裕が保たれているなら、テスト済みのストリームの改善にコア数やRAMを増やしても効果はありません。

アプリデータを高速に保ち、トランスコード用の一時領域に十分なスループットを確保する

Jellyfinの設定、データベース、メタデータ、キャッシュは、低レイテンシのソリッドステートストレージに配置します。映画やエピソード本体は、元のビットレートを安定して読み出せる容量重視のストレージに保管し、長時間のセッション中にシステムディスクが満杯にならない経路にトランスコード用の作業領域を配置します。

メディアが別のNASにある場合は、演算処理とストレージ間のリンクもテストに含めます。高負荷のトランスコードでは、その経路を通じて元のソースを読み出してから新しい出力をクライアントへ送信します。同時にバックアップやファイル転送が同じリンクを使用している可能性もあります。

再生に問題がある場合は、字幕やHDR変換によるJellyfinのバッファリングを診断する方法で説明されているのと同じ、段階ごとの切り分けを行います。まずDirect Playかトランスコードかを確認し、次に字幕、トーンマッピング、ハードウェアアクセラレーション、ストレージ、ネットワークの動作を個別に切り分けます。アクティブなボトルネックを特定する前に、より高性能な演算リソースを購入してはいけません。

最悪条件のストリームを1本検証してから、同時実行数を慎重に増やす

最も負荷の高いHDRソース、焼き付けが必要になる可能性が最も高い字幕形式、実際にサポートする中で最も性能の低いクライアントを含む、再現可能な検証セットを作成します。まず1セッションで開始し、再生状態、CPU使用率、GPUや映像エンジンの使用率、トランスコード速度またはバッファ状態、メモリ、温度を記録します。

1つの経路が安定してから、家庭内で実際に発生する重複を表す2人目の同時ユーザーやバックグラウンドタスクを追加します。目的は普遍的なストリーム数を見つけることではありません。特定の処理段階を使い切ることなく、実際のメディア、クライアント、ハードウェアが維持できる同時実行数を見極めることです。

想定される中で最も負荷の高い組み合わせが、余力を残して繰り返し正常に動作した時点で、サイジングを止めます。実測された障害の原因が明確になった場合にのみ、ハードウェアを追加または変更します。コーデック経路の不足には別のメディアエンジン、ソフトウェアへの継続的なフォールバックにはより高性能なCPUまたは優れたアクセラレーション、ストレージ競合には構成の変更が必要です。高い同時実行負荷を共存させられない場合は、専用のトランスコードノードが適しています。