Plexのハードウェアトランスコードは、互換性のない再生を滑らかにするため、ソースをデコードし、変更が必要な部分を変換し、クライアントが受け付けられる新しいストリームをエンコードします。
この結果はDirect Playではありません。Direct Playは、互換性のあるソースストリームを動画変換なしで送信します。ハードウェアトランスコードが関係するのは、要求されたクライアント、画質、字幕、音声、またはネットワーク条件では元の組み合わせを利用できないとPlexが判断した後だけです。この処理は、リクエストの不一致から新しい配信用ストリームの生成まで続くパイプラインとして理解するのが最適で、各段階に失敗する可能性があります。
パイプラインは互換性の不一致から始まる
Plexはまず、要求されたメディアをそのまま配信できるのか、再パッケージ化できるのか、それとも変換が必要なのかを判断します。Direct Playは負荷の軽い経路です。Direct Streamは互換性のあるエレメンタリーストリームを維持したままパッケージングを変更します。一方、トランスコードは、クライアントや配信条件に合わせて動画、音声、またはその両方を変更します。
この違いが重要なのは、動画トランスコードが、Direct Playを高速化したものではなく、デコードとエンコードを行う処理だからです。変換が始まると、サーバーは元のバイト列を単に読み取って転送するのではなく、ソースの新しい表現を生成します。
トリガーになるのは、クライアントのコーデック対応、要求解像度、ビットレート、HDR処理、字幕、または再生経路全体を変える音声の組み合わせなどです。そのため、仕組みを説明する際はGPUモデルではなく、まず不一致から考える必要があります。
ハードウェアデコードで圧縮ソースを処理用フレームに変換する
圧縮されたソースはデコーダーに送られ、H.264やHEVCなどの形式から動画フレームと参照状態が再構成されます。ハードウェアアクセラレーションを使うと、対応するデコード処理をメディアエンジンに移し、この段階で必要となる汎用CPUの処理量を減らせます。
ハードウェアデコードとエンコードは別々の段階です。ハードウェアデコードを実行するには、メディアエンジンが入力コーデックに対応している必要があります。対応していない場合、後続のエンコード段階でアクセラレーターを使用できる場合でも、Plexはソフトウェアデコードを行うことがあります。
このため、ダッシュボードは単一のオン/オフ表示ではなく、パイプラインの指標として読む必要があります。一部だけがアクセラレーションされている場合でも、高負荷な段階がCPU上に残ることがあります。また、CPU使用率が低いからといって、すべての変換がハードウェア上で行われているとは限りません。
スケーリング、トーンマッピング、字幕処理でフレームが変化する
デコード後、Plexは映像のサイズ変更、色処理の変更、HDRからSDRへの変換、またはエンコード前の字幕合成を行うことがあります。これらはパイプラインの中間段階であり、デコードとエンコードの両方に対応していても、ハードウェア経路を変える可能性があります。
HDRと字幕の処理によって、パイプラインの中間段階を効率的に維持できるかどうかが変わることがあります。重要なのは、特定の設定手順を示すことではありません。デコードとエンコードの間にある変換が、クライアントに単純なコーデック変更以上の処理を要求された場合、高負荷な段階になる可能性があるという点です。
HDRのトーンマッピングや字幕の焼き込みを有効にしたときだけ再生が遅くなる場合、エンコーダーがボトルネックだとは限りません。GPUの性能やビットレート設定を変更する前に、その変換を取り除いた状態で同じソースを比較してください。
ハードウェアエンコードでクライアント互換の出力を生成する
処理用フレームの準備が整うと、エンコーダーはセッション用に選択された出力形式と画質に合わせてフレームを圧縮します。アクセラレーターが要求された出力に対応し、Plexがアクセスできる場合、ハードウェア動画エンコードによってCPU負荷を大幅に軽減できます。
ハードウェアエンコードを有効にすると、実際の動画変換では、CPU使用率が高いだけでなく、ハードウェアの動作として表示されるはずです。この確認により、エンコード段階がどこで実行されているかを確かめられますが、段階の役割自体が変わるわけではありません。
その後、エンコードされた動画は、選択された音声やコンテナ、ストリームのパッケージングと組み合わされます。クライアントは要求に合った新しいストリームを受け取りますが、ストレージ上の元のソースは変更されません。
滑らかな再生には出力経路全体が重要
高速なエンコードが必要なのは変換が求められる場合だけであり、それだけでは十分ではありません。トランスコード用の一時ストレージ、ネットワーク配信、クライアントのバッファー、クライアントのデコーダーも処理速度に追いつく必要があります。そのため、高性能なGPUがフレームを時間内に処理できても、別の段階が原因で目に見えるバッファリングが発生することがあります。
ソースがすでに互換性を持っている場合、滑らかな4K再生は依然としてDirect Playの要件に左右されます。クライアントが元のファイルを受け付けられるなら、より高速な変換経路を構築するより、変換を避けるほうが通常は簡単です。
実際にクライアントとの不一致がある場合にのみ、次の判断材料としてクライアント互換性またはトランスコード性能を検討してください。ハードウェアトランスコードは互換性を補う橋渡しであり、Direct Playは同じパイプラインの最終段階ではなく、別の経路です。
テック&AIハブ
もっと読む

Plexの状態とは何か、どの部分を永続化する必要があるのか?
永続的なPlexの状態情報とは、再起動や再構築後もサーバー環境を維持する情報を指します。メディアデータと一時的なトランスコードデータは、それぞれ別の役割を担います。

Plexはローカルセッションとリモートセッションで認証をどのように処理しますか?
Plexの認証はサーバーとアカウントの識別から始まり、その後、ローカルまたはリモートのネットワーク経路によって到達可能性と安全な接続の動作が決まります。

ライブラリデータが増えると、Plexの検索が遅くなるのはなぜですか?
ライブラリの増加だけが原因とは限りません。データベースのサイズを問題視する前に、クエリの形状、インデックス、キャッシュの状態、ストレージのレイテンシ、書き込みアクティビティを確認してください。

