ZimaOSユーザーが、16GBのRAMを搭載したIntel N100システムでJellyfinを実行した際の再生挙動について、明確な違いを報告しました。1080pまでのメディアは正常に動作しましたが、トランスコードが必要な4KストリームではCPU使用率が100%まで上昇し、途切れがひどくて視聴できなくなりました。JellyfinはHostネットワークで実行されており、サーバーに専用GPUはありませんでした。
コミュニティでの議論から、最終的に確認された単一の解決策が得られたわけではありません。代わりに、ソフトウェアトランスコード、Intel内蔵グラフィックス、VA-API、コーデック互換性、HDRトーンマッピング、実行中のトランスコードを確認する適切な場所について、実践的な調査へと発展しました。元のユーザーは最終的にハードウェアアクセラレーションを有効にし、1本のトランスコード済みストリームを再生できましたが、CPU使用率は約95～98%のままでした。
Jellyfinで最初に発生した4Kトランスコード問題
サーバーにはIntel N100プロセッサーと16GBのメモリが搭載されていました。Jellyfinはローカルメディアサーバーとして機能し、DockerのネットワークタイプはHostに設定されていました。通常の1080p再生には問題がありませんでした。
問題が発生したのは、トランスコードが必要な4Kファイルの場合だけでした。その時点でプロセッサー使用率は100%まで上昇し、再生は途切れ、ストリームは実質的に視聴できない状態になりました。そのためユーザーは、専用グラフィックスカードなしでトランスコード性能を改善できるJellyfinの設定を知りたいと考えました。
1080pと4Kのこの違いが、返信で中心的な手がかりとなりました。コミュニティのメンバーは、ネットワークやメモリよりも、Jellyfinが何を変換しているのか、N100の内蔵グラフィックスが使用されているのか、選択したクライアントがソース形式を直接再生できるのかに注目しました。
コーデックとクライアントの互換性が議論に加わった理由
goultronは、N100クラスのシステムでの4Kトランスコードは、特にサーバーがCPUにフォールバックした場合、負荷の高い処理だと説明しました。本人の方針は、4Kライブラリの維持を避け、より幅広いデバイスで直接再生できるH.264メディアを優先することでした。
返信では、実用上重要な点も強調されました。H.264動画であっても、何らかの変換が必要になる場合があります。受信デバイス、対応する音声形式、利用可能なネットワーク速度のすべてが、最終的な再生経路に影響する可能性があります。goultronは、H.264動画を使用しているにもかかわらずトランスコードされたストリームの一部は、音声変換が原因ではないかと考えました。
利用可能な4Kコンテンツの多くが、一般的にH.265/HEVCを使用している点と対比されました。一部の小型再生デバイスやテレビでは、すべてのH.265プロファイルを直接処理できない場合があります。その場合、Jellyfinはクライアント向けにソースを変換する必要があり、負荷がサーバーに戻ります。
gelbuilding の主な診断：まず N100 の iGPU を確認する
gelbuilding は、Jellyfin が 4K のソフトウェアトランスコードを実行している場合、N100 の動作は想定どおりだと考えました。その説明は単純で、この処理によって小型 CPU の使用率が最大まで上昇する可能性があり、元のユーザーが 1080p の再生は滑らかに行える一方で、4K のトランスコードは実用にならなかった理由を説明できます。
最初に確認すべきことは、Jellyfin が N100 に内蔵された Intel メディアエンジンを実際に使用しているかどうかでした。N100 は iGPU を利用するために別途グラフィックカードを必要としませんが、Jellyfin でハードウェアアクセラレーションを有効にし、コンテナからそのデバイスにアクセスできるようにする必要があります。
返信で共有された設定手順は次のとおりです。
- Jellyfin の管理インターフェースを開きます。
- 再生を開きます。
- トランスコードを開きます。
- ハードウェアアクセラレーションを有効にします。
- このスレッドで説明されている設定では、VA-API を選択してください。
期待されていた結果は、処理が CPU 上のソフトウェア処理から Intel iGPU 側へ移行することでした。gelbuilding は、N100 の iGPU ですべての 4K ソースを滑らかに変換できるとは限らないとも警告しました。特に、一部の高ビットレートの HEVC ファイルは、ソフトウェア処理にフォールバックする可能性があると説明しました。
コミュニティによって VA-API を確認する場所が訂正された
最初の返信では、Dashboard → Activity で H.264 または HEVC の VA-API ラベルを確認するよう提案していました。goultron は Jellyfin 10.10.7 でこの助言を試しましたが、Activity ページに表示されたのは VideoPlayback や VideoPlaybackStopped などのイベントだけでした。
その後、gelbuilding は手順を訂正しました。Activity ページでは、トランスコードに VA-API とソフトウェアのどちらが使われたかは表示されない想定でした。関連情報は、4K ストリームのトランスコードが実行されている間に、次の場所で確認する必要があります。
- ダッシュボード
- 再生
- トランスコード
アクティブなセッションでは、コーデックの下に行が表示されるはずです。VA-API というラベルはハードウェアアクセラレーションが使用されていることを示し、Software というラベルは CPU が変換処理を行っていることを示します。トランスコード領域が空の場合、そのファイルはダイレクト再生またはダイレクトストリーミングになっており、動画のトランスコードが実行されていない可能性があります。
btop ではスレッドの答えが明確にならなかった理由
goultron は、btop を使って iGPU の動作確認も試みました。Intel iGPU は GPU 領域に明確には表示されませんでしたが、同じ iGPU はすでに Frigate へのパススルーに成功しており、Frigate でもそのデバイスを使用していることが示されていました。
gelbuildingは、このZimaOS環境ではbtopが主に専用GPUを表示するため、Intel iGPUが動作中でも表示されない可能性があると返信しました。そのため、直接の確認方法としてJellyfinのアクティブな「トランスコード」画面を使うことを推奨しました。
その後、Zima-JerryはGPU使用率の確認にbtopを使えると補足しました。ただし、議論が終わるまで、この2つの説明の整合性は確認されませんでした。そのため、このコミュニティスレッドはbtopを追加の確認ツールとして使うことを支持するものの、唯一の証拠とすることはできません。VA-APIによる処理かソフトウェア処理かを特定するには、Jellyfinのアクティブなトランスコード情報が引き続き必要です。
Zima-JerryのHDRトーンマッピング設定
Zima-Jerryは、Intel N100でのJellyfinのハードウェアアクセラレーションとHDRトーンマッピングに重点を置いた、別のコミュニティ設定を紹介しました。その以前の事例では、当時App Storeで提供されていたJellyfinのバージョンに色調変換の問題があると報告されていました。
提案された代替手段は、nyanmisaka JellyfinコンテナイメージとカスタムYAML設定を組み合わせて使用する方法でした。これは当時使用されていたJellyfinおよびZimaOSのバージョンに関連するコミュニティの回避策であるため、既存のインストールを置き換える前に、現在のApp Store版と比較する必要があります。
関連する投稿で共有された結果は、4Kトランスコードが無制限に可能になるというものではありませんでした。Zima-Jerryは、テストした設定では、N100の内蔵グラフィックスでDolby Vision動画をおよそ4K・30fps以下ならスムーズに変換できると見積もりました。
元のユーザーがハードウェアアクセラレーションを有効にした後の変更点
返信を確認した後、Heimwerkerkingはトランスコードのハードウェアアクセラレーションを有効にしました。これにより、少なくとも1つのトランスコード済みストリームが再生可能になるという明確な改善が見られました。
ダッシュボードに表示されたアクティブな再生情報は 48.7 Mbps MP4 H264 AACただし、CPU使用率は95%から98%の間で推移していたため、ユーザーはIntel iGPUが実際に動画変換を処理しているのか、依然として確信を持てませんでした。
この結果は、問題が完全に解決したことを証明するものではありません。設定変更によって再生が改善したことは示されましたが、スレッドにはVA-APIラベルの確認、FFmpegの完全な結果、または整合性のあるiGPU使用状況の記録がありませんでした。最後の返信でも、btopでGPU使用率を確認することが改めて提案され、その後の確認報告はありませんでした。
このコミュニティスレッドで実際に確認されたこと
この議論は、N100のCPU使用率が100%に達した最初の原因として、ソフトウェアによる4Kトランスコードを強く示しています。また、確認方法も修正され、［アクティビティ］の履歴ではなく、4Kトランスコードを開始してJellyfinの［再生］と［トランスコード］のエリアでアクティブなセッションを確認することになりました。
返信では、処理負荷に関するいくつかの条件も示されています。H.265のクライアント互換性、音声変換、高いソースビットレート、HDRトーンマッピング、使用するJellyfinコンテナによって、結果は変わる可能性があります。VA-APIを有効にすると、元のユーザーはトランスコードされた1ストリームを再生しやすくなりましたが、高いCPU使用率は残りました。
このスレッドから、N100で処理できるストリーム数の普遍的な基準が確立されたわけでも、Intel Arc GPUが必須だと証明されたわけでもありません。gelbuildingは、安定した4K変換が引き続き必要なユーザー向けに、ソースのビットレートを下げるか、小型のIntel Arc GPUを追加するという2つの次の手段を提示しました。元の投稿者がどちらかを試す前に、議論は終了しました。
コミュニティでの議論からのFAQ
1080pは動作したのに、4Kのトランスコードでは途切れたのはなぜですか？
コミュニティは、この違いを4Kファイルの変換が必要になった際に発生する、はるかに重いソフトウェア処理負荷によるものと説明しました。元のN100では、その処理中にCPU使用率が最大に達しました。
Jellyfinでは、VA-APIをどこで確認すべきですか？
トランスコードを強制する4Kストリームを開始し、［ダッシュボード］の［再生］と［トランスコード］でアクティブなセッションを確認します。［アクティビティ］のイベント履歴には、必要なVA-APIまたはソフトウェアのラベルが表示されないことが確認されました。
アクティブなトランスコード表示が空の場合、何を意味しますか？
gelbuildingの訂正によると、それはファイルがダイレクト再生またはダイレクトストリーミングで、現在ビデオのトランスコードが行われていないことを意味する可能性があります。
ハードウェアアクセラレーションを有効にすることで、この問題は完全に解決しましたか？
いいえ。トランスコードされた1ストリームを再生可能にはしましたが、報告されたCPU負荷は95～98%のままで、iGPUがパイプライン全体を処理したことを最終確認しないままスレッドは終了しました。
4Kが不安定なままだった場合、コミュニティはどのような選択肢を提案しましたか？
返信では、可能な場合は互換性のあるH.264メディアを優先すること、4Kソースのビットレートを下げること、Zima-Jerryが共有したカスタムJellyfin設定を試すこと、またはより高性能なハードウェアトランスコード経路のために小型のIntel Arc GPUを追加することが提案されました。
