メディアサーバーが再生中に高いCPU使用率を示すのはなぜですか？

メディア再生中の高CPU使用率は通常、サーバーが元のファイルを送信する以上の処理をしていることを意味します。動画のデコードと再エンコード、すべてのフレームへの字幕の焼き込み、SDRクライアント向けのHDR変換、解像度のダウンスケール、またはリモート接続用の低ビットレートストリームの作成などが考えられます。

ただし、高CPUは必ずしもプロセッサが弱いことを証明するわけではありません。ハードウェアアクセラレーションはパイプラインの一部でのみ動作している場合や、バックグラウンド分析タスクが同時に実行されている場合、または複数のセッションが同じリソースを競合している場合があります。最初のステップは再生モードと実際にCPUを消費しているプロセスを特定することです。

ハードウェアを責める前に再生モードを確認してください

問題のストリームがアクティブな間にサーバーダッシュボードを開いてください。Plex、Jellyfin、Embyなどのプラットフォームは通常、セッションがダイレクトプレイ、ダイレクトストリームまたはリマックス、オーディオ変換、または完全な動画トランスコードのどれを使用しているかを表示します。

ダイレクトプレイは元のコンテナ、動画、オーディオ、および対応する字幕トラックをクライアントに送信します。リマックスやダイレクトストリームは配信フォーマットの一部のみを変更し、多くの場合動画の再エンコードは行いません。動画トランスコードはソースをデコードし新しい動画ストリームを作成するため、持続的な高CPU使用の最も可能性の高い原因です。

この区別が次のテストを決定します。ソフトウェアで処理が行われている場合、確認された動画トランスコード中の高CPUは予想されます。ダイレクトプレイ中の高CPUは通常、別のセッション、バックグラウンド分析タスク、またはサーバー上で動作している別のプロセスを示します。

ソフトウェアによる動画トランスコードが主な原因であることが多いです

クライアントが元のコーデック、プロファイル、解像度、ビットレート、コンテナ、オーディオ、または字幕の組み合わせを受け入れられない場合、メディアサーバーは動画をトランスコードします。また、ユーザーが低い再生品質を選択した場合にもトランスコードが行われることがあります。

サーバーはソースフレームをデコードし、必要なフィルターを適用し、画像をリサイズまたは変換し、新しいストリームを再生に追いつく速さでエンコードしなければなりません。4K HEVCソースを低解像度のH.264に変換するには、元のファイルをそのまま配信するよりもはるかに多くの処理が必要です。

これらの処理がすべて汎用CPUコアで行われる場合、高い使用率は正常なことがあります。重要なのはトランスコーダーが再生速度より速く処理できているかどうかです。CPUが忙しくてもスムーズに再生されているのと、CPUが限界まで使われてクライアントが繰り返しバッファリングするのは異なります。

CPUが必要かどうかはクライアントが決めることが多い

同じファイルでも、あるストリーミングボックスではダイレクトプレイできるのに、ブラウザ、テレビアプリ、スマホ、古いプレーヤーでは完全なトランスコードが発生することがあります。各クライアントはコンテナ、動画プロファイル、ビット深度、オーディオフォーマット、字幕、最大ビットレートの組み合わせが異なります。

動画コーデックがサポートされていても、互換性のないオーディオトラックや字幕フォーマットが再生経路を変えることがあります。クライアントはHEVC動画を受け入れてもTrueHDオーディオの変換が必要だったり、選択された字幕がローカルでレンダリングできない場合は動画のトランスコードが必要になることがあります。

同じファイルを2つのクライアントで、オーディオトラック、字幕選択、品質設定を変えずに比較してください。高いCPU使用率が特定のクライアントに伴う場合は、サーバーのハードウェアを交換する前にそのクライアントの能力と設定に注目してください。

低品質はサーバーのCPU使用率を増加させることがある

低い品質設定を選ぶとサーバーの負荷が減ると思われがちですが、実際には要求された解像度やビットレートがソースと異なる場合、サーバーは通常新しいストリームを作成しなければなりません。

例えば、4Kの高ビットレートファイルから8 Mbpsの1080pを要求すると、デコード、スケーリング、再エンコードが必要になります。クライアントがソースフォーマットをサポートし、ネットワークがそのビットレートを運べる場合、「オリジナル品質」を選択するとダイレクトプレイが可能になることがあります。

