ハードウェアトランスコーディングが実際に動作しているかどうかを確認する方法

ハードウェアトランスコーディングをオンにすることは、ハードウェアトランスコーディングが動作していることを証明するのと同じではありません。メディアサーバーは設定を有効にしていても、現在のストリームは直接再生されているかもしれませんし、ソフトウェアトランスコーディングにフォールバックしているかもしれませんし、パイプラインの一部だけでハードウェアを使用しているかもしれませんし、Docker内でGPUにアクセスできていないかもしれません。

より安全な確認方法は、複数の角度から同じアクティブストリームを追跡することです：実際のトランスコードを強制し、メディアサーバーダッシュボードを読み取り、ホストレベルのGPUまたはiGPUのアクティビティを確認し、結果が不明瞭な場合はFFmpegログを検査し、クライアントが期待される再生出力を受け取っていることを検証します。

設定は許可を与えるだけで、証明にはならない

ハードウェアトランスコーディング設定は許可であり、テスト結果ではありません。これは、ストリーム、コーデック、ドライバー、デバイスアクセス、再生条件が整った場合にPlex、Jellyfin、Emby、または他のメディアサーバーがハードウェアアクセラレーションを使用できることを示しますが、現在視聴しているストリームがGPUを使用していることを証明するものではありません。

Plexはハードウェアアクセラレーションストリーミングを、Plex Media Serverがビデオ変換時に専用のビデオデコーダーおよびエンコーダーハードウェアを使用する方法として説明しており、これによりCPU負荷の高いトランスコード処理を軽減できます。しかし、Plexはハードウェアアクセラレーションが利用できないか、特定のビデオパスに対応していない場合はソフトウェアフォールバックが発生することも指摘しています。

この区別が重要なのは、メディアサーバーが正常な設定ページを表示していても、アクティブなセッションが別の動作をしている可能性があるためです。ファイルは直接再生されているかもしれません。サーバーは音声のみをトランスコードしているかもしれません。ビデオはハードウェアでデコードされているがソフトウェアでエンコードされているかもしれません。またはコンテナがホストOSが認識しているデバイスにアクセスできない場合もあります。

信頼できる検証フローは5つの質問に答えるべきです：ストリームは実際にトランスコードしているか、ダッシュボードはハードウェアアクセラレーションを表示しているか、ホストはビデオのエンコードまたはデコードのアクティビティを示しているか、FFmpegのログはハードウェア経路を示しているか、クライアントの再生結果は期待される解像度、ビットレート、コーデック、または字幕の動作と一致しているか？

これらの層が一致すれば、ハードウェアトランスコーディングはおそらく機能しています。もし矛盾があれば、単に設定が壊れているとかダッシュボードが間違っているというわけではありません。より良い答えは、パイプラインのどの層が変わったのかを見つけることです。

まずストリームを実際にトランスコードさせる

GPU使用率を確認する前に、メディアサーバーが実際にトランスコードしていることを確認してください。ファイルが直接再生されている場合、サーバーは主に元のストリームをクライアントに送信しています。その場合、CPU使用率もGPU使用率も低いのは正常です。

制御されたテストストリームはサーバーに何かを変換させる必要があります。通常は再生品質を下げる、ソースコーデックをサポートしないブラウザやクライアントを使う、リモートのビットレート制限を設定する、焼き込みが必要な字幕を有効にする、またはクライアントのためにビットレートの高いファイルを選ぶことで可能です。

Plexの場合、簡単なテストは動画を開始し、再生品質を下げてPlexにストリームを変換させることです。Plexのガイドでは、動画品質を下げて480pへの変換を強制し、Plexダッシュボードの再生詳細でハードウェアアクセラレーションの指標を確認する方法が説明されています。

JellyfinやEmbyでも同じ制御された再生テストが適用されます。クライアントが直接再生できないファイルから始めるか、手動で再生品質を下げます。その後、再生情報、アクティブストリームの詳細、またはストリーム診断を開いて、セッションが直接再生、ダイレクトストリーム、またはトランスコードかを確認します。

