CPUトランスコードはダイレクトプレイと比べてサーバーの消費電力をどう変えるのか？

エヴァ・ウォン

IceWhale author

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

How Does CPU Transcoding Change Server Power Compared With Direct Play? - Zima Store Online

CPUトランスコードでは、Direct Playと比べてサーバーの消費電力が大幅に増えることがあります。これは、サーバーの処理が既存のメディアストリームをほぼ読み取って送信するだけの状態から、動画をリアルタイムでデコード、フィルタリング、再エンコードする状態へ変わるためです。ただし、消費電力の増加量に一律の基準はありません。コーデック、解像度、HDRトーンマッピング、字幕の焼き付け、CPU世代、電力制限、ストリーム数によって結果は変わります。比較すべきなのは一般的な「トランスコードは電力を多く使う」という分類ではなく、同じサーバーで同じ視聴タスクを行う際に消費されるエネルギーです。

比較を実行する前に、電力の測定結果を定義する

メディアファイル、クライアント、ネットワーク経路、再生時間、サーバー構成を一定に保ちます。まずタイトルをDirect Playで再生し、次にソフトウェアCPUトランスコードを強制して、出力解像度とビットレートを固定します。これにより、CPUが新しいストリームを生成しなければならない場合に、サーバーがどれだけ余分なエネルギーを必要とするかという、1つの制御された変数として比較できます。

Plexは、Direct Playを互換性のあるメディアを変換せずに送信する方式と説明しており、トランスコードはクライアント向けにメディアを変換します。この違いから仕組みは分かりますが、特定のプロセッサでどれだけ電力差が生じるかまでは分かりません。

クロックブーストや短時間の起動処理が落ち着くよう、十分に長い再生時間で平均消費電力と総消費エネルギーを測定します。10秒間のピークは劇的に見えても、2時間の映画全体への影響は小さい可能性があります。所有コストを評価するうえでは、視聴1時間あたりのエネルギーのほうが有用です。

Direct PlayではCPUをサーバーのアイドル時に近い状態に保てる

Direct Playでも、ストレージ、ネットワーク、アプリケーション処理、必要に応じた暗号化、クライアントセッション管理は使用するため、処理がゼロになるわけではありません。重要な違いは、ファイルがすでにクライアントに適合している場合、CPUが動画の全フレームを継続的にデコードして再エンコードする必要がないことです。

Jellyfinのハードウェアガイダンスでは、メディア配信と高負荷なトランスコードを分けて説明し、変換がワークロードに含まれる場合は大幅に高い処理能力を推奨しています。そのため、あるセッションではサーバーがほぼアイドル状態でも、別のクライアントが互換性のない形式を要求すると、突然CPU負荷が限界に達することがあります。

したがって、Direct Playは、そのタイトルとクライアントにおける実用上の低消費電力の基準になります。Direct Play中もサーバーの消費電力が高い場合は、メディア配信のせいだと判断する前に、ディスク、バックグラウンドジョブ、ファン、仮想マシン、プラットフォームのアイドル動作を確認してください。

CPUトランスコードでは、ストリームの再生中ずっとパッケージ処理が増える

ソフトウェアトランスコードでは、デコード、フィルター、字幕合成、色変換、エンコードの各段階が動作するため、汎用コアがアクティブな状態に保たれます。通常、使用率が高くなると、プロセッサは深いアイドル状態から離れ、より高い持続クロックで動作します。そのため、リアルタイム変換が続く間はパッケージ電力も上昇する傾向があります。

Linuxでは、CPUパッケージ向けのRAPLエネルギーカウンターを通じて、Intelのパッケージエネルギーを計測できます。このインターフェースは瞬間的なワット数ではなく累積エネルギーを報告するため、同じ長さのDirect Play実行とソフトウェアトランスコード実行におけるCPU総エネルギーの比較に役立ちます。

これは比較結果への影響であり、固定倍率ではありません。最新の高効率CPUで軽い1080p変換を行う場合はエネルギーの増加が小さいこともあります。一方、HDR処理を伴う難しい4K HEVCからH.264へのソフトウェア変換では、多数のコアが稼働し続け、システムがまったく異なる電力状態になる可能性があります。

Featured

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

ZimaCube2

ピークワットではなく、視聴1時間あたりのエネルギーを測定する

ピーク電力から分かるのは、電源ユニットと冷却システムが短時間の負荷に耐えられるかどうかです。運用コストについては分かりません。メディアサーバーでは、再現可能な視聴時間全体で消費されたエネルギーを積算し、Direct Playと同じセッションをCPUトランスコードで実行した場合のワット時を比較します。

Intelは、RAPLをプロセッサの電力ドメイン全体における累積エネルギーの報告機能として説明しています。まずはパッケージレベルの指標として利用し、メモリ、ストレージ、ファン、電源ユニットの損失、その他のサーバー全体を含めて測定したい場合は、ワットメーターと組み合わせてください。

余分なエネルギーが頻繁かつ継続的に発生すると、判断は変わります。まれに発生する1回のトランスコードは運用上ほとんど問題にならないかもしれません。しかし、毎晩数時間ソフトウェアトランスコードを行うと、メディア互換性が実際の電力、熱、同時実行数の問題になる可能性があります。

コーデックとフィルターの選択は、解像度だけの場合より電力差を大きく左右する

2つの4Kストリームでも、CPU負荷は大きく異なることがあります。一方はコンテナの変更だけで済むかもしれませんが、もう一方ではソフトウェアによるHEVCデコード、トーンマッピング、字幕の焼き付け、スケーリング、H.264エンコードが必要になる場合があります。「4K」だけで消費電力を一意に予測できると考えず、パイプライン全体をテスト対象にしてください。

FFmpegでは、デコード、フィルター、スケール、字幕、エンコードの各段階を個別の処理ステップとして扱います。そのフィルタリングとコーデックのパイプライン制御からは、出力ビットレートが控えめでも、トランスコードにCPU負荷の高い段階が複数含まれる可能性が分かります。

特定の字幕処理やHDR処理が電力上昇の原因なら、その経路を変更することで、TDPの低いCPUを購入するより大きなエネルギー削減が得られる場合があります。持続的なCPU処理を引き起こしている正確な段階が特定され、それを回避または高速化できる状態になったら、仕組みの分析を終えてください。

同時実行数が増えると、電力差は容量の判断材料になる

ソフトウェアトランスコード1本なら許容できても、2本または3本になるとCPUが持続的な限界近くまで達することがあります。アクティブなコア数の増加、パッケージ温度の上昇、ファンの長時間動作、他のサービスへの干渉により、2本目のストリームは単独で動作させた場合以上に運用コストが高くなる可能性があります。

クライアント互換性とトランスコード電力の比較におけるZimaSpaceの検討は、有用な事前確認です。最悪のケースを前提にサーバーの規模を決める前に、回避可能な変換をなくしてください。適切に設定したクライアントならDirect Playできる形式をトランスコードするための電力は、有効な容量とはいえません。

人工的な全コア負荷テストではなく、現実的に最も混雑する同時実行時間帯を比較します。サーバーが他のサービスを維持でき、電力増加も許容範囲なら、CPUトランスコードは引き続き実用的です。しかし、夜間のセッションが繰り返しシステムを熱または電力の上限近くに保つ場合、そのワークロードは一時的な互換性処理を超え、アーキテクチャの判断が必要な段階に入っています。