ローカルネットワーク上で診断テストとして「オリジナル品質」を使用してください。これは万能の解決策ではありません。互換性のないコーデック、帯域幅不足、サポートされていない字幕があるクライアントは変換が必要な場合があります。

字幕の焼き付けは軽いストリームを重いものに変えることがある

字幕を有効にした後だけCPU使用率が上がる場合、選択された字幕トラックが強い疑い対象です。SRTのようなテキスト字幕はクライアントでレンダリングされることが多いですが、PGSやVobSubは画像ベースのフォーマットです。ASSやSSAはテキストを含みますが、一部のクライアントが再現できないスタイリングや位置指定が含まれることがあります。

クライアントが字幕トラックをレンダリングできない場合、サーバーは字幕を映像に焼き付けることがあります。これは動画のデコード、各フレームへの字幕の合成、新しい動画ストリームのエンコードを必要とします。

Plexはハードウェアトランスコーディング中の字幕焼き込みパフォーマンスの改善に特に取り組んでおり、その結果はOS、GPUの種類、トーンマッピングがパイプラインに残っているかどうかによって異なります。これが同じ字幕テストでもサーバーごとにCPU使用率が異なる理由です。

字幕トラックを別途テストしてください

同じシーンを字幕なしで再生してみてください。CPU使用率がすぐに下がり、セッションがダイレクトプレイに戻る場合、追加の負荷を引き起こしているのは字幕経路であり、元の動画だけが原因ではありません。

次に、外部のSRTトラック、別の字幕言語、またはより広範な字幕サポートを持つクライアントを試してください。また、サーバーが単純な字幕配信ではなく字幕の焼き込みを報告しているかどうかも確認してください。

すべての字幕フォーマットが同じ負荷であるとは限りません。スタイル付きテキストトラックはあるクライアントでは簡単でも、別のクライアントでは完全な動画処理が必要になることがあります。また、Blu-rayの画像字幕は焼き込みなしで配信するのが特に難しい場合があります。

GPUが動作しているからといってパイプライン全体が加速されているわけではありません

CPU使用率が高いままGPUの動作が見られることがあります。ハードウェアアクセラレーションは動画のデコードとエンコードを行っていても、CPUは字幕レンダリング、オーディオ変換、スケーリング、トーンマッピング、または他のフィルター処理を担当している場合があります。

コミュニティのトラブルシューティング事例では、字幕の焼き込みとオーディオ変換による高いCPU使用率と並行してGPUトランスコーディングが動作していることが示されました。この事例はすべての現行バージョンに当てはまる固定ルールとして扱うべきではありませんが、GPU利用率だけでは不十分な証拠であることを示しています。

GPUのデコードおよびエンコードエンジンの両方を確認し、次にトランスコーダーログでソフトウェアフィルターを調べてください。字幕をオフにし、互換性のあるオーディオトラックを選択し、トーンマッピングをテストから除外した状態でCPU使用率を比較します。

ハードウェアアクセラレーションはソフトウェアにフォールバックすることがあります

ホストドライバー、デバイス権限、ランタイム、または選択されたコーデックが正しく動作していなくても、サーバーインターフェースでハードウェアアクセラレーションオプションを有効にできます。

一部のソースフォーマットはGPUを正常に使用できる場合がありますが、他のフォーマットはCPUにフォールバックすることがあります。GPUはH.264やHEVC Mainをサポートしていても、特定のファイルに必要な正確なビット深度、クロマフォーマット、エンコードターゲット、またはトーンマッピング経路をサポートしていない場合があります。

既知のトランスコードを強制実行し、サーバーをリアルタイムで監視してください。ハードウェアデコーダーとエンコーダーがアクティブであることを確認し、トランスコーダーのコマンドを検査し、有効化チェックボックスだけに頼らず初期化失敗やソフトウェアフォールバックのメッセージを探してください。

Dockerは別のGPUアクセスレイヤーを追加します。

メディアサーバーがDockerで動作している場合、ホストでGPUを検出しても、アプリケーションがコンテナ内でGPUを使用できるとは限りません。コンテナにはデバイス、互換性のあるユーザースペースライブラリ、正しいランタイム、ビデオ機能へのアクセス権限が必要です。

