専用メディアハードウェアは、動画のトランスコードが繰り返し発生するワークロードでJellyfinに大きな優位性をもたらします。一方、ほとんどがダイレクトプレイのライブラリでは、その優位性は小さい場合があります。
最初の確認:実際に動画をトランスコードしていますか?
ダイレクトプレイでは、動画を再エンコードせずにソースを対応クライアントへ送信するため、その経路で専用GPUやメディアエンジンが高速化できる処理はほとんどありません。通常はネットワークとストレージのほうが重要です。
クライアントがソースのコーデック、ビットレート、字幕の処理方法、HDR形式に対応できない場合、サーバーは動画変換を行う必要があります。固定機能のデコード・エンコードハードウェアが、パフォーマンスと消費電力の特性を大きく変えられるのは、このワークロードです。
Jellyfinのトランスコードに関するドキュメントでは、この依存関係が明確に説明されています。変換が要求されるかどうかは、クライアントの性能と制約によって決まります。ハードウェアアクセラレーションを必須と考える前に、その発生頻度を測定してください。
動画のエンコードとデコードがボトルネックなら、ハードウェアアクセラレーションが有効
Jellyfinは、対応する動画のデコード、処理、エンコードをIntel、NVIDIA、AMD、Apple、Rockchipのメディアハードウェアへオフロードできます。これにより、ハードウェアとソフトウェアのスタックが対応する段階では、汎用CPUによる処理への依存を減らせます。
公式のハードウェアアクセラレーションガイドでは、ハードウェア、ドライバー、ソフトウェアの制限により、一部のパイプライン段階がCPUに残る可能性があるため、部分的なアクセラレーションも起こり得ると説明されています。したがって、実際に比較すべきなのは「GPUがあるかないか」ではなく、完全な処理経路と部分的な処理経路です。
CPUのみの動画変換ですでにリアルタイム速度に届かない、または他のサービスに必要なリソースを消費している場合、専用アクセラレーションの導入効果は大きくなります。すべてのクライアントがダイレクトプレイするためCPU使用率がほとんど上がらないなら、その導入効果は小さいでしょう。
HDRトーンマッピングと字幕の焼き込みで、優位性はさらにワークロード依存になる
HDRからSDRへのトーンマッピングや字幕の焼き込みでは、基本的なデコードとエンコード以外の処理段階が追加されることがあります。対応状況はGPUの世代、オペレーティングシステム、コーデック、字幕の処理方法によって異なるため、名目上はアクセラレーション対応のサーバーでも、難しいファイルではCPU使用率が高くなる場合があります。
Jellyfinは対応プラットフォームでのハードウェアアクセラレーションによるトーンマッピングを文書化していますが、形式やドライバーの制限も記載しています。購入判断では、一般的なH.264 SDRサンプルだけでなく、実際に扱う中で最も負荷の高い代表的なファイルもテスト対象に含めるべきです。
変換を引き起こす可能性が最も高いクライアントとメディアの組み合わせで、制御されたテストを実行してください。そのストリームが十分な余裕を持ってリアルタイム再生を維持し、他のサービスのためにCPUを空けられるなら、そのアクセラレーション経路はあなたのワークロードに大きなメリットをもたらしています。
内蔵メディアエンジンは、シンプルさとアイドル時の消費電力でディスクリートGPUを上回ることが多い
専用のハードウェアアクセラレーションは、必ずしも別途グラフィックカードを意味しません。最新の内蔵グラフィックスには、Jellyfinが利用できる固定機能のメディアエンジンが搭載されている場合があります。これにより、追加のディスクリートGPUに伴う設置スペース、電力、冷却、ドライバーの複雑さを避けられます。
Jellyfinのハードウェア選定ガイドでは、現在、新しいサーバー向けに複数の内蔵プラットフォームを推奨し、最新のコーデック対応を重視しています。これは、CPUのみの処理と大型のディスクリートカードの導入の間にある、優れた第三の選択肢です。
内蔵グラフィックスでは満たせないコーデック機能、メディアエンジンの処理性能、または別のGPUワークロードが必要な場合、ディスクリートGPUを導入する理由は強くなります。iGPUが実際のトランスコードテストに合格するなら、ディスクリートカードは不要なオーバーヘッドになる可能性があります。
ソフトウェアの対応状況で勝者が変わることがある
ハードウェアの性能は、ホストのドライバー、カーネルまたはオペレーティングシステム、コンテナのデバイスマッピング、権限、JellyfinのFFmpegスタックがそのハードウェアを利用できる場合にのみ意味を持ちます。理論上は高性能なGPUでも、ソフトウェア経路が不安定なら、確実に動作する控えめな内蔵エンジンに負ける可能性があります。
ZimaSpaceのハードウェアアクセラレーションによるストリーミングガイドでは、GPUを利用した実用的な構成と、実際のサーバーでアクセラレーションを利用可能にするデバイスアクセスの手順を紹介しています。
別の検証ガイドでは、設定が成功したと思い込むのではなく、現在のストリームが実際にハードウェアを使用していることを確認する方法を説明しています。
購入の条件は、使用するOSとコンテナモデルでサポートされ、保守可能な経路があることにしてください。その経路を検証できない場合、ハードウェアアクセラレーションを確実なメリットとして数えるべきではありません。
条件付きの結論:アクセラレーションが有効なのは変換であり、すべてのJellyfinサーバーではない
複数のクライアントで定期的に動画変換が必要になる場合、リモート環境で低ビットレート出力が必要な場合、HDRからSDRへの変換が頻繁に発生する場合、またはCPUのみのトランスコードが他のサービスに影響する場合は、ハードウェアアクセラレーションを選択してください。
実際に利用するクライアントがすでにライブラリをネイティブに再生でき、CPU使用率も低いなら、ダイレクトプレイと既存のハードウェアを使い続けてください。その場合、ネットワークの信頼性、ストレージ、バックアップ、またはより優れたクライアントに投じた費用のほうが、ユーザーが実感できる改善につながる可能性があります。
コーデックと処理性能の要件を満たすなら、ディスクリートGPUより先に内蔵メディアエンジンを選びましょう。実測したワークロードが内蔵経路の限界を超えた場合にのみ、ディスクリートGPUへ移行してください。
製品比較
もっと読む

JellyfinのCPUコア数を増やすと、実際にいつ高速化するのか?
Jellyfinでコア数を増やす効果があるのは、制御された低コア数の候補がCPUバウンドになり、同じワークロードがより大きなプロセッサでスケールする場合に限られます。

Jellyfinへの直接リモート公開とプライベートVPNアクセス:どちらの方法がより安全?
自分で管理するクライアントにはプライベートVPNを使用し、クライアントとの互換性や共有のためにパブリックな到達性が必要な場合にのみ、セキュリティ強化済みの公開HTTPSルートを使用してください。

JellyfinではSATA SSDとNVMe SSDのどちらが適している?結果を左右する仕様とは?
ほとんどの Jellyfin サーバーでは、HDD から SSD への移行が大きな性能向上につながります。NVMe が SATA を上回るのは、アプリの状態データや共有ホストの I/O が実際に SATA のレイテンシーやキューの上限に達する場合に限られます。