ランダムなファイルを唯一のハードウェアトランスコードテストとして使わないでください。テレビで直接再生が完璧にできる映画はトランスコーダーに触れないかもしれませんが、同じファイルがブラウザ、リモートアクセス、モバイルデータ、または字幕有効時にトランスコードされることがあります。テストファイルは明確なビフォーアフターの条件を作るべきです。

ダッシュボードは最初の手がかり

メディアサーバーダッシュボードは、アクティブな再生セッションをサーバーのストリーム解釈に結びつけるため、最初の有用な手がかりです。しかし、それはあくまでダッシュボードの手がかりであり、完全な証明ではありません。

Plex: ハードウェアデコードとエンコードを確認する

Plexでトランスコードされていることがわかっているストリームを開始し、Webダッシュボードを開いて「Now Playing」の詳細を展開します。Plexは、ハードウェアアクセラレーションが使用されている場合、展開された再生詳細のビデオフォーマットの横に(hw)が表示されると説明しています。

強いPlexのサインは、ビデオパスに(hw)が付いたトランスコード行の表示です。ソースファイル、ハードウェア、OS、Plexのバージョンによって、ハードウェアはデコード、エンコード、またはその両方に関与している場合があります。重要なのは、メインのNow Playingカードだけでなくストリーム詳細を展開して確認することです。

PlexでDirect Playが表示されている場合、ハードウェアトランスコードは表示されません。Plexでトランスコードが表示されていても(hw)がなければ、ソフトウェアトランスコードの可能性があります。Plexで(hw)が表示されていてもCPUがまだ動作している場合、それが必ずしも失敗を意味するわけではありません。オーディオトランスコード、字幕、リマックス、トーンマッピングなどの段階はまだCPUを使うことがあります。

JellyfinとEmby：ストリーム詳細を確認しよう

Jellyfinでは、アクティブなストリームや再生情報でトランスコード理由とハードウェアアクセラレーション方法を確認してください。Jellyfinのハードウェアアクセラレーション方法のドキュメントによると、Jellyfinは修正されたFFmpegトランスコーダーを使用し、Intel QSV、NVIDIA NVDEC / NVENC、AMD AMF、VA-API、VideoToolboxなどの方法で統合GPUやディスクリートGPUを利用できます。

重要な質問はトランスコードしているかどうかだけでなく、どの方法が使われているかです。再生詳細にQSV、VAAPI、NVENC、AMF、VideoToolboxが表示されていれば、一般的なトランスコードラベルよりも強い証拠です。ストリーム詳細にソフトウェアトランスコードのみが表示されている場合、GPUはそのストリームを処理していない可能性が高いです。

ダッシュボードのチェックは、もう一つの質問と組み合わせると特に有用です：なぜサーバーがトランスコードしているのか? コーデックの不一致、ビットレート制限、字幕の焼き込み、HDRトーンマッピング、非対応のオーディオストリーム、リモートの品質設定などが、それぞれ異なるパイプラインを引き起こす可能性があります。だから同じサーバーでも2つのファイルが異なる動作をするのです。

ホストGPUアクティビティは2番目の証拠レイヤーです

次のレイヤーはホストレベルのGPUアクティビティです。GPUやiGPUがライブトランスコードを実際に支援している場合、ストリームが動作中はホストがビデオのエンコードまたはデコードエンジンのアクティビティを通常表示します。

このレイヤーは重要です。なぜならダッシュボードを簡素化できるからです。ダッシュボードはハードウェアの関与を示すかもしれませんが、どの段階が加速されているかは説明しません。ホストはストリーム開始時にビデオエンジンがアクティブになり、ストリーム停止時に落ち着くかどうかを示せます。

NVIDIA: GPU使用率だけでなくビデオエンジンも確認しよう

