アップロード帯域が限られたリモートユーザー向けのダイレクトプレイとサーバートランスコード比較
アップロード帯域が限られた自宅からリモート再生する場合、元のファイルが利用可能な上り帯域に収まり、クライアントでデコードできるなら、ダイレクト再生が最適です。ソースのビットレートが安定して利用できるアップロード帯域を上回る場合は、ビットレートを下げることで、通常なら不可能なリモートストリーミングを実現できるため、サーバーでのトランスコードが適しています。したがって、まず実測した上り帯域の余裕を基準にし、次にクライアントの互換性とサーバーのトランスコード能力を考慮して選択すべきです。
再生方法を選ぶ前にアップロード上限を測定する
リモートストリームは、クライアントに届く前に自宅のインターネット接続を通過します。サーバーに安定した上り帯域が20 Mbpsあり、元のファイルがその上限を繰り返し超える場合、ダイレクト再生はサーバーの処理能力をほとんど使わなくてもバッファリングする可能性があります。
Plexがサーバー側のアップロード制限とリモートビットレート制限を用意しているのは、送信回線がボトルネックになる可能性があるためです。Jellyfinのハードウェア選定ガイドでも、LAN速度を前提にせず、アップロード帯域をリモートアクセスの要件として扱っています。
代表的なソースファイルが、十分な余裕を持って実測した上り帯域に収まるなら、目標はダイレクト再生にします。収まらない場合、より高速なクライアントを使ってもアップロード帯域は増えません。再生前にメディアのビットレートを下げるか、サーバーでより小さいリモートストリームにトランスコードする必要があります。
元のファイルがWANの帯域予算に収まるならダイレクト再生が有利
ダイレクト再生では、元の映像と音声ストリームをそのまま維持し、再エンコード処理を回避します。そのため、クライアントがコーデックに対応し、自宅の接続が通常のネットワーク変動に備えた十分な余裕を持ってソースのビットレートを送信できる場合に最適です。
サーバーが新たに圧縮した映像を作成しないため、この方法ではソース品質も維持されます。一方で柔軟性に欠けます。4Kリマックスなどの高ビットレートソースは、リモート接続の帯域がはるかに狭くても、高ビットレートのままです。
アップロード容量がファイルの公称平均値ではなく、実際のピーク値を十分に上回っている場合にダイレクト再生を選びます。サーバー負荷ではなく、ネットワークの継続的な飽和がバッファリングの主因になった時点で、選択は逆になります。
実際の制約をビットレート削減で解決できるならトランスコードが有利
サーバーでのトランスコードは、計算能力と引き換えに帯域幅を節約します。サーバーはソースをデコードし、制約のある上り回線でも送信しやすい低ビットレートの出力をエンコードします。これにより、WANのボトルネックを計算処理の負荷へ変換できます。
FFmpegのコーデックおよび出力制御パイプラインは、このトレードオフの仕組みを示しています。元のパケットをそのまま転送するのではなく、新しい出力ストリームを生成するのです。この処理にはCPUまたはハードウェアアクセラレーターの能力が必要ですが、出力特性をサーバー側で制御できます。
元のビットレートが接続に収まらず、サーバーにリアルタイムトランスコードの余力がある場合は、この方法が適しています。元のファイルがすでに収まっている場合は、帯域の問題を解決しないまま追加の処理と画質劣化が発生するため、適切ではありません。
ISPのプラン名ではなく、持続可能なスループットを測定する
公称上り速度は、アプリケーションが継続的に利用できるスループットと同じではありません。混雑、サーバー側のWi-Fi、ルーターの動作、他のアップロード、クラウドバックアップ、家庭内のビデオ通話などにより、リモートメディアセッションに使える余裕は減少します。
ESnetのiperf3ネットワーク測定ツールは、実際に達成可能なネットワーク性能を測定するために設計されています。家庭内メディアの判断では、トランスコーダーの速度やクライアントのデコード能力を問題にする前に、再現性のある上限を確立することが重要です。
低ビットレートのテストストリームでさえ送信回線が不安定なら、メディアサーバーの調整を止めてください。まずネットワーク経路を改善します。反対に、ネットワークが安定しているのにトランスコードセッションがリアルタイム処理を維持できない場合、制約は帯域幅からサーバーの計算能力へ移っています。
クライアントの互換性によって映像トランスコードが不要になる場合がある
アップロード帯域が限られているからといって、すべてのストリームをトランスコードする必要はありません。クライアントが元の映像、音声、コンテナ、字幕に対応しており、ビットレートも収まるなら、ダイレクト再生が最も低コストな方法です。
ZimaSpaceの再生経路のボトルネックとクライアント互換性に関するガイドでは、トランスコード能力を追加購入する前にクライアントの性能を確認すべき理由を説明しています。互換性のあるエンドポイントなら不要な変換を省けますが、元のファイルがWANの帯域予算を超えている問題を解決することはできません。
不要なトランスコードを避けるために互換性を活用し、本当にビットレートが合わない場合にトランスコードを使います。この2つは別々の判断基準として扱い、一方が常に優れていると考えないでください。
事前にエンコードしたリモート用バージョンが両極端より有利な場合もある
比較の主題ではありませんが、3つ目の運用方法として、高品質なローカルマスターを保持しつつ、リモート利用向けに低ビットレート版をあらかじめ生成する方法があります。これにより、計算処理をライブ再生の時間帯から移せます。
HandBrakeの一定品質エンコードのワークフローは、オフライン処理の考え方を示しています。リモート再生を頻繁に行う一方で、サーバーが複数のリアルタイムトランスコードを処理するには力不足な場合に役立ちます。
このハイブリッド方式は、繰り返し発生する制約を簡素化できる場合にのみ使ってください。たまに発生する狭い帯域のリモートセッションのために、ライブラリ全体を重複して作成する必要はありません。基本的な判断は、帯域に収まるならダイレクト再生、収まらず計算能力があるならリアルタイムトランスコードです。
リモート経路で最初に発生するボトルネックを選ぶ
ソースファイルが持続可能なアップロード帯域に収まり、クライアントでデコードできるなら、ダイレクト再生を選びます。ソース品質を維持しながら、サーバーのリソース使用量を抑えられます。
ソースのビットレートが利用可能な上り帯域を超えており、サーバーが必要な低ビットレートストリームをリアルタイムで生成できるなら、サーバーでのトランスコードを選びます。どちらの条件も満たさない場合、どちらを選んでも本当の問題は解決しません。
停止すべき境界は測定できます。リモートテストで安定したアップロード帯域の余裕があり、互換性のあるクライアントを使い、再生経路がリアルタイムに先行し続けているなら、それ以上サーバーをアップグレードしても信頼性は向上しません。実際に最初に枯渇するリソースだけをアップグレードしてください。
おすすめ商品
製品比較
もっと読む
PlexにはDockerと仮想マシンのどちらが適している？導入方法を比較
共有される運用要件に基づく、Docker、仮想マシン、またはVM内のDockerに関するPlex導入方式の条件付き判定。
Plex向け8GB・16GB・32GB RAM比較：あなたのワークロードに合う容量はどれ？
軽量なPlexには8GB、複数ユーザーでアプリを共有する場合は16GB、VMやRAM容量を制限したワークスペースには32GBを選びましょう。ただし、測定結果で必要性が裏付けられる場合に限ります。
専用ハードウェアアクセラレーションはPlexに大きな優位性をもたらすのか？
対応している繰り返しトランスコードではハードウェアアクセラレーションが有利ですが、ダイレクト再生、まれな変換、未対応の処理段階ではCPUのみでも問題ありません。
