JellyfinホームサーバーにおけるIntel・AMD・ARMの比較

エヴァ・ウォン

IceWhale author

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

Intel vs AMD vs ARM for Jellyfin Home Servers - Zima Store Online

低摩擦なハードウェアトランスコーディングを必要とする多くのLinux版Jellyfin構成では、Intelが最も無難なデフォルトです。AMDは、正確なメディア処理経路を検証できる場合、よりバランスの取れた計算プラットフォームとなる可能性があり、RK3588など一部のARM SoCは、低消費電力で優れたメディアアクセラレーションを実現できます。最適な選択はCPUのロゴだけでなく、コーデック、クライアント、OS、拡張性、そして同じホストで動かすワークロードによって決まります。

CPUアーキテクチャだけでなく、メディアサーバーのレベルでプラットフォームを比較する

IntelとAMDのホームサーバー向けプロセッサーは通常x86-64プラットフォームですが、ARMは多種多様なSoCで使われる幅広いアーキテクチャを指します。Raspberry Piクラスのボード、RK3588ボード、サーバークラスのARMシステムを、同じ性能帯として扱うべきではありません。Jellyfinでは、CPU、固定機能メディアエンジン、ドライバーパス、OSサポート、メモリ、I/O、拡張性を含む完全なプラットフォームを比較することが重要です。

ZimaSpaceのより広範なARM対x86ホームサーバーガイドが、ソフトウェア互換性、ワット当たりの性能、仮想化、拡張性を分けて説明しているのも同じ理由です。Jellyfinではメディア固有の軸が加わります。十分にサポートされた動画エンジンを備えた控えめなCPUは、ユーザーが実際に要求するトランスコードにおいて、はるかに強力な汎用CPUを上回ることがあります。

クライアントがすでにファイルに対応している場合、3つのプラットフォーム系統はいずれも比較的少ない計算資源でメディアデータを配信できるため、ダイレクトプレイでは差がさらに縮まります。Jellyfinでデコード、トーンマッピング、字幕の焼き込み、エンコード、大規模なライブラリのスキャン、または他のアプリケーションとのホスト共有が必要になると、プラットフォームの選択が重要になります。

低摩擦なハードウェアトランスコーディングではIntelが通常優位

多くのJellyfin購入者にとって、Intelの主な強みは対応する内蔵グラフィックスで利用できるQuick Syncです。これにより、コンパクトで常時稼働するサーバーとしてすでに魅力的なプロセッサーに固定機能の動画処理能力が組み込まれるため、専用カードを追加せずにCPU、メディアエンジン、そして控えめな消費電力を得られます。

現在のIntel Quick Sync対応Jellyfinガイドは、その利点が単なる理論ではなく運用上のものだと示しています。iGPUが有用なトランスコードの余力を生み出すには、レンダーデバイス、グループ権限、メディアドライバー、コーデック対応、そして実際のFFmpegパスがすべて整合していなければなりません。

優先事項が、ハードウェアトランスコードを継続的に行うコンパクトなLinuxメディアサーバーと、主流で実績のある構成手順である場合、Intelが優位です。ただし、選んだIntelモデルに必要なiGPUやコーデック世代がない場合、ワークロードの大半が汎用コンピューティングである場合、または別のプラットフォームのアクセラレーション経路が対象のメディアライブラリで実証済みの場合、その自動的な優位性は失われます。

AMDは汎用コンピューティング性能と強力なAPUで勝てるが、メディア処理経路の確認が必要

AMDのプラットフォームは、Jellyfinのアクセラレーションに対応できる高いCPU性能と内蔵またはディスクリートグラフィックスを組み合わせられます。そのため、同じ筐体でコンパイル、VM、データベース、その他のCPU負荷の高いサービスも実行する場合、AMD APUは魅力的な選択肢になります。ただし、メディアサーバーの判断は、すべてのRyzenモデルが同じグラフィックス機能を備えていると決めつけず、正確なVCN／VA-APIまたはAMFの経路に基づいて行うべきです。

独立したJellyfinのトランスコードテストでは、最新のAMD RDNA3 iGPU構成が、低消費電力のIntel N100と競合し、いくつかのテスト経路ではそれを上回る速度を示しました。同時に、トーンマッピングや字幕処理によって、ボトルネックがメディアコーデックブロック自体から別の箇所へ移ることも明らかになっています。だからこそ、単一のエンコーダー仕様だけでプラットフォームを決めることはできません。

AMDは、CPU性能の価値や同一ホスト上でのコンピューティングが重要で、なおかつ正確なiGPU／dGPU、OS、ドライバー、コーデックの経路がJellyfinのワークロードを処理できる場合に優位になります。購入者がコア数やベンチマーク上の価値だけを理由にAMDを選ぼうとしており、ハードウェアトランスコードを検証していない場合は、Intelのほうが依然としてリスクの低い既定の選択肢です。

-15% OFF

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

Single board computer zimaboard2

SoCに適切なVPUとソフトウェアサポートがある場合にのみARMは勝利する

ARMは非常に高効率ですが、アーキテクチャだけで実用的なJellyfinのビデオエンジンが保証されるわけではありません。多くの小型ボードはダイレクトプレイには対応できますが、クライアントが変換を必要とするとCPUボトルネックになります。選ばれたSoCは異なります。RK3588クラスのハードウェアには専用のビデオ処理ブロックとJellyfin向けのアクセラレーションパスがあるため、未対応のSBCと一括りにすべきではありません。