NVIDIAシステムの場合、テストトランスコード実行中にnvidia-smiを使用します。メディアサーバーまたはトランスコーダープロセス、GPUメモリ使用量、エンコーダー/デコーダーのアクティビティを確認します。NVIDIAのドキュメントにはエンコーダーとデコーダーの利用状況が含まれており、プロセス監視でプロセスごとのGPU使用率も確認できます。

基本的なNVIDIAチェックは以下の通りです：

nvidia-smi

より積極的な監視ビューには、以下を使用します：

nvidia-smi dmon

よくある誤りは、一般的なGPU使用率だけを監視することです。ビデオトランスコードは3Dレンダリング、ゲーム、AI計算とは異なる場合があります。ビデオのエンコード/デコードアクティビティ、関連するメディアサーバープロセス、そしてタイミングがアクティブなストリームと一致しているかを特に確認してください。

Intel Quick Sync：iGPUが実際に稼働していることを確認

LinuxのIntel iGPU / Quick Syncシステムでは、intel_gpu_topが最もわかりやすいツールです。強制トランスコードを開始し、ビデオエンジンにアクティビティがあるか監視します。メディアサーバーダッシュボードがハードウェアアクセラレーションが有効と表示しているのにIntelビデオエンジンがアイドル状態の場合、サーバーが誤ったデバイスを使用しているか、権限が不足しているか、ソフトウェアにフォールバックしている可能性があります。

Linuxがグラフィックスデバイスを認識しているかどうかも確認できます：

lspci -nn | grep -Ei "3d|display|vga"

Jellyfinのハードウェアアクセラレーションのドキュメントは、利用可能なアクセラレーション経路がデバイス、ドライバー、プラットフォームのサポートに依存するため、アクセラレーション方法を選択する前にハードウェア固有のチェックを推奨しています。

AMD：GPUアクティビティをアクティブなストリームに合わせる

AMDシステムの場合、正確な監視ツールはOSとドライバースタックによって異なります。Linuxでは、ユーザーはしばしばradeontopやプラットフォームのダッシュボードなどのツールでVAAPI / AMF関連のアクティビティを確認します。検証ロジックは同じで、強制トランスコードを開始し、ビデオ関連のGPUアクティビティを監視し、ストリームを停止してアクティビティが減少するかを確認します。

すべてのツールがビデオアクセラレーションを同じようにラベル付けするとは限りません。実際の問題は、そのストリーム中にアクティビティがあるかどうか、そしてそのタイミングがメディアサーバーダッシュボードと一致するかどうかです。

FFmpegログは実際のトランスコード経路を示す

ダッシュボードとホストのメトリクスが一致しない場合、通常はFFmpegログを確認します。ほとんどのメディアサーバーはトランスコードにFFmpegまたは修正されたFFmpegビルドを使用しているため、ログからストリームがハードウェア経路を使用したか、ソフトウェアにフォールバックしたか、デバイスへのアクセスに失敗したかがわかります。

ログ内で、ハードウェアパスには以下のような名前が含まれることがあります：

h264_nvenc
hevc_nvenc
h264_qsv
hevc_qsv
h264_vaapi
hevc_vaapi

ソフトウェアエンコードパスにはしばしば以下が含まれます：

libx264
libx265

FFmpegのドキュメントはFFmpegのハードウェアアクセラレーションパスオプションを説明しており、vaapi、qsv、d3d11va、dxva2、videotoolboxなどの方法があります。また、実際の利用可能性は選択された方法、デコーダーのサポート、ハードウェア、ドライバー環境に依存すると説明しています。

この区別は重要です。FFmpegがハードウェアアクセラレーション方式でビルドされていることは、現在のストリームがそれを使ったことを証明しません。ログには実際のコーデックパス、デバイスアクセス、FFmpegが静かにソフトウェアにフォールバックしたかどうかが示されるべきです。

