Epicでは、GoogleがWebRTCのバージョンにおける脆弱性を公開 (詳細はこちら)したことを認識しており、EOS SDKに対する影響および次のステップを調査しています。
デフォルトの Pixel Streaming は、インターネット上でデプロイされ、さまざまなネットワーク条件でユーザーによって利用されることを想定し、ストリームのイメージ品質、レイテンシー、およびレジリエンシーのバランスを取るようにコンフィギュレーションが行われています。この想定がユース ケースに合う場合は、Pixel Streaming のコンフィギュレーションを変更しないでください。ただし、Pixel Streaming は柔軟なテクノロジーであり、その他の多数のユース ケースに利用できます。このガイドは、Pixel Streaming で品質、レイテンシー、およびレジリエンシーを実現する方法に加え、バランスが取れたストリーミングよりもイメージの品質、レイテンシー、およびレジリエンシーのいずれかが重要な場合に最適化するケースについて読者に情報を提供することを目的としています。
WebRTC
Pixel Streaming のイメージ品質、レイテンシー、およびレジリエンシーのバランスの大部分は、WebRTC というテクノロジーによって処理されます。WebRTC はビデオ会議やリアルタイムのストリーミングで広く利用されています。その例として、Facebook Messenger、Discord、Amazon Chime、Google Stadia があります。WebRTC は、低レイテンシー、耐障害性、および複数の参加者間でのマルチメディアおよびデータの送信を向上させるために開発されています。
Pixel Streaming の場合、WebRTC の参加者は、Pixel Streaming プラグインを使用する Unreal Engine アプリケーションであり、WebRTC 機能を持ついくつかのクライアントですが、これは通常はウェブ ブラウザです。WebRTC のユース ケースは幅広いため、特定のユース ケース向けのモードやあらかじめ定義されたコンフィギュレーションはありません。その代わりに、WebRTC は、ネットワーク条件やリソースの制限において品質、レイテンシー、およびレジリエンシーのバランスを取ろうとします。
ただし、Pixel Streaming には、イメージ品質、レイテンシー、およびレジリエンシーについての具体的な要件のいずれかをユーザーが好む場合に選択を許可する複数のパラメータが公開されています。
これらのうちのいずれかを優先すると、その他の 2 つに影響が及びます。こうしたトレードオフが、ユースケースにおいて許容可能かどうかを決めるのはご自身の責任です。以降のセクションでは、以下に関する方法のガイダンスを説明します。
イメージ品質
映像のストリーミングのイメージ品質は、WebRTC によって送信される前に、Unreal Engine のイメージのエンコード時に使用される圧縮の度合いによって最終的に決定されます。この圧縮は、Pixel Streaming アプリケーションの内部で行われ、デフォルトでは完全に WebRTC によって制御されます。
WebRTC エンコーダのビットレートの適合
WebRTC は、Pixel Streaming アプリケーションと WebRTC クライアントの間の利用可能なネットワーク回線容量を繰り返し判定し、適切なビットレート値を計算して、その最新のビットレート推定値で映像のストリーミングを更新します。続いて、映像ストリーミング エンコーダはそのビットレートを上限として使用し、そのビットレートを超えるエンコード済みイメージを生成しないようにします。
このシステムでは、低品質のネットワーク条件では非常に圧縮されたイメージ (角ばったりピクセル化したりしたもの) が生成され、高品質の映像ストリーミングの再生に対応したネットワーク条件では圧縮が少なくなります。言い換えれば、このシステムはネットワーク条件に基づいて映像ストリーミングの圧縮を適合させます。
ネットワーク条件にかかわらずイメージ品質を維持する
回答：-PixelStreamingEncoderMaxQP=N を使用 (ここで N は、1 以上 51 以下の整数です)。
QP の意味と、このパラメータの利用によって生じるトレードオフについて、詳細を以下に説明します。
映像のストリーミングのイメージ品質を最終的に決定する唯一の要素は、映像ストリーミング エンコーダによって行われる圧縮です。任意のフレームの圧縮は、「量子化パラメータ」 (QP) と呼ばれるメトリックによって測定されます。 Pixel Streaming のエンコーダで使用される QP の範囲は 1 ～ 51 (両端を含む) であり、以下のようになっています。
- 1 は最高品質/最も圧縮されていないエンコーディング
- 51 は最低品質/最も圧縮されたエンコーディング
デフォルトでは、この QP 範囲は制限されません。つまり、映像ストリーミング エンコーダは WebRTC によって渡された目的のビットレートに基づいて適切な QP を選択できます。ただし、低品質なイメージを生成してはならないアプリケーションなどでは (高品位な製品コンフィギュレータなど)、エンコーダで使用できる QP 範囲を制限する可能性があります。
生成されるビットレートがネットワーク条件または -PixelStreamingWebRTCMaxBitrate を超えるように MaxQP が制限されている場合、フレームの破棄に伴ってストリーミングされるフレームレートは低下します。
Pixel Streaming の映像エンコーダの QP は、以下を使用して起動引数として制御できます。
-PixelStreamingEncoderMinQP=-PixelStreamingEncoderMaxQP=
通常、イメージ品質の範囲の変更に必要な唯一のパラメータは、MaxQP です。アプリケーションにとって適切な MaxQP は、そのアプリケーションのビジュアルの互換性によるため (特に、動きが存在する場合)、ある程度実験を行って確認する必要があります。ただし、弊社の経験から、ほとんどのユーザーにとって受け入れられるのは MaxQP 20 であり、これは圧縮の度合いに上限を設定することを求める場合に妥当なものです。
送信されるビットレートおよび QP は、Pixel Streaming のシッピングに付属するページ内の settings"/"stats panel または Chromium ベースのブラウザで chrome://webrtc-internals を使用するか、Firefox で about:webrtc を使用することでトラックできます。
次の画像は、イメージ品質やビットレートに QP がどのような影響を与えるかを示しています。
イメージ品質とビットレートに QP が与える影響
強調すべき点として、QP とビットレートの関係は対数的です。つまり、QP の変化は、たとえば 4 と 5 の間の方が 20 と 21 の間よりもビットレートの変化がはるかに大きいということです。
レイテンシー
Pixel Streaming のレイテンシーは、要素の組み合わせによって制御され、制御できるものもあればできないものもあります。エンド ユーザーのデバイス ハードウェア、パブリック インターネット、光の速さなどは制御できません。しかし、Pixel Streaming のレイテンシーに影響するその他いくつかの制御可能な要素もあります。これらの要素については、次のセクションで取り上げます。
レイテンシーを最小限に抑える
レイテンシーを最小化するため、以下の要素を調整することができます。ただし、これらの調整の一部はストリーミング品質とレジリエンシーに影響する可能性があるため、注意してください。
| レイテンシーの要素 | ガイダンス |
|---|---|
| 選択済みの映像エンコーダ。 | 実験的機能である VP8/VP9 ソフトウェア エンコーダは、ハードウェア アクセラレーションを適用した H.264 エンコーダよりもレイテンシーが発生するため使用しないでください。 |
| アプリケーションの地理的位置。 | Pixel Streaming アプリケーションを、地理的に可能な限りターゲット ユーザーの近くにホストします。これには、複数の地域でのホスティングが必要になる場合があります。 |
| アプリケーションをホストするのに使用するハードウェア。 | ハードウェア アクセラレーションを適用した H.264 エンコーディングが GPU でサポートされるハードウェアをお勧めします。さらに、ターゲット CPU でアプリケーションをプロファイリングし、利用率が 100% でないことを確認するようお勧めします。WebRTC トランスミッション スレッドでストールが発生するためです。 |
| 最大ビットレートおよび解像度 | 解像度と最大ビットレートを低くすると、データ送信およびエンコーディングの複雑さが低減する場合があり、これによってエンコーディング、パケット化、デコーディングがより高速になります。このレイテンシーの低減は、通常、品質のトレードオフに見合うものではありません。 |
| オーディオと映像の同期。 | オーディオ/ビジュアルの非同期を希望する場合、-PixelStreamingWebRTCDisableAudioSync によってレイテンシーを改善し、別々のストリーミングでオーディオおよび映像を送信できます。 |
| オーディオの無効化。 | オーディオが必要ない場合は、-PixelStreamingWebRTCDisableReceiveAudio および -PixelStreamingWebRTCDisableTransmitAudio を使用してその送信を無効にすることで、帯域幅を節約します。 |
| モーション ブラーまたはシーンの複雑さの無効化。 | モーション ブラーや視覚的な複雑さを増大させるエフェクトを無効化すると、エンコーディングの複雑さを大幅に減少させることがあり、これによってビットレートの低下につながります。 |
一般に、最大のレイテンシー低減を実現する要素は、Pixel Streaming アプリケーションとユーザーの間の地理的な近接性とネットワーク品質です。
レジリエンシー
このコンテキストで、レジリエンシーとは、パケット損失、ネットワーク ジッター、およびデータ破棄が存在する場合にストリーミングがどれほど安定しているかを指します。WebRTC は、内部の動的に調整されたメカニズムをすでに多数備えており、ストリーミングのレジリエンシーを管理するためにそれらを使用します。たとえば、WebRTC は、受信したパケットを格納するために使用する「ジッター バッファ」のサイズを大きくし、レイテンシーの増大と引き換えにネットワークの遅延や再送信を補正しています。ジッター バッファは直接制御可能ではないものの、データ冗長性によってストリーミングのレジリエンシーを向上するため、映像ストリーミングのエンコーディング中に制御可能な他の要素があります。
低品質のネットワーク条件に対してレジリエントなストリーミングにする
Pixel Streaming の映像ストリーミングのレジリエンシーは、次のものを調整することで向上させることができます。
| レジリエンシーの要素 | ガイダンス |
|---|---|
| エンコーダのキーフレーム インターバル | キーフレームを送信すると、ストリーミングやデコーダで大きなデータ損失の発生後の回復が可能になります。キーフレームを送信するインターバルは、-PixelStreaming.Encoder.KeyframeInterval を使用して制御できます。キーフレームは、通常のフレームよりも大きな帯域幅を使用するため、ネットワークの飽和によってパケット損失が発生した場合にキーフレームをさらに送信しても効果はありません。 |
| エンコーダのイントラフレームのリフレッシュ | 映像ストリーミングの回復情報は、複数のフレーム スライスにまたがってエンコードされる場合があります。この情報によって、データ損失がある場合にストリーミングはよりレジリエントになりますが、ストリーミング全体でより大きな帯域幅が必要になり、ストリーミングの回復が発生した場合にはスキャンライン タイプのアーティファクトが発生します。このオプションは、現時点で NVIDIA GPU でのみ利用できます。また、Pixel Streaming では -NVENCIntraRefreshPeriodFrames=N と -NVENCIntraRefreshCountFrames=M (ここで N はイントラフレームの再リフレッシュされるまでに送信するフレーム数であり、M はイントラフレーム リフレッシュ データを使用してエンコードするフレームの数) を使用することで Pixel Streaming で有効にできます。 |
一般に、ストリーミングのレジリエンシーはほとんどの場合、ネットワーク品質と送信されるデータ量によって影響を受けます。そのため、Pixel Streaming アプリケーションでレジリエンシーの向上と引き換えに品質の低下を受け入れられるのであれば、QP 範囲に制限を設けないことや、アプリケーションの解像度の低下によって送信データ量を削減することは、実行可能な選択肢となります。
Pixel Streaming に対してアプリケーションを最適化する
Pixel Streaming に対してアプリケーションを最適化するための追加の提案を次に示します。
-
部分ごとに異なる色のアーティファクトが存在する場合は、シーン内にフィルム粒子を生成するポスト プロセスを追加することで大幅に減少させることができますが、帯域幅は増加します。
-
追加のレイテンシーを許容可能であり、Pixel Streaming アプリケーションごとに複数のピアをサポートしない場合は、
-PixelStreamingEncoder=を使用し、実験的機能である VP8/VP9 ソフトウェア エンコーダを試すことができます。これらのエンコーダは、H.264 エンコーダと同じビットレートの場合に、より高い品質のエンコーディングを実現します。 - 単一の GPU で多数の Pixel Streaming アプリケーションを実行する (マルチテナンシー) には、アプリケーションのプロファイリングを向上させるか、フレームレート/解像度の低下を受け入れる必要があります。
- クラウドで大規模にアプリケーションを実行する場合は、Unreal アプリケーションが Linux 向けに構築されていれば、Linux では Kubernetes などのテクノロジーのサポートがより充実しているため、より簡単かつ低価格になります。