リモート4Kストリーミング向けPlex：ハードウェアトランスコードでワークフローがどう変わるか
ハードウェアトランスコードにより、リモート4K Plexは配信だけのワークフローから、リアルタイムでデコード、変換、エンコード、バッファリングを行うパイプラインへと変わります。
互換性のあるリモートクライアントなら、サーバーに動画の再構築を求めず、4KをそのままDirect Playできます。帯域幅、コーデック対応、HDR処理、字幕、またはクライアントからの画質要求によって変換が必要になると、ワークフローは変わります。Plexはソースをデコードし、必要な変換を適用し、新しい出力をエンコードして、その出力がクライアントより先行する状態を維持しなければなりません。したがって、重要な境界は、リアルタイム処理の余裕を維持できなくなる最初の段階です。
ハードウェアトランスコードは、クライアントがソースを利用できない場合にのみ始まる
Plexはまず、要求された動画、音声、字幕、コンテナ、画質を、動画を変更せずに配信できるかどうかを判断します。クライアントがソースを受け入れられる場合、Direct Playは軽い経路のままです。互換性または配信条件のいずれかによってPlexが別のストリームを作成する必要が生じた場合にのみ、完全なビデオトランスコードが始まります。
実際の違いは、Direct Playとトランスコードの経路に現れます。Direct Playは元のメディアを送信しますが、トランスコードではクライアントの要求に合わせてストリームを再構築します。これにより、サーバーの仕事はバイトを読み取って送ることから、ライブ変換パイプラインを維持することへと変わります。
再生の判断を、ワークフローの最初の関門として扱ってください。GPUを選定したりトランスコード設定を変更したりする前に、実際のクライアント、選択した音声トラック、字幕、画質制限を使って、リモート要求を再現します。セッションがDirect Playなら、GPU性能は最初の制約ではありません。トランスコードされる場合は、変換によって追加される各段階を確認してください。
デコードによって、圧縮された4Kソースが処理用フレームに変換される
動画変換が始まると、ソースをそのまま通過させることはできません。デコーダーはHEVC、H.264、その他の対応コーデックから処理用フレームを再構成します。これらのフレームが、後続する拡大縮小、色変換、字幕合成、再エンコードの入力になります。これはDirect Playでは不要な、最初の負荷の高い計算処理です。
ソースのコーデックやビット深度によって負荷の高いデコード経路が必要になると、4Kワークフローはさらに難しくなります。そのため、プロセッサを比較する前に4Kコーデックの互換性を確認することが重要です。表示解像度が同じでも、4Kと表示された2つのファイルが異なるデコード処理を発生させることがあります。
CPU使用率が低いことだけを根拠にせず、デコードが意図したメディアエンジンを実際に使用しているか確認してください。部分的にアクセラレーションされたパイプラインでは、1つの段階だけがソフトウェア処理のまま残ることがあります。既知のソースファイルを1つ使い、同じトランスコードを2回実行して、ハードウェアを変更する前にCPU使用率、GPUのビデオエンジン使用状況、トランスコード速度を比較します。
変換処理がパイプラインの中間で大きな負荷になることがある
デコードされたフレームには、エンコード前にサイズ変更、HDRからSDRへのトーンマッピング、色変換、字幕の焼き付けが必要になる場合があります。これらの変換はデコードとエンコードの間に位置するため、両方のコーデックに対応したGPUでも、中間処理がサポートされていなかったり、CPUにフォールバックしたり、追加の中間サーフェスを作成する必要があったりすると、処理に苦戦する可能性があります。
基本的なトランスコードがすでに機能していても、HDRや字幕の処理によって経路は大きく変わることがあります。HDRと字幕の処理は、字幕を無効にしてSDRメディアだけを使う単純化されたベンチマークではなく、実際のクライアントが発生させる変換をテストすべきだという好例です。
SDRの拡大縮小、HDRのトーンマッピング、家庭で実際に使用する字幕形式について、個別の負荷テストケースを作成してください。1つのケースだけが遅延する場合は、サーバー全体をアップグレードするのではなく、その変換処理に絞って原因を診断します。より広範な4K環境については、4K Plexサーバーの構成も確認できます。
エンコードによって、リモート再生に適した新しい動画ストリームが作成される
変換が完了すると、Plexは処理用フレームを、リモートセッションで要求された出力コーデック、解像度、ビットレートに圧縮します。ハードウェアエンコードを利用すれば、このフレームごとに繰り返される処理を専用のメディアエンジンへ移せます。ただし、要求された出力経路がサポートされ、コンテナからアクセラレーターにアクセスできる場合に限られます。
デコードとエンコードは別々の関門として扱う必要があります。一方だけをアクセラレーションでき、もう一方には対応できないシステムもあるためです。実用的なハードウェアトランスコードの解説では、ハードウェアデコードとエンコードを、単純なオン・オフの1つの設定としてではなく、別々の段階として検証する必要があることが示されています。
ストリームが安定した後のトランスコード速度と、シークや画質変更を行ったときの速度を確認してください。エンコーダーが再生に先行し続けられなければ、ストレージとアップロード回線が正常でも、リモートセッションは最終的にバッファを使い果たします。エンコーダーに余裕がある場合は、外部の要素である一時ストレージ、ネットワーク配信、クライアントのバッファリングを確認します。
変換されたストリームが滑らかに感じられるかどうかは、バッファリングと配信によっても決まる
エンコード済みのフレームは、パッケージ化され、一時的に書き込まれるかバッファリングされ、サーバーのネットワークインターフェースを通過し、リモート経路を経由して、クライアントのバッファに十分早く到着しなければなりません。ハードウェアトランスコードは計算処理のボトルネックを1つ解消しますが、残りの配信チェーンを無制限にするわけではありません。
リモート4Kが安定するのは、変換と配信の両方が先行し続けられる場合だけです。そのため、バッファ枯渇の症状は、GPUが遅すぎる証拠と決めつけず、トランスコード速度やネットワークスループットと合わせて判断してください。
完全な受け入れテストを実施してください。再生モードを確認し、ハードウェアデコードとエンコードを検証し、必要な中で最も負荷の高い変換を実行して、トランスコード速度を観察します。そのうえで、同じセッション中にアップロード速度とクライアントの挙動を測定します。ハードウェアトランスコードは計算処理の段階を追加することでワークフローを変えますが、滑らかなリモート4K再生には、下流のすべての段階が余裕を維持することが依然として必要です。
おすすめ商品
テック＆AIハブ
もっと読む
Plexの状態とは何か、どの部分を永続化する必要があるのか？
永続的なPlexの状態情報とは、再起動や再構築後もサーバー環境を維持する情報を指します。メディアデータと一時的なトランスコードデータは、それぞれ別の役割を担います。
Plexはローカルセッションとリモートセッションで認証をどのように処理しますか？
Plexの認証はサーバーとアカウントの識別から始まり、その後、ローカルまたはリモートのネットワーク経路によって到達可能性と安全な接続の動作が決まります。
ライブラリデータが増えると、Plexの検索が遅くなるのはなぜですか？
ライブラリの増加だけが原因とは限りません。データベースのサイズを問題視する前に、クエリの形状、インデックス、キャッシュの状態、ストレージのレイテンシ、書き込みアクティビティを確認してください。