メディアサーバーのトランスコードログにlibx264やlibx265のようなソフトウェアエンコードパスが見られることは、特にNVENC、QSV、VAAPI、AMF、VideoToolboxを期待していた場合、ソフトウェアlibx264フォールバックやソフトウェアエンコードの強い兆候であることが多いです。

ダッシュボードの証拠とホストのメトリクスが一致しない場合、Dockerや権限が最近変更された場合、あるコーデックは動作するが別のコーデックは動作しない場合、字幕やHDRトーンマッピングが結果を変える場合、ストリームが開始、バッファリング、失敗、または静かにソフトウェアトランスコーディングに切り替わる場合はログを使用してください。

部分的なハードウェアトランスコーディングは普通です

ハードウェアトランスコーディングは必ずしも全か無かではありません。ストリームはハードウェアデコードを使いながらソフトウェアエンコードを使うこともあれば、ハードウェアエンコードを使いながらソフトウェアデコードを使うこともあります。また、ビデオにはGPUアクセラレーションを使い、音声、字幕、スケーリング、リマックス、トーンマッピングはCPUを使う場合もあります。

Jellyfinのドキュメントはここで役立ちます。なぜなら、トランスコーディングパイプラインの段階をビデオデコード、デインターレース、スケーリング／フォーマット変換、HDR／DVトーンマッピング、字幕の焼き込み、ビデオエンコード、ゼロコピーに分けて説明しているからです。また、ソフトウェア、ハードウェア、ドライバーの制限により、一部の段階がGPUアクセラレーションされない場合があることも記載しています。

したがって、正しい問いはCPU使用率がゼロかどうかではありません。より良いハードウェアトランスコードの確認は、映像のデコードがハードウェアで行われているか、映像のエンコードがハードウェアで行われているか、CPU使用率が音声や字幕によるものか、ソフトウェアのみのトランスコーディングと比べて再生が改善しているか、ログにハードウェア経路またはソフトウェアフォールバックが記録されているかを確認することです。

重い映像処理段階がオフロードされ、残りのCPU作業が予想される場合、部分的なアクセラレーションでも成功と見なせます。問題となるのは、GPUに処理を期待していた段階でサーバーがソフトウェアにフォールバックした場合です。

なぜCPU使用率が高く見えるのか

高いCPU使用率が必ずしもハードウェアトランスコーディングの失敗を意味するわけではありません。映像のエンコード・デコードは再生パイプラインの一部に過ぎません。CPUは音声トランスコード、字幕の焼き込み、コンテナのリマックス、ファイルI/O、スケーリング、メタデータ処理、ネットワークオーバーヘッド、HDRトーンマッピングの一部などを担当している可能性があります。

よくある例は字幕です。クライアントが字幕形式を直接処理できない場合、サーバーが字幕を動画に焼き込むことがあります。これによりトランスコード経路が変わり、CPUに余分な負荷がかかることがあります。音声も同様の例で、ハードウェアビデオアクセラレーションが音声のトランスコードをGPUで行うことを意味するわけではありません。

CPU負荷の高い段階を見分ける良い方法は、いくつかの制御されたファイルをテストすることです。字幕なしのシンプルなH.264ファイル、HEVCファイル、字幕を無効にしたファイル、字幕を有効にしたファイル、ブラウザで再生したファイル、テレビやモバイルクライアントで再生したファイルなどです。

単純なファイルでGPUの動作が確認できるが、字幕付きやHDRファイルでCPU使用率が急上昇する場合、ハードウェアトランスコーディングは動作しているものの、その特定のパイプラインにCPU負荷の高い段階がある可能性があります。

Dockerが真のボトルネックである場合

Docker環境では、ホストがGPUを認識していても、コンテナがそれを使用できるとは限りません。Plex、Jellyfin、Emby、Frigateは正常に起動し、UIも問題なく表示されても、コンテナが適切なデバイスアクセス権を持っていなければCPUにフォールバックすることがあります。

