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 範囲を制限する場合があります。
MaxQP が制限されていて、生成されるビットレートがネットワーク条件や -PixelStreamingWebRTCMaxBitrate を超える場合、フレームがドロップしてストリーミングされるフレームレートが低下します。
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 の映像ストリーミングのレジリエンシーは、次のものを調整することで向上させることができます。
レジリエンシーの要素 | ガイダンス |
---|---|
エンコーダのキーフレーム インターバル | キーフレームを送信すると、ストリーミングやデコーダで大きなデータ損が発生しても回復が可能になります。キーフレームを送信するインターバルは、 キーフレームは、通常のフレームよりも大きな帯域幅を使用するため、ネットワークの飽和によってパケット損失が発生した場合にキーフレームをさらに送信しても効果はありません。 |
エンコーダのイントラフレームのリフレッシュ | 映像ストリーミングの回復情報は、複数のフレーム スライスにまたがってエンコードされる場合があります。この情報によって、データ損失がある場合でもストリーミングはよりレジリエントになりますが、ストリーミング全体でより大きな帯域幅が必要になり、ストリーミングの回復が発生した場合にはスキャンライン タイプのアーティファクトが発生します。 このオプションは、現時点では NVIDIA GPU でのみ利用できます。Pixel Streaming で有効にするには |
通常、ストリーミングのレジリエンシーはネットワーク品質と送信されるデータ量に大きく影響を受けます。そのため、Pixel Streaming アプリケーションでレジリエンシーの向上と引き換えに品質を落としても構わないのであれば、QP 範囲に制限を設けないことや、アプリケーションの解像度を落とすことによって送信データ量を削減することが、選択肢として有効です。
Pixel Streaming に対してアプリケーションを最適化する
Pixel Streaming に対してアプリケーションを最適化するための追加の提案を次に示します。
- 部分ごとに異なる色のアーティファクトが存在する場合は、シーン内にフィルム粒子を生成するポスト プロセスを追加することで大幅に減少させることができますが、帯域幅は増加します。
- 追加のレイテンシーを許容可能であり、Pixel Streaming アプリケーションごとに複数のピアをサポートしない場合は、
-PixelStreamingEncoder=
を使用し、実験的機能である VP8/VP9 ソフトウェア エンコーダを試すことができます。これらのエンコーダは、H.264 エンコーダと同じビットレートの場合に、より高い品質のエンコーディングを実現します。 - 単一の GPU で多数の Pixel Streaming アプリケーションを実行する (マルチテナンシー) には、アプリケーションのプロファイリングを向上させるか、フレームレート/解像度の低下を受け入れる必要があります。
- クラウドで大規模にアプリケーションを実行する場合、Unreal アプリケーションが Linux 向けに構築されていれば、より簡単で低価格になります。Linux では Kubernetes などのテクノロジーのサポートがより充実しているためです。
1 対 1 のストリームで最適なパフォーマンスを実現
1 人のユーザーが 1 つの Pixel Streaming インスタンスに接続する 1 対 1 のユースケースは、Pixel Streaming の最も一般的でシンプルな形です。Pixel Streaming の設定の詳細については、「ホスティングおよびネットワーキングの操作ガイド」を参照してください。
1 対 1 のストリーミングに最適なセットアップの説明に入る前に、Pixel Streaming の使用感を最適なものにする上で考慮に入れる指標を決める必要があります。特に次の点を考慮します。
- レイテンシー (ユーザー操作とストリームの時間差)
- 映像品質 (ユーザーが受信する品質)
- さまざまなネットワーク条件に対するストリームのロバスト性 (パケット ロスの処理と回復を迅速に行えるかどうか)
レイテンシー
レイテンシーを最適化するには、ダイレクト ピアツーピア アーキテクチャ (SFU やメディア サーバーがない) を使用し、Pixel Streaming インスタンスとユーザーを地理的にできるだけ近づける必要があります。

