同じ4KストリームにおけるハードウェアアクセラレーションとCPUトランスコード

同じリアルタイム4Kストリームであれば、GPUまたはメディアエンジンが必要なデコード、フィルター、トーンマッピング、エンコードのすべての段階に対応している場合、ハードウェアアクセラレーションの方が通常、メディアサーバーに適した選択です。最も負荷の高い動画処理を汎用CPUコアから移し、CPUへの負荷を軽減して、同時処理の余裕を増やします。ハードウェア経路が必要な形式やフィルターに対応していない場合、またはリアルタイムスループットより圧縮効率を優先する単発のソフトウェアエンコードでは、CPUトランスコードが引き続き有用です。比較を意味のあるものにするには、ソースファイル、目標解像度、ビットレート、クライアント、処理要件を一定に保つ必要があります。

エンジンを比較する前に4Kジョブの条件を固定する

公平な比較では、同じソースファイル、出力解像度、目標ビットレートまたは品質設定、字幕の状態、HDR/SDR要件、クライアントを使用します。これらの変数のいずれかを変更すると、ハードウェアエンコードとCPUエンコードの選択よりも、処理量が大きく変わる場合があります。

HandBrakeのパフォーマンスに関するドキュメントでは、エンコーダーのプリセット、品質目標、ビットレート、フィルターが速度に与える影響を説明しています。その制御されたエンコーダーパフォーマンス変数は、適切なテスト方法を示しています。つまり、異なるジョブ同士ではなく、一度に一つの経路を比較します。

トランスコード速度、再生の停止や遅延、CPU使用率、ビデオエンジン使用率、可能であればシステム消費電力、出力品質を記録します。どちらの経路もリアルタイムより高速なら、次に判断すべきなのは、どちらが技術的に完了できるかではなく、余裕度と効率です。

ハードウェアアクセラレーションがリアルタイムスループットテストで勝利

対応するハードウェアアクセラレーションでは、動画専用に設計された固定機能のデコードおよびエンコードブロックを使用します。これにより、マクロブロックや変換処理の一つひとつに汎用CPUの処理能力を費やす必要がなくなり、通常はメディアアプリケーション、ストレージスタック、字幕、データベース処理、その他のサービスにより多くのCPU容量を残せます。

Jellyfinでは、QSV、NVENC/NVDEC、AMF、VA-API、VideoToolboxなどのハードウェア方式を列挙し、トランスコードパイプラインの複数の段階をオフロードできる仕組みを説明しています。固定機能トランスコードパイプラインから導ける実用的な結論は、必要な処理経路全体が実際にアクセラレーションされる場合に、ハードウェアが優位になるということです。

複数のストリームが重なる場合、その効果は最大になります。4Kソースを1本リアルタイムでソフトウェアトランスコードできるCPUでも、2つ目のセッションに対応する余裕はほとんどない可能性があります。一方、適切なビデオエンジンなら、同じ一般用途CPUの予算を消費せずに、より多くの同時処理を維持できることがよくあります。

ハードウェアの経路では対応できない部分でもCPUトランスコードは柔軟性を維持する

ソフトウェアトランスコードは、特定のハードウェア世代では対応していない形式、エンコーダーオプション、フィルターも処理できます。また、圧縮時の判断を改善するためにより多くの計算を行う低速プリセットも利用できます。これはオフラインでのライブラリ作成には魅力的ですが、ライブ再生には適さないことが多い方法です。

Plexの現在のハードウェアストリーミングに関するガイダンスでは、ハードウェアの世代が出力品質に影響する可能性や、HEVCエンコードにはH.264より多くのリソースが必要であることが説明されています。その世代によって異なるハードウェア出力が境界線となります。つまり、すべてのプロセッサやGPU世代で、ハードウェアエンコーダーが同一とは限りません。

したがって、アクセラレーターで必要な処理を完了できない場合は、CPUトランスコードがフォールバックとして残ります。CPU使用率に余裕があるというだけで選ぶべきではありません。問題は、ライブ4Kセッションにおいて、追加の柔軟性が消費電力の増加と同時実行数の減少に見合うかどうかです。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

部分的なアクセラレーションでは本当のボトルネックが隠れる

セッション上はハードウェアエンコードが行われていても、デコード、字幕の焼き付け、音声処理、スケーリング、その他のフィルターをCPUが処理している場合があります。その場合、システムが比較しているのは、完全なハードウェアパイプラインと完全なCPUパイプラインではなく、ソフトウェア処理の段階が異なる2つのハイブリッドです。

NVIDIAのVideo Codec SDKは、NVDECとNVENCの機能を分けて扱い、コーデックごとのハードウェア対応を文書化しています。その個別のハードウェアデコードおよびエンコード機能は、ハードウェアエンコードが正常に動作しても、ソースのデコードまでオフロードされているとは限らない理由を示しています。

