AIに似た分析と自動化がJellyfinのストレージおよびコンピューティング要件をどう変えるか

Jellyfin自体が汎用的な生成AIプラットフォームへと変化しているわけではありません。しかし、最新のメディアサーバーのワークフローでは、ライブラリに対して、チャプター画像、キーフレーム、メディアセグメント、字幕処理、イントロ検出、OCR、文字起こし、タグ付け、その他のプラグインや連携ツールによる処理など、より多くの自動分析が追加されています。

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

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

Jellyfin本体には、ライブラリスキャン、キャッシュのクリーンアップ、字幕処理、データベースの最適化、チャプター画像の抽出、その他のバックグラウンドジョブをすでにスケジュールする機能があります。プラグインによって、さらに多くのタスクやメタデータプロバイダーを追加できます。

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

サードパーティ製の分析処理は、別のものとして扱うべきです。音声のフィンガープリントを作成したり、音声を文字起こししたり、物体認識を実行したり、言語モデルを呼び出したりするプラグインや連携ツールは、Jellyfin本体の再生処理とは大きく異なるリソースを消費する場合があります。

派生メタデータは永続的なストレージを追加で消費する

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

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が起動し、インタラクティブなメタデータアクセスと競合する可能性があります。

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

遅延の影響を受けやすいアプリデータはSSDに配置し、大容量メディアは容量重視のストレージ層に置き、一時的な分析書き込みをアプリケーションディスクを圧迫せずに受け止められるスクラッチ領域を選びましょう。

派生データの処理を再生時間帯と調整する

分析処理の多くは後回しにできます。ユーザーはストリームの停止にはすぐ気付きますが、イントロ検出が午後8時ではなく午前3時に完了しても気にしません。

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

再生成可能なデータと正式なデータを分けて管理する

• ソースメディア：正式なコンテンツであり、交換コストに応じて保護します。
• Jellyfinのデータベース／設定：正式なアプリケーション状態であり、頻繁にバックアップします。
• 生成画像とキャッシュ：再生成できることが多いものの、再生成には大きなコストがかかる場合があります。
• セグメントまたはフィンガープリントデータ：通常は派生データです。再構築にかかる時間を踏まえ、バックアップが必要か判断します。
• 外部AIの出力：手動編集や高コストで固有性の高い分析結果を含む場合に限り、正式なデータとして扱います。

したがって、AIに近い分析処理や自動化は、「もっとGPUが必要」という曖昧な要件ではなく、バックグラウンドのコンピュート処理と派生ストレージとして見積もるべきです。機能を具体的に特定し、何を読み書きするのかを測定し、その処理を実行する時間帯を制御して再生を保護しましょう。