上図は低レイテンシーを実現する最適な Pixel Streaming 構成を表しています。エンド ユーザーが UDP を通じて Pixel Streaming インスタンスと直接接続されています。
考慮事項
- パブリック インターネットを介して UDP で UE インスタンスと交信する必要があります。
- 不明 IP アドレスを使って UDP で通信できるネットワーク構成をエンド ユーザーが用意する必要があります。WebRTC に関して言えば、2 つのマシンの間に STUN サーバーを置き、NAT を処理してパブリック IP 交換を可能にする必要があります。
- ユーザー側でこれが難しい場合は TURN (リレー) サーバーを使用できますが、レイテンシーは P2P ユーザーよりは劣る でしょう。
- 複数の WebRTC ピアが異なる品質で同じストリーミングを閲覧するケースでは、この構成は うまくいきません (詳細については SFU 構成 についてのドキュメントを参照してください)。
映像品質
Pixel Streaming などの WebRTC を映像最優先にする場合、エクスペリエンスに最も影響するチューニング パラメータは映像品質です。モザイク状のブロックノイズは誰もが避けたいものですが、一方でさまざまなネットワーク条件の幅広いユーザーに常に安定したエクスペリエンスを提供する必要もあります。これを実現するため、次の点を考慮する必要があります。
- 受容できる最低限の解像度
- その解像度で受容できる最低限のビットレート
- 映像品質、ロバスト性、レイテンシーのどれが重要か
映像品質を上げると必要なビットレートが増大し、ロバスト性が低下してフリーズ発生時にパケットロスが生じます。また、少量でも重要な再送信パケットを処理するためにジッター バッファが拡大し、レイテンシーが増加します。
そのため、快適なエクスペリエンスを確保できる最低限の映像品質を慎重に検討する必要があります。またこの最低限の品質を決めたら、ユーザーとのフィールド テストを慎重に行った後で、上限を超えないようストリーミング品質を制限することが重要です。
ユーザーとの実験を通じてパケット ロス、ジッター バッファによる遅延、ビットレートなどの主要指標を測定し、データに基づいて決めることが大切です。
ただし、データが何もない場合は以下から初めてみましょう。
- 1080p 映像ストリーム (-ResX=1920、-ResY=1080、-ForceRes、-Windowed)
- 最大エンコード品質 10 メガビット/秒 (-PixelStreamingWebRTCMaxBitrate=10000000)
- 必要なときだけ送信されるキーフレーム (PixelStreamingEncoderKeyframeInterval=0)
ロバスト性
映像ストリームのロバスト性は次の方法で向上できます。
- 最大ビットレートを低く設定する
- エンコード時に冗長情報を追加する (
-PixelStreamingEncoderIntraRefreshPeriodFrames=300 -PixelStreamingEncoderIntraRefreshCountFrames=5
) - ネゴシエーション オファー/アンサーに Flex-FEC を含める (Chrome や Firefox など)
ロバスト性が使用上どの程度重要かに関するこれらの指標を調整することで、ユーザーがフリーズに遭遇したりジッターバッファを拡大したりする頻度を変えることができます。
一般的な推奨速度
推奨速度はエクスペリエンスの調整の仕方によって変わりますが、1080p ストリームの H.264 圧縮ビデオの場合の一般的なガイドラインは次のとおりです。
ユーザーのネットワーク接続
- 10 ~ 20 メガビット/秒: 高品質の映像
- 1.5 ~ 10 メガビット/秒: 下限側ではネットワークが不安定になるため、映像品質に目に見える変化が現れる場合があります (動きのある映像で、静止画では出ないブロックノイズが出るなど)。
- 0.5 ~ 1.5 メガビット/秒: ブロックノイズが出ます。
- 0 ~ 0.5 メガビット/秒: 多くの場合使用に適しません。
これらは目標とする映像品質、レイテンシー、ロバスト性によって変わります。
ストリームの品質低下につながる要素
ストリームの品質低下につながる要素はいくつかあります。そのうち最も一般的なものを次に挙げます。
- ユーザー側で達成できる最大ネットワーク速度が、目標とする映像品質に対して低すぎる場合。
- ネットワーク環境が悪いと、断続的/集中的にパケットロスが発生します。
- ストリーミング インスタンスと地理的に近接しているかどうか (レイテンシーが大きいとパケットロスが起こりやすくなります。すると WebRTC がビットレートを落としてストリーミング エクスペリエンスを安定させようとするため、ストリームの品質低下につながります)。
- ユーザーのネットワーク接続に対してエクスペリエンスのデフォルト映像品質が高すぎるとパケット ロスが起こるため、ジッター バッファが拡大されます。するとストリーム適応の最初の方でビットレートが低下します。
- TURN/リレー サーバーがレイテンシーを招き、パケット ロス (UDP) やパケット再送信 (TCP) につながる場合。
- メディア サーバー/SFU がレイテンシーを招き、パケット ロスにつながる場合。
- メディア サーバー/SFU の設定を誤ると、ビットレートや制御メッセージの抽象化を招き、メッセージが Pixel Streaming インスタンスに返されなくなります。すると、エクスペリエンスを接続ピアに適した状態に調節するためのフィードバックを通じたストリーミング ソース更新ができなくなります。
WebRTC 最適化トライアングル

ストリーミング シナリオによっては、望ましい結果を実現するためストリーム設定を最適化する必要があります。
ニーズに即したストリームに調節するため、ストリーム提供者が最適化する上で特に検討するパラメータが、レイテンシー、映像品質、ストリーム ロバスト性の 3 つです。ネットワークの制約上、これらは互いに切り離せないため、調節すれば他のパラメータ (1 つの場合もあれば 2 つの場合もあります) を制限することになります。
デフォルトでは、Pixel Streaming は上図のように、ユーザーの接続に合わせて 3 つの設定のベスト バランスを実現しようとします。
品質とロバスト性より低レイテンシーを優先した最適化

ローカル ストリーミング (VCam Pixel Streaming など) では、低レイテンシーを優先してロバスト性と映像品質を犠牲にする方が都合が良い場合があります。これは次のパラメータで実現できます。
-PixelStreamingEncoderTargetBitrate=10000000
-PixelStreamingWebRTCDisableFrameDropper
-PixelStreamingWebRTCVideoPacingFactor=100
この例では、ネットワーク条件にかかわらず目標ビットレートを 10 メガビット/秒に固定し、フレーム ドロップを無効にして、混雑状態でも常にフレームを送信するようにしています。また、大量パケットを受容できるよう映像ペーシングの設定値に余裕を持たせます。こうすることで、どのようなネットワーク条件でも遅延なくパケットを送信し、レイテンシーを最小限に抑えることができます。この設定は、ネットワーク速度の制約が大きいインターネット経由にはおすすめしません。さまざまなネットワーク条件でスムーズな動作を得るには、フレーム ドロップやパケット ペーシングが役立つからです。
レイテンシーとロバスト性より品質を優先した最適化

別のストリーミング シナリオとして、高品位な製品コンフィギュレータ用など、どのような場合でも一定の映像品質を確保したい場合があります。その場合は映像品質を優先してレイテンシーとロバスト性を犠牲にしてもよいでしょう。これは次の設定で実現できます。
-PixelStreaming.Encoder.MaxQP=20
この設定では、エンコーダが実行する最大圧縮率を制限 (値が小さいほど映像圧縮率が小さい) するため、最低限保証される映像品質に直接影響します。ただし、ユーザーのネットワーク接続がこのビットレートを処理できない場合は、フリーズが発生したりレイテンシーが増大したりします。