※この記事は以下の記事の続きです。良ければ合わせてご覧ください
※記事作成時点ではEarlyAccessです
この記事を読んでいる方はおそらくすでにローカルネットワーク内でのPixelStreamingに成功しているだろう、と思います
そうなれば次は、インターネット上…つまりクラウド上のサーバに配置したくなりますね
ただ、インターネットを通じてPixelStreamingを行う際には、ある問題が発生します
いわゆるNAT越え問題です
ネットワークに関わっている方なら「なるほどね～」と思うことだろうと思います
知らない人は…後で調べてください
検証環境
下記記事と同じ
参考リンク
準備するもの
- AWSアカウント
サーバー構成
今回はPixelStreaming用とSTUN/TURN用の2つのインスタンスを使用しています
※セキュリティグループの簡素化のため、互いのインスタンスと操作用のPCの間のトラフィックはすべてAllowにしました
※ご自身のセキュリティポリシーに従って設定してください
環境構築（PixelStreaming用）
PixelStreaming用サーバの設定は導入編と同様にしてください
ただし、NVIDIAのドライバが入っていないとUE4のアプリが起動しませんので、下記ドキュメントを参考にしてドライバをインストールする必要があります
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/install-nvidia-driver-windows.html
環境構築（STUN/TURN用）
STUN/TURNサーバ用のアプリにはcoTurnを使用します
設定手順については下記記事が参考になるでしょう
STUN/TURNとしての特別な設定は不要です
環境構築（設定ファイル）
SignallingWebServerにSTUN/TURNを使用する旨の設定が必要です
config.jsonを以下のように書き換えてください
{
"UseFrontend": false,
"UseMatchmaker": false,
"UseHTTPS": false,
"UseAuthentication": false,
"LogToFile": true,
"HomepageFile": "player.htm",
"AdditionalRoutes": {},
"peerConnectionOptions": "{\"iceServers\": [{\"urls\": [\"stun:<STUNのPublicIP>:3478\",\"turn:<TURNのPublicIP>:3478\"],\"username\": \"hakobuneworks\",\"credential\": \"********\"}]}"
}
peerConnectionOptionsのValueをエスケープしている理由ですが、
Cirrus.jsのプログラム側に少々不具合があるようで、内部でParseしているためJSON文字列でないと受け付けない状態になっています
普通にJsonで書きたい方はプログラム側を修正することをおすすめします
// 120行目付近
if(typeof config.peerConnectionOptions != 'undefined'){
// clientConfig.peerConnectionOptions = JSON.parse(config.peerConnectionOptions);
clientConfig.peerConnectionOptions = config.peerConnectionOptions;
console.log(`peerConnectionOptions = ${JSON.stringify(clientConfig.peerConnectionOptions)}`);
}
実行
後は導入編と同じ手順で実行してください
coTurnの起動も忘れないように
ただ、WebRTCProxyの起動だけは、同梱されているStart_AWS_WebRTCProxy.batを使用するほうが良いかと思います
明確に比較できてはいませんが、通常のStartではうまくつながらない可能性がありそうです
ネットワーク状況によってレイテンシと画質に問題が出ますが、今回の構成ではTURNサーバがボトルネックになると思われるので、その部分をスケールアップすれば改善すると思います
AWSのGPUインスタンス上でPixelStreamingが動いた！TURNサーバの性能が低いからレイテンシと画質の劣化がヤバいけど、もっと性能のいいサーバを用意できるなら問題なくなるはず #UE4 #UE4Study pic.twitter.com/cANW7FliYo
— 墨崎達哉 (@T_Sumisaki) 2018年11月9日
考察
ここまで実行できている方であれば、SignallingWebServerに同梱されているbatファイルに、AWSの名前がつくバッチファイルがあることに気がついているかと思います
中身を見てみると、その先はPowerShellスクリプトにつながっており、その内部で先程config.jsonに書いたpeerConnectionOptionsを生成して当てはめるような書き方になっています
STUNのアドレスには、自分のPublicIPを指定しています
これはおそらくこのスクリプト作成時には、PixelStreamingサーバとSTUN/TURNサーバは同一のインスタンスに立ててしまう設定になっていたと考えられます
そうすると、今回僕が作成したような構成で問題になったSTUN/TURNサーバによるボトルネックもある程度合理的に解消できるのでは？と思います
このあたり、サーバの構築に詳しい方であれば解決できるかと思います
追記
ちょっと試すだけであれば、STUNとTURNのサーバは
— neguse (@neguse) November 9, 2018
Engine/Source/ThirdParty/WebRTC/rev.23789/programs/Win64/VS2017/
のものを使うとお手軽そうです
自分はWebRTCProxy, SignallingWebServer,STUN,TURN,UE4アプリを全部Windowsサーバに同居させる構成で試して、うまくいってました