Jellyfinで字幕付きHDR再生を楽しむためのホームサーバーの選び方

トーンマッピングや字幕の焼き付けが発生するクライアント、ファイル、字幕の組み合わせを実際にテストし、HDRと字幕に対応するJellyfinサーバーの性能を見積もりましょう。

対応クライアントが元の動画、音声、コンテナ、字幕の再生経路を受け入れる場合、HDR再生でサーバーにかかる負荷は軽くなります。同じファイルでも、別の画面では負荷の高い変換が必要になることがあります。小規模な負荷マトリクスを作り、避けられない動画処理にはハードウェアアクセラレーションを使い、フィルタリングやフォールバック処理に備えてCPUの余力を確保し、RAMの増設、GPUの追加、演算処理とストレージの分離を行う前に、家庭内で最も負荷の高いケースを検証してください。

クライアント、HDR形式、字幕の種類を基にサイジングマトリクスを作成する

重要な画面をリストアップしてください。メインのHDRテレビ、SDRテレビやプロジェクター、ブラウザー、スマートフォン、タブレット、リモートクライアントなどです。それぞれで、代表的な4K HEVC HDRファイルを使い、字幕なし、シンプルなテキスト字幕、ライブラリーに実際にある画像ベースまたは装飾付きの字幕形式をテストしてください。

デバイスの横に「4K対応」と書くのではなく、実際の再生経路を記録してください。同じクライアントでも、あるHDRタイトルはダイレクトプレイ、別のタイトルはコンテナや音声の都合でリマックス、字幕をローカルで表示できない場合は動画の変換が必要になることがあります。この再生経路がサーバーの性能を見積もる基準になります。

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

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

HDR対応クライアントがソースをそのまま再生できる場合、サーバーは主にデータを転送するだけなので、必要な処理能力はわずかです。難しいのは、出力先がSDRなどの互換性のない形式を必要とし、サーバーが動画をデコードし、色と明るさを変換して、新しい動画ストリームをエンコードしなければならないケースです。

避けられない変換が必要な場合は、ダッシュボードの設定を有効にしただけでGPUが動作していると思い込まず、実際のホストでハードウェアアクセラレーションを使ったJellyfinのトランスコードを設定し、動作を確認してください。ハードウェアのメディアエンジンを使えば、CPUの汎用処理を大幅に減らせます。ただし、処理経路全体はコーデック、ドライバー、フィルター、権限、クライアントからの要求にも左右されます。

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

字幕の映像への焼き込みは、別のサイジング条件として扱う

サーバーの負荷を考えるうえで、字幕は軽視できる要素ではありません。クライアントが描画できるテキスト字幕ならDirect Playを維持できる場合がありますが、画像ベースの字幕や互換性のない字幕では、サーバーがすべての動画フレームに字幕を描き込む必要が生じ、低負荷の再生が動画処理パイプライン全体を使う状態に変わることがあります。

字幕が原因のトランスコードに関する独立したガイドでは、クライアントが直接描画できない場合にJellyfinが字幕を映像に焼き込むことになりやすいケースとして、PGSとVobSubが挙げられています。コンテンツに適している場合はテキストベースのSRTも用意しつつ、品質やスタイルが重要な場合はオリジナルの字幕トラックを保持し、焼き込みが必要なクライアントに合わせてサーバーの構成を決めてください。

HDRファイルと同じ条件で字幕をテストしてください。両方の要件が重なることがあるためです。1つのリクエストで、サーバーがデコード、字幕のレンダリング、HDRからSDRへのトーンマッピング、スケーリング、エンコードを同時に必要とする場合があります。構成の不足やアクセラレーションの一部未対応が明らかになりやすいのは、単なる「4K」ではなく、この複合処理経路です。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

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

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

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

サイジングの停止条件は、対象のパイプラインでのリソースの使用状況です。GPU／動画エンジンに余力があり、フォールバック処理でCPUが張り付き状態にならず、メモリのスワップも発生せず、再生時のバッファに余裕があれば、そのテスト済みのストリームについてはコア数やRAMを増やしても改善しません。

アプリデータは高速なストレージに置き、トランスコード用の作業領域には十分なスループットを確保する

Jellyfinの設定、データベース、メタデータ、キャッシュは、レイテンシの低いSSDに配置します。映画やエピソードなどの大容量ファイルは、ソースのビットレートを安定して供給できる大容量ストレージに保存します。トランスコード用の作業領域は、長時間の処理中にシステムディスクをいっぱいにしない場所に確保しましょう。

メディアを別のNASに保存している場合は、計算機とストレージ間の接続もテストに含めます。高負荷のトランスコードでは、生成した出力をクライアントに送る前に、元のソースをその経路経由で読み込みます。同時にバックアップやファイル転送を行うと、同じ経路を使うことがあります。

再生に問題が起きたら、字幕またはHDR変換時のJellyfinのバッファリング問題を診断するで説明したのと同じ、問題を段階ごとに切り分ける方法を使います。まずDirect Playかトランスコードかを確認し、次に字幕、トーンマッピング、ハードウェアアクセラレーション、ストレージ、ネットワークの挙動を個別に調べます。現在のボトルネックを特定するまでは、計算能力を追加しないでください。

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

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

1つの再生経路が安定してから、家庭内で実際に起こり得る重複利用を想定し、2人目の同時ユーザーまたはバックグラウンドタスクを追加しましょう。目的は、あらゆる環境に通用するストリーム数を見つけることではありません。お使いのメディア、クライアント、ハードウェアで、どの段階にも過度な負荷をかけずに処理できる同時実行数を見極めることです。

最も負荷の高い想定構成で余裕を保ったまま繰り返し再生できるようになったら、性能の拡張は止めましょう。ハードウェアを追加・変更するのは、計測で特定された問題に担当箇所がある場合だけにします。対応するコーデック経路がないなら別のメディアエンジンが必要です。ソフトウェア処理へのフォールバックが繰り返されるなら、CPUの強化か、より優れたアクセラレーションが必要です。ストレージの競合には構成の変更が必要です。共存できないほど同時処理が多いなら、専用のトランスコードノードを用意するのも選択肢です。