Intel Quick SyncやVAAPI経路の場合、重要なデバイスはしばしば/dev/driです。Plexのハードウェアアクセラレーションガイドでは、Dockerでのハードウェアトランスコーディングには追加の設定が必要であり、PlexのDockerセットアップではIntel Quick Sync用に関連するカーネルデバイスをコンテナに渡す必要があると記載されています。

NVIDIAシステムの場合、DockerのGPUアクセスには--gpus、NVIDIA Container Toolkit、ランタイム設定、ドライバー機能が関わることがあります。NVIDIAのContainer Toolkitドキュメントは、Docker GPUアクセスを、ランタイム設定に応じて--gpusやNVIDIA_VISIBLE_DEVICESなどのオプションを通じて説明しています。

Docker Composeには独自のGPU予約モデルがあります。Dockerの公式Compose GPUサポートガイドでは、サービスがGPUデバイスを予約でき、GPU予約には機能設定が必要であることを説明しています。これは同じコンテナデバイスアクセスの問題の一部です。

ホストGPUが見えているのにメディアサーバーダッシュボードがソフトウェアトランスコードを示す場合、ホストでnvidia-smiが動作するがコンテナ内で動作しない場合、ホストに/dev/driが存在するがコンテナ内にない場合、またはコンテナのアップデートで権限、グループ、ランタイム、デバイスマッピングが変更された場合はDockerを確認してください。

コンテナ化されたメディアサーバーは、ホストだけでなくコンテナ内部からのデバイスアクセスを証明すべきです。そうでなければ、誤ったレイヤーをデバッグしている可能性があります。

Plex、Jellyfin、Emby向けのよりクリーンなテストシーケンス

多くの設定を一度に変えるのではなく、1つのクリーンなテストシーケンスを使用します。安定したシーケンスはハードウェアトランスコードの証明とデバッグを容易にします。

1. トランスコードを引き起こす可能性のあるビデオファイルを選びます。
2. 品質を制御できるクライアントで再生を開始します。
3. 再生品質を下げてトランスコードを強制します。
4. メディアサーバーダッシュボードを開きます。
5. ストリームがトランスコードであり、Direct Playではないことを確認します。
6. ダッシュボードが表示しているか確認します。 (hw) またはハードウェアの方法で確認します。
7. ストリーム中にホストのGPU / iGPUビデオエンジンの動作を監視します。
8. そのセッションのFFmpegトランスコードログを開きます。
9. ハードウェアコーデックのパスやソフトウェアフォールバックを確認します。
10. 字幕を無効にして再度テストします。
11. ストリームを停止し、GPUの動作が低下することを確認します。
12. 最初のテストが問題なければ、異なるコーデックまたはクライアントを1つだけ変えて繰り返してください。

この手順は、最も一般的な誤診断を避けます：品質、字幕、クライアントタイプ、ドライバー設定、Dockerマッピングを一度にすべて変更することです。結果が変わった場合、どの変数が原因かを把握できるはずです。

合格するハードウェアトランスコードの見た目

合格するハードウェアトランスコードは一つのスクリーンショットではありません。互いに一致する一連のシグナルです。

最も強力な証拠は、ダッシュボード、ホストメトリクス、ログ、再生結果で同じアクティブストリームが一致することです。どれか一つの層が異なる場合は、設定を変更する前にテストを簡素化してください。

同じチェックがビデオAIとカメラワークフローに適用される方法

同じ検証の考え方はPlexやJellyfinを超えて適用されます。ビデオAIやカメラワークフローも、実際のハードウェアパス、コンテナのデバイスアクセス、モデルエンドポイント、ログ出力、最終分析結果が正しく機能していない場合でもインストール済みに見えることがあります。

