AIのような分析と自動化がJellyfinのストレージと演算能力の要件をどう変えるか

Jellyfin自体が汎用生成AIプラットフォームになるわけではありませんが、最新のメディアサーバーのワークフローでは、チャプター画像、キーフレーム、メディアセグメント、字幕処理、イントロ検出、OCR、文字起こし、タグ付けなど、ライブラリを対象とする自動分析が追加されつつあります。こうした処理は、プラグインや補助ツールのパイプラインによって行われます。

これらの機能により、主に読み取りを行う再生サーバーが、ファイルのスキャン、メディアのデコード、派生情報の計算、メタデータの書き込み、生成アセットの保存も行うシステムへと変わるため、必要な処理能力が変わります。適切なハードウェアとストレージの設計は、どの分析機能を有効にし、いつ実行するかによって異なります。

Jellyfin本体の自動化と周辺のAI処理を切り分ける

Jellyfin本体は、ライブラリのスキャン、キャッシュのクリーンアップ、字幕処理、データベースの最適化、チャプター画像の抽出など、さまざまなバックグラウンドタスクをすでにスケジュールしています。プラグインによって、タスクやメタデータプロバイダーがさらに追加されることもあります。

最新のJellyfinタスク最適化ガイドでは、ライブラリのスキャン、生成メディアの処理、メンテナンス、クリーンアップを、ストリーミングなどの対話的な利用を避けてスケジュールすべきバックグラウンド処理としてまとめています。これらのタスクは、誰も視聴していないときでもCPUとストレージを消費することがあります。

サードパーティーによる分析は別に考える必要があります。音声のフィンガープリント作成、音声の文字起こし、物体認識、言語モデルの呼び出しを行うプラグインや補助ツールは、コアの再生機能とは大きく異なるリソースを消費する場合があります。

派生メタデータによってストレージを継続的に使用

自動化によって、サムネイル、チャプター画像、トリックプレイ用フレーム、字幕、セグメントマーカー、フィンガープリント、インデックス、モデルの出力など、元のライブラリには存在しなかったデータが生成されることがよくあります。再生成できるものもあれば、保護しておく価値があるほど生成コストの高いものもあります。

Jellyfinの現在のメディアセグメントフレームワークは、バックグラウンドスキャンを通じて、イントロ、アウトロ、プレビュー、あらすじ、コマーシャルなど、プロバイダーが生成するセグメントに対応しています。メタデータは動画ファイルに比べれば小容量ですが、生成するスキャンではメディアライブラリの読み取りと分析が必要です。

データベースの増加、生成されるメタデータ、一時作業ファイルに対応できるよう、アプリデータ用SSDには十分な容量を確保してください。元のメディアライブラリに変更がないからといって、ストレージ使用量が一定のままだと考えないでください。

メディア分析で処理をCPUからGPUへ移行、あるいは新たなアクセラレーターを追加

対応している場合、動画のデコードとエンコードには固定機能のメディアエンジンを使用できます。その他のAI系分析では、ツールに応じて汎用CPU、CUDA、OpenVINO、ROCm、NPU、または別のサービスを利用することがあります。

サードパーティの分析機能からも、アクセラレーションの必要性は機能ごとに異なることがわかります。Intro Skipperは音声フィンガープリント分析で繰り返し現れるイントロやアウトロの区間を特定します。この処理は、通常の動画トランスコードや画像認識モデルとは根本的に異なります。したがって、汎用GPUを購入しても、すべての自動化機能に役立つとは限りません。

「AI対応のJellyfin」のためにGPUを購入する前に、実際のソフトウェアとアクセラレーションAPIを特定しましょう。音声フィンガープリントを処理するプラグインはCPUを必要とする場合がありますが、画像認識や文字起こしのサービスは汎用の計算アクセラレーターを活用できる場合があります。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

分析によってストレージI/Oのパターンが変わる

再生では通常、数個の大きなファイルを順番に読み取ります。一方、自動分析ではライブラリ全体を走査し、多数のファイルをシークして、何千もの小さな出力を作成し、データベースを更新することがあります。その結果、スリープ中のHDDが起動したり、対話的なメタデータへのアクセスと競合したりする可能性があります。

ZimaSpaceの記事Jellyfinのバックグラウンド処理の自動化では、この処理を、見えないアイドル時の動作ではなく、独立した稼働時間帯として扱うべき理由を説明しています。

遅延に敏感なアプリデータはSSDに置き、大容量メディアは容量重視のストレージ階層に保存します。一時的な分析データの書き込みを受け止めつつ、アプリケーション用ディスクを満杯にしないスクラッチ領域を選びましょう。

派生データの処理を再生時間帯の外にスケジュールする

ほとんどの分析処理は後回しにできます。ストリームの停止はすぐに気づきますが、イントロ検出が午後8時ではなく午前3時に終わっても、誰も気づきません。

新しい分析機能は、まず代表的なライブラリの一部で実行します。CPU/GPU使用率、ストレージの読み書き量、生成データのサイズ、処理時間、温度、同時再生への影響を測定しましょう。そのうえで、処理を制限するか、スケジュール設定するか、別のワーカーに移すかを決めます。

再構築可能なデータと重要なデータを分ける

• ソースメディア: 重要なコンテンツです。再入手にかかるコストに応じて保護しましょう。
• Jellyfinのデータベース/設定: アプリケーションの重要な状態情報です。こまめにバックアップしましょう。
• 生成画像やキャッシュ: 多くの場合は再生成できますが、再生成にコストがかかることがあります。
• セグメントデータやフィンガープリントデータ: 通常は派生データです。再構築にかかる時間を考慮し、バックアップが必要か判断しましょう。
• 外部AIの出力: 手動編集や、コストの高い独自の分析結果が含まれる場合に限り、信頼できる正本として扱います。

そのため、AI的な分析や自動化は、漠然と「もっと高性能なGPUが必要」と考えるのではなく、バックグラウンド計算と派生ストレージとして見積もるべきです。機能を特定し、読み書きするデータを測定して、実行タイミングを制御し、再生を妨げないようにしましょう。