NVIDIA環境では、まずホストドライバーを確認し、DockerがNVIDIAランタイムを認識しているか検証し、コンテナ内に必要なライブラリとデバイスが存在するかをチェックし、強制トランスコード中のエンコーダーの動作を観察することが有効な検証手順です。コンテナが nvidia-smi 実行環境にメディアサーバーが必要とするライブラリや機能が欠けている場合があります。

実用的なDockerセットアップでは、Plexコンテナ内でNVIDIAランタイム、ユーザースペースライブラリ、デバイスの露出、エンコーダーの動作を検証する必要があります。特権モードを恒久的なショートカットとして使わず、サービスに必要なリソースだけを公開してください。

仮想マシンは同じ失敗パターンを引き起こすことがあります。

仮想マシンはディスプレイアダプターを検出しても、メディアトランスコーディングに必要なハードウェアのエンコード・デコード機能にアクセスできない場合があります。GPUパススルー、メディエーテッドデバイス、ドライバー、ゲストの権限が結果に影響します。

ゲストOS内でGPUを検証し、その後メディアサーバープロセスからも検証してください。ホストレベルのGPUアクティビティは、ゲストアプリケーションが意図したエンジンを使用していることを証明しません。

ネイティブインストールでハードウェアアクセラレーションを使用しているのに、同じ構成のVMインストールでCPU使用率が高い場合は、コーデック設定を変更したりライブラリを再エンコードする前に、デバイスの露出状況とログを比較してください。

HDRトーンマッピングはCPUにかなりの負荷をかけることがあります。

HDRメディアがSDRディスプレイや元のHDRストリームを受け入れられないクライアントで再生される場合、サーバーは通常のトランスコーディングに加えてトーンマッピングを行う必要があります。

パイプラインには10ビットデコード、カラースペース変換、輝度マッピング、スケーリング、字幕合成、エンコードが含まれることがあります。ソースコーデックのハードウェアサポートがあっても、これらすべての段階がGPU上で処理されるとは限りません。

HDR対応クライアントで同じファイルをテストし、SDR出力と比較してください。通常のSDRトランスコードは効率的でも、HDRからSDRへのセッションで高いCPUを使用する場合は、すべての4Kメディアを同等とみなすのではなく、トーンマッピングの方法とハードウェアサポートを調査してください。

オーディオ変換は通常、ビデオトランスコーディングほど重くない

TrueHD、DTS、マルチチャンネルオーディオ、またはサポートされていないオーディオコーデックは、クライアントが再生可能な形式に変換されることがあります。サーバーはサラウンドサウンドをステレオにダウンミックスすることもあります。

オーディオトランスコーディングは処理能力を消費しますが、通常はビデオストリーム全体のデコードと再エンコードよりも軽いです。コンテナのリマックスもビデオストリームを保持し、通常はビデオ変換よりもはるかに少ない計算量で済みます。

ダッシュボードがオーディオトランスコーディングのみを報告していてもCPUが限界近くにある場合は、字幕処理、バックグラウンド分析、別のアクティブセッション、または別のトランスコーダープロセスを確認してください。表示されているオーディオラベルだけで全負荷を説明しているとは限りません。

高いCPU使用率のDirect Playは通常、別のタスクが実行されていることを意味する

Direct Playでもファイルの読み込み、認証、アプリケーションロジック、ネットワーク配信が必要なため、CPU使用率は完全にゼロにはなりません。通常、ソフトウェアトランスコードに伴う重いビデオ処理は必要ありません。

Plexはイントロとクレジット検出、プレビューサムネイル、音声分析、コマーシャル検出、メディア最適化、ダウンロード準備にかなりのCPUを消費します。これらのジョブの一部は、誰も積極的にメディアを視聴していない場合でもトランスコーダーを呼び出します。

合計CPUグラフだけでなく、オペレーティングシステムのプロセスリストを確認してください。現在のストリームのトランスコーダー、スケジュールされた分析プロセス、ライブラリスキャナー、または無関係なコンテナのどれが原因かを特定します。

スケジュールされた分析は再生負荷のように見えることがある

