字幕付きHDR再生がJellyfinのリソーススケジューリングを変える理由

エヴァ・ウォン

IceWhale author

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

Why HDR Playback With Subtitles Changes Jellyfin Resource Scheduling - Zima Store Online

字幕付きのHDR再生では、字幕の焼き付けとトーンマッピングによって、軽量なダイレクトプレイのリクエストが複合的な変換パイプラインへ変わることがあり、Jellyfinのスケジューリングが変化します。

リビングのテレビでは、画像ベースの字幕トラックを選択するまでは4K HDRファイルを直接デコードできる場合があります。一方、タブレットでは同じソースからSDR出力が必要になることがあります。その場合、Jellyfinは映像、色、字幕、ビットレートの制約を同時に満たさなければなりません。スケジューリングの問題は単純に「HDRは負荷が高い」ということではなく、各段階が対応ハードウェア上で処理され続けるか、それとも共有CPU処理へフォールバックするかという点にあります。

字幕の互換性によって映像の再構築が必要かどうかが決まる

テキスト字幕は別ストリームとして渡せる場合がありますが、画像ベースの形式や対応していないスタイルでは、Jellyfinがすべての映像フレームに字幕を描画する必要が生じることがあります。ピクセルが変更されると、サーバーは元のエンコード済み映像をそのまま送信できなくなり、再度デコード、合成、エンコードを行わなければなりません。

クライアントの対応状況が重要なのは、画像ベースの字幕の焼き付けが、小規模なテキスト処理ではなく、完全なトランスコードを開始する要因として説明されているためです。この切り替えにより、字幕を選択した直後にCPUまたはGPUの使用率が急上昇する理由が分かります。

影響はクライアントごとに異なります。同じ字幕ファイルでも、あるプレーヤーでは外部字幕のまま扱われ、別のプレーヤーでは映像に焼き付けられることがあります。そのためスケジューリングでは、字幕方式を映像配信後に付加する装飾的な設定ではなく、ワークロードの一要素として扱うべきです。

HDRは色変換への依存関係を追加する

HDRソースをSDRディスプレイで再生する場合、ハイライトと色域を出力先に合わせるため、サーバーでトーンマッピングが必要になることがあります。字幕も焼き付ける場合、最終エンコードの前に、色変換と合成の各段階でピクセル形式とハードウェア対応を一致させなければなりません。

実用的なトランスコードの概要では、HDRトーンマッピングはGPUが搭載されているかどうかではなく、対応するデコード、フィルタリング、エンコード機能に依存すると説明されています。ハードウェア処理の経路が一部しか対応していない場合、高負荷なフィルタ処理がCPUへ戻されることもあります。

この依存関係により、スケジューリングの対象は1つのアクセラレーター処理から、複数のリソースを組み合わせた処理へ変わります。GPU使用率が中程度に見えていても、単一スレッドの処理やメモリ転送の段階が、エンコーダーへ渡せるフレームレートを制限することがあります。

平均使用率が限界に達する前に再生の安定性が低下する理由

再生には、数分間の平均値が良好であることではなく、リアルタイムを上回る速度で継続的に処理できることが必要です。字幕の描画、シーンの複雑さ、ストレージからの読み出し、別セッションによる短時間の負荷によってセグメントの生成が遅れると、小さなクライアントバッファが空になることがあります。

字幕同期の問題に関する報告は、明確なリソース枯渇メッセージではなく、タイミングや連続性の問題として目に見える障害が発生することを示しています。CPU使用率の平均値だけでは、1つの段階が飽和している状態や、短時間のスケジューリング停止を見落とすことがあります。

したがって、安定性は余裕と最悪時のフレーム処理能力に左右されます。再生速度が平均1.2倍のパイプラインでも、複雑なシーンで繰り返し1.0倍を下回り、クライアントがその間に十分なバッファを蓄積できなければ、再生が途切れる可能性があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

ハードウェアアクセラレーションが不十分になるケース

ハードウェアアクセラレーションが効果を発揮するのは、選択したデバイスが、そのセッションで使用されるソースコーデック、ビット深度、トーンマッピング経路、字幕合成方式、出力コーデックに対応している場合だけです。対応していない組み合わせでは、ソフトウェア処理へフォールバックしたり、CPUとGPUのメモリ間でフレームが何度も移動したりすることがあります。

この境界があるため、より広範なJellyfinのバッファリングモデルでは、再生をGPUだけの問題ではなく、エンドツーエンドの経路として捉えています。アクセラレーションを有効にした後も、ストレージ、キャッシュへの書き込み、クライアント側のバッファリングが制約要因として残ることがあります。別のフィールドレポートでも、目に見える症状からボトルネックを決めつけるのではなく、字幕とトーンマッピングのテストを実施することが推奨されています。

代表的なHDRタイトルを1本選び、字幕なし、テキスト字幕あり、画像字幕ありの3条件でテストしてください。それぞれの再生モード、トランスコード速度、CPU負荷、ビデオエンジン負荷、出力される色形式を記録し、最も容易なダイレクトプレイの結果ではなく、実際に成立する最も遅い組み合わせを基準に容量を確保します。