CPUとビデオエンジンの動作を両方監視し、トランスコードログを確認します。ソフトウェアフィルターがボトルネックの場合、より高速なハードウェアエンコーダーにアップグレードしても、そのフィルターにアクセラレーション対応の経路が追加されるか、再生要件が変わるまでは再生性能が改善しない可能性があります。

品質は実際に使用する配信ビットレートで比較する必要がある

ソフトウェアエンコーダーは低速なプリセットを使って圧縮効率をより積極的に追求できますが、固定機能ハードウェアはスループットと予測可能な遅延に最適化されています。新しいハードウェアエンコーダーは大幅に改善されているため、古い世代の比較から品質差を推測せず、実際に測定してください。

IntelのQuick Syncドキュメントでは、この機能がプロセッサー・グラフィックスに実装されており、使用するCPUそのものが対応している必要があると説明されています。Quick Syncの世代を正確に確認することが重要なのは、「ハードウェアアクセラレーション」という言葉が、プラットフォームの世代によって大きく異なるメディアエンジンを指す場合があるためです。

ライブ再生では、リモートユーザーやクライアントが受け取るビットレートで、実際に見える画質を比較してください。どちらも家庭で求める画質基準を満たすなら、視聴者には見えないエンコーダー指標を最適化するのではなく、より多くのリソース余力を残せる経路を選びましょう。

電力と同時実行数が、1ストリームのテストをサーバーの判断へと変える

同じ4KストリームでもCPU上では継続的に処理できる場合がありますが、常時稼働サーバーのデフォルトとしては適さない可能性があります。ソフトウェアの使用率が高いと、2本目のストリーム、ライブラリのスキャン、バックアップ、その他のサービスが再生と競合する可能性が高まります。ハードウェアアクセラレーションを使えば、こうした処理が重なる場合にも、より大きなスケジューリングの余裕を確保できます。

ZimaSpaceのハードウェアトランスコーディングが実際に動作しているかを確認する方法では、設定だけを信頼せず、アクティブなストリーム、ホストのアクセラレーターの動作状況、ログを確認することを推奨しています。ハードウェア経路に効率面での優位性を付ける前に、同じ方法で実証してください。

ハードウェアアクセラレーションによるストリームが1本は安定しているのに、2本目で失敗するなら、実際の同時実行数の限界を見つけたことになります。CPUソフトウェアトランスコードが、他のすべてのサービスをアイドル状態にしたときだけ動作するなら、デモには成功していても、サーバーのワークロードには対応できていません。

よくある質問

ハードウェアトランスコードは、常にCPUトランスコードより画質が悪いのですか？

いいえ。品質は、ハードウェアの世代、コーデック、エンコーダー設定、目標ビットレート、比較に使用するソフトウェアエンコーダーのプリセットによって決まります。低速のソフトウェアプリセットは、圧縮効率を高める代わりに、はるかに多くの計算量を必要とすることがあります。一方、近年のハードウェアエンジンでも、リアルタイムで非常に良好な出力を生成できます。実際にユーザーが見るビットレートと表示サイズで比較してください。

ハードウェアアクセラレーションを有効にしているのに、CPU使用率が高いままなのはなぜですか？

パイプラインの一部しかアクセラレーションされない場合があります。音声変換、字幕、トーンマッピング、スケーリング、サポートされていないデコード形式、その他のフィルターはCPU上で処理され続けることがあります。ストリームのログとホストのエンジン稼働状況を確認し、どの段階がまだソフトウェア処理に依存しているかを特定してください。

サーバーにアイドル状態のコアが多数ある場合、CPUトランスコードを使うべきですか？

ソフトウェア経路が、最大同時負荷に対して十分な余裕を持ってリアルタイム速度を達成し、かつ柔軟性や出力特性を重視する場合に限ります。アイドル状態のコアは、データベース、スキャン、バックアップ、追加セッションのための余力として役立ちます。単に利用可能だからという理由で消費すると、サーバーの耐障害性が低下する可能性があります。

ライブ4Kではハードウェアを優先し、CPUは例外的な経路として使う

4Kの入力から出力までの経路全体が完全にサポートされ、ライブ処理のスループット、同時実行数、サーバーの余裕が重要な場合は、ハードウェアアクセラレーションを選びます。これは、さまざまなクライアントに常時配信するメディアサーバーに適した一般的な選択です。

必要なコーデックや処理段階をハードウェアがサポートできない場合、またはオフライン処理で、ソフトウェアのプリセットによるエンコード時間の大幅な延長を意図的に受け入れる場合は、CPUトランスコードを選びます。これはワークロード上の例外であり、固定機能の動画ハードウェアが不要だという根拠にはなりません。

ストリームがすでにダイレクト再生されているなら、この2つの経路の比較は完全にやめてください。動画変換が不要なセッションでは、ハードウェアトランスコードもCPUトランスコードも改善にはつながりません。ダイレクト再生を維持し、避けられない変換にサーバーのリソースを使いましょう。