誰かが視聴を開始した直後にバックグラウンドジョブが始まることがあり、再生自体がCPUスパイクの原因であるかのように見えることがあります。メンテナンスウィンドウは通常、夜間や新しいコンテンツが追加された直後に実行されます。

あるUnraidのディスカッションでは、アイドル状態のCPU負荷がスケジュールされたメディア分析および後にイントロとクレジット検出に起因すると追跡されました。これはすべてのアイドル負荷ケースが同じ原因であるという証明ではなく、コミュニティの一例です。

プレビュー生成、一部検出、クレジット検出、最適化、詳細なメディア分析を一時的に停止してください。アクティブなストリームを変更せずにCPU使用率が下がる場合は、再生設定を変更する代わりにそれらのタスクを別のメンテナンス時間帯に移動してください。

複数のストリームは異なる種類の作業を掛け合わせます

1つのDirect Playセッションは主にストレージとネットワークの負荷を増やします。1つのオーディオトランスコードはより小さな変換作業を追加します。1つのソフトウェア4Kビデオトランスコードは複数の直接ストリームよりもはるかに多くの計算資源を消費することがあります。

別のユーザーが再生を開始したら、各セッションを個別に検査してください。2人のユーザーが必ずしも同じ作業負荷を2倍にするわけではありません。1人はDirect Playし、もう1人はHDRトランスコードに字幕を焼き込んでいるかもしれません。

CPU、GPU、ネットワーク、ディスク遅延、トランスコード速度を監視しながら、テストセッションを一つずつ追加してください。これにより、実際の制限がソフトウェアエンコード、ハードウェアエンコーダー容量、ストレージ競合、または総帯域幅のどれかが明らかになります。

ライブTVは追加の処理を必要とすることがあります

ライブTVは、再生クライアントが直接受け入れられないコーデック、解像度、インターレース形式、またはビットレートで届くことがあります。サーバーはデインターレース、ビデオ変換、オーディオ変更、または低ビットレートストリームの作成が必要になる場合があります。

これらの操作により、ライブ再生はDirect Playする通常の映画よりもCPU負荷が高くなることがあります。録画やコマーシャル分析も視聴と並行して実行され、サーバーの負荷が増加します。

ライブセッションのソースコーデック、デインターレース状態、再生モード、選択された品質を、保存されたメディアライブラリとは別に確認してください。ライブTVの問題は、すべてのローカルファイルが同じハードウェアを必要とすることを証明しません。

リモート再生はしばしば新しいビットレートを強制します

高ビットレートのファイルはホームLAN内でDirect Playできるかもしれませんが、サーバーの利用可能なインターネットアップロード速度を超えることがあります。その場合、リモートクライアントまたはサーバーの制限により、より小さいストリームが要求されます。

ビットレートを下げるということは、通常サーバーが新しいビデオ出力を作成しなければならないことを意味します。そのため、同じクライアントが自宅でほとんどサーバーの計算資源を使わなくても、リモート再生中にCPU使用率が上がることがあります。

ソースのビットレートを持続可能なアップロード容量およびクライアントのリモート品質設定と比較してください。ストリームのビットレートを下げるとソフトウェアトランスコードが発生する場合、正しく設定されたハードウェアアクセラレーションや事前にエンコードされたリモート版がCPU負荷を軽減する可能性があります。

短時間のCPUスパイクは正常な場合があります

一部のトランスコーダーは再生位置より先に動作してバッファを作成します。CPU使用率は開始時に急上昇し、十分なセグメントが生成されると低下し、さらに出力が必要になると再び上昇することがあります。

短時間のピークでスムーズな再生と安定した温度なら修正は必ずしも必要ない。持続的な最大使用率、トランスコード速度の低下、繰り返しのバッファリング、またはサーマルスロットリングはより深刻な容量問題を示す。

単一のCPUスクリーンショットに頼らず、数分間の負荷を観察する。プロセッサが固定されているか、トランスコーダーが先行しているか、温度上昇に伴いサーバーのクロック速度が低下しているかを記録する。

最初にライブラリ全体を再エンコードしないでください

すべてのファイルを広くサポートされている形式に変換すると将来のリアルタイムトランスコードを減らせるが、多くのソースで時間、追加ストレージ、別のロスのあるエンコードステップが必要になる。