ZimaOSカメラAIワークフローは有用な例です。ZimaSpaceのFrigateとOllamaカメラAIのガイドでは、RTSPカメラ、物体検出、ローカルモデルエンドポイント、スナップショット、ストレージ、デバイスマッピング、コンテナ権限、ログを含むセットアップが示されています。そのようなワークフローでは、インストールされているUIは最初の層に過ぎず、実際のチェックはストリームが届くか、コンテナが正しいデバイスにアクセスできるか、モデルエンドポイントが応答するか、ログが正常か、期待される検出や説明の出力があるかどうかです。

これはPlexのハードウェアトランスコーディングとは異なりますが、セルフホストルールは似ています：単一の設定を信用しないこと。ビデオワークロードでは、アクティブなストリーム、デバイスアクセス、ログ、モデルやエンコーダーパス、最終出力を確認してください。

ZimaCube 2 AI NASのようなプライベートクラウドやホームサーバーのセットアップは、ストレージ、GPUまたはiGPUアクセス、コンテナ、ログを一つのシステムとして扱うことで、より豊かなセルフホストメディアやビデオAIワークフローをサポートできます。重要なのは製品名ではなく、検証パターンです。UIが有効と表示しても、ストリーム、デバイス、ログ、出力が一致しなければ、ワークロードはまだ完全に検証されていません。

よくある質問

Plexのハードウェアトランスコーディングが動作しているかどうかはどうやってわかりますか？

再生品質を下げてPlexトランスコードを強制し、Plex Web Appを開いてダッシュボードに移動し、Now Playingを展開してビデオフォーマットの横に(hw)があるか確認します。より確実な証拠として、ホストのGPUアクティビティとPlexトランスコードログも確認してください。

Jellyfinでハードウェアトランスコーディングをどうやって確認しますか？

Jellyfinトランスコーディングが必要なストリームを開始し、再生情報またはアクティブストリームの詳細を開きます。トランスコーディングの理由とQSV、VAAPI、NVENC、AMF、VideoToolboxなどのハードウェアアクセラレーション方式を探します。ダッシュボードが不明瞭な場合は、ホストのGPUアクティビティとFFmpegログを確認してください。

ハードウェアトランスコーディングが有効でもCPU使用率が高いのはなぜですか？

CPU使用率が高いままになるのは、ハードウェアアクセラレーションがビデオのデコードまたはエンコードのみをカバーしている可能性があるためです。オーディオトランスコーディング、字幕の焼き込み、リマックス、スケーリング、トーンマッピング、ファイルI/O、一部のフィルターは依然としてCPUを使用します。ハードウェアトランスコーディングが失敗したと決めつける前にログを確認してください。

部分的なハードウェアトランスコーディングとは何ですか？

部分的なハードウェアトランスコーディングとは、パイプラインの一部だけがアクセラレーションされている状態を指します。例えば、GPUがソースビデオをデコードし、CPUが字幕、オーディオ、または他の段階を処理している場合です。また、ハードウェアエンコードは有効でもデコードがソフトウェアにフォールバックしている場合も含まれます。

ハードウェアトランスコーディングがホストでは動作するのにDocker内で動作しない場合、何を確認すればよいですか？

コンテナのデバイスアクセスを確認してください。IntelのiGPUの場合、/dev/driがコンテナに渡されていることを確認します。NVIDIAの場合は、ホストドライバー、NVIDIA Container Toolkit、Dockerランタイム、--gpusアクセス、およびビデオ関連のドライバー機能を確認してください。また、コンテナ内のメディアサーバーユーザーがデバイスにアクセスする権限を持っているかもチェックしてください。

ハードウェアトランスコーディングは、アクティブなストリームが実際にトランスコードしている場合にのみ機能します。メディアサーバーがハードウェアアクセラレーションを報告し、ホストがビデオのエンコードまたはデコードのアクティビティを示し、ログがソフトウェアのフォールバックではなく期待されるハードウェアパスを確認している必要があります。どれか一つでも異なれば、よりシンプルなファイルでテストし、変数を減らし、パイプラインを段階的に検証してください。