最近のRK3588のJellyfinベンチマークでは、デバイスとソフトウェアスタックを正しく構成すれば、RKMPPによるハードウェアデコードおよびエンコードでCPU負荷を大幅に肩代わりできることが示されています。この記事は、ARMを選ぶ際の重要な制約も示しています。その結果は特定のSoCとVPU経路に固有のものであり、「ARM」全般に当てはまるものではありません。

必要なコーデックに対応したサポート対象SoCで、残りのソフトウェアスタックもARM64で利用できるなら、低アイドル電力、コンパクトなサイズ、導入のしやすさという点でARMが有利です。一方、家庭内でx86専用ソフトウェア、幅広いPCIe拡張、サポートされていないプラグインやイメージ、またはSoCのアクセラレーションパイプライン外にあるメディア機能に依存する場合は不利になります。

ドライバーとコンテナのサポートによって、紙上の仕様上の優位性が逆転することがある

シリコン上にメディアエンジンが存在していても、ホストドライバーがそれを公開できなかったり、コンテナがデバイスにアクセスできなかったりすれば、Jellyfinにとっては役に立ちません。Intel、AMD、サポート対象のARMプラットフォームには、それぞれ異なるデバイスノード、ユーザー空間ライブラリ、アクセラレーションAPIがあります。そのため、正しい比較には導入時の手間とアップグレードの保守性も含める必要があります。

ベンダー横断のJellyfin Dockerハードウェアトランスコードガイドでは、Intel QSV、NVIDIA、AMD VA-APIを分けて説明しています。コンテナの構文が同じでも、ドライバー経路まで同じになるわけではないためです。ARM SoCでは、RKMPPのような別のベンダー固有経路が加わることもあります。ハードウェアアクセラレーションの切り替えを保存できるだけでは根拠になりません。代表的なFFmpegトランスコードを実行することが根拠になります。

この比較軸では、理論上のコーデック対応表を重視しません。カスタムパッチや不安定なランタイム作業に依存する強力な仕様よりも、正常に動作することが確認されたドライバーと導入経路を備えた、やや見劣りするプラットフォームを優先します。常時稼働する家庭向けサービスでは、再現性のあるアップグレードも性能の一部です。

失敗させられないワークロードでIntel、AMD、ARMを選ぶ

通常のハードウェアトランスコードを行うコンパクトなJellyfinホストで、最も幅広く手間の少ない標準構成を求めるならIntelを選びます。一般的なCPU性能、仮想化、または高性能なAPUが、メディア処理経路をより入念に検証する必要性を上回るほど重要ならAMDを選びます。省電力とコンパクトな設置が最優先で、Jellyfinの正確なVPU経路をすでに検証済みなら、サポート対象のARM SoCを選びます。

最も重視度を下げるべき仕様は、CPUの生のコア数です。ハードウェアアクセラレーションを利用したJellyfinの性能は、一般的なCPUコア数が決定要因になるはるか前に、コーデックのサポート、メディアエンジンの処理能力、フィルター、メモリ帯域幅、字幕の焼き付け、ドライバー、クライアントの動作によって制限されることがあります。

軸	Intel	AMD	ARM
手間の少ないJellyfinのHWA	サポート対象のiGPUでは強力なデフォルト	正確なVA-API／AMF経路を検証できれば高い	サポート対象の一部SoCでのみ高い
一般的なコンピューティング性能	幅広い選択肢	高性能なAPU／CPUではコストパフォーマンスに優れることが多い	SoCへの依存度が高い
消費電力／コンパクトさ	優れた低消費電力の選択肢	効率的な選択肢があり、より高い性能余力を持つことが多い	特化型ボードでは非常に優れた性能を発揮する場合がある
拡張性／ソフトウェアの選択肢	幅広いx86エコシステム	幅広いx86エコシステム	ボードとARM64ソフトウェアの対応状況には大きな差がある
購入時のリスク	世代とiGPUの不一致	GPU／エンコーダー／ドライバーに関する前提	すべてのARM SBCが有用なVPUサポートを備えていると仮定する

メディアのほとんどがDirect Playで再生されるなら、3社のいずれでも十分な場合があり、電力、ストレージ、アプリケーション互換性、価格を基準に選ぶべきです。トランスコードが重要なら、正確なモデル、コーデック経路、オペレーティングシステム、導入方法で代表的なテストに合格したことを確認してから購入してください。

よくある質問

JellyfinのCPUプラットフォームでは、Intelが常に最適ですか？

いいえ。Intelは、サポートされているQuick Sync対応iGPUが成熟し、広く利用されているハードウェアトランスコード経路を提供するため、特にLinuxでは有力なデフォルト候補です。一般的なコンピューティング性能や特定のAPUを重視する場合はAMDがサーバー全体としてより適していることがあり、サポート対象のARM SoCは優れた低消費電力メディアノードになり得ます。最適な選択肢は、正確なモデルとワークロードによって変わります。

ARMサーバーで4KのJellyfinトランスコードに対応できますか？

可能なARMシステムもありますが、この説明はSoCごとに判断する必要があります。RKMPPが正常に動作するRK3588クラスのプラットフォームと、JellyfinでビデオエンジンがサポートされていないSBCでは大きく異なります。ARM64対応をメディアアクセラレーション対応と見なす前に、VPU、コーデック、トーンマッピングの要件、ドライバー、実際のトランスコード速度を確認してください。

CPUのコア数でJellyfinのパフォーマンスを予測できますか？

必ずしもそうとは限りません。コア数はソフトウェア作業や同時稼働するアプリケーションでは重要ですが、ハードウェアトランスコードは固定機能メディアエンジン、コーデック互換性、字幕処理やトーンマッピングのフィルター、メモリ帯域幅、ドライバー経路によって制限される場合があります。コア数を増やすために費用をかける前に、メディアパイプライン全体を比較してください。