字幕の焼き込み、HDRトーンマッピング、リモートビットレート制限、バックグラウンド分析、Docker内のGPUアクセス障害が原因の場合は、実際の原因に対処できないこともある。

まず、実際に使用しているクライアントで繰り返し失敗する組み合わせを特定する。問題の多いメディアに対してのみ最適化コピーを作成するか、複数バージョンのライブラリを維持するよりも簡単な場合はより高性能なクライアントを使用する。

このトラブルシューティング手順を使用する

1. 同じファイルとクライアントで高CPUセッションを再現する。
2. ダイレクトプレイ、リマックス、オーディオトランスコード、ビデオトランスコードのいずれかを記録する。
3. CPUを消費している正確なプロセスを特定する。
4. 変換の理由を記録する。
5. ローカルネットワークでオリジナル品質をテストする。
6. 字幕を無効にし、別のオーディオトラックを選択する。
7. 別のクライアントで同じファイルを再生する。
8. GPUのデコードおよびエンコードエンジンを監視する。
9. トランスコーダーまたはFFmpegログでソフトウェアフォールバックを調査する。
10. Dockerまたは仮想マシン内からGPUアクセスを確認する。
11. メディア分析、プレビュー生成、最適化ジョブを一時停止する。
12. ストリームを1つずつ追加する。
13. 温度とCPUクロック速度を確認する。
14. ボトルネックが確認されてからハードウェアをアップグレードする。

最終的なまとめ

メディア再生中の高CPUは通常、処理の決定によるものであり、それ自体が診断ではありません。完全なソフトウェアビデオトランスコードが最も一般的な原因ですが、字幕の焼き込み、HDRトーンマッピング、部分的なハードウェアアクセラレーション、リモートの品質制限、同時セッションも同様の負荷を生み出すことがあります。

まず再生モードとCPUを使用している正確なプロセスを特定してください。セッションがトランスコードの場合は、クライアントの互換性、元の品質、字幕、音声トラック、完全なハードウェアアクセラレーションパイプラインをテストします。Direct Playの場合はバックグラウンド分析や他のアクティブなタスクを調査してください。

ログと制御されたテストで必要なリアルタイム処理が利用可能な計算能力を超えていることが示されてからサーバーをアップグレードしてください。多くの高CPU使用ケースは、再生経路の変更、DockerのGPUアクセスの修正、視聴時間外の分析スケジューリング、または元のメディアをDirect Playできるクライアントの選択で解決できます。

よくある質問

なぜ字幕を有効にするとCPU使用率が増えるのですか？

クライアントが選択された字幕フォーマットをレンダリングできない場合、サーバーは字幕をすべてのビデオフレームに焼き付けます。これにはビデオのデコードと再エンコードが必要です。字幕を無効にするか、サポートされているテキストベースのトラックを選択してテストしてください。

ハードウェアトランスコードを有効にしているのにCPU使用率が高いのはなぜですか？

GPUはビデオのデコードとエンコードのみを加速し、CPUが字幕、音声、トーンマッピング、スケーリング、その他のフィルターを処理する場合があります。Dockerや仮想マシン内ではハードウェアアクセスが不完全なこともあります。

Direct PlayはCPUを使わないのですか？

いいえ。Direct Playでもファイルアクセス、ネットワーク、認証、アプリケーション処理は必要です。通常、ビデオトランスコードよりはるかに少ないCPUを使用するはずなので、持続的な高負荷がある場合はバックグラウンドジョブや他のプロセスを確認してください。

なぜストリーミング品質を下げるとCPU使用率が増えるのですか？

解像度やビットレートを下げると、通常はサーバーが新しいビデオストリームを作成する必要があります。元のファイルがDirect Play可能であった場合、低品質を選択するとセッションがトランスコードに変わり、サーバーの処理負荷が増加します。

メディアスキャンは、映画再生中にCPU使用率を高くすることがありますか？

はい。プレビューサムネイルの生成、イントロやクレジットの検出、最適化、音声分析などのバックグラウンドジョブは、再生と同時に実行されることがあります。すべてのCPU使用率をアクティブなストリームに帰属させる前に、プロセスリストとスケジュールされたタスクの状態を確認してください。