RTA 1n Kagawa Onlineで実践した配信セットアップ【ミラー向け？】
こんにちは、Cmaです。
今日のお昼くらいに回ってきたこのツイートをみて、「あーオンラインイベントの配信セットアップとか知りたい人いるかなぁ」とか思ったので、この間やったRTA1nKagawa Onlineのセットアップを共有しようと思います。
今回OBSで録画してて気づいたんだけどブラウザソースの「OBSに音声を再ルーティングする」にチェックを入れると音声ミキサーで調整できるようになります。ミュートとかもできるようになるので録画やミラーに有用かと思います。
— mobu (@mobu_ngo) March 15, 2020
既出であればすみません。 pic.twitter.com/zaYZdfHXhN
はじめに
本題に入る前に。今回の配信セットアップについては、配信管理ボランティアとして参加したRTA in Japan 3 Onlineを大いに参考にしています。 RTA 1n Kagawa Onlineのセットアップを紹介しますが、本イベントのセットアップが特段新規性のあるものではないことは予めご了承ください。
RTA 1n Kagawa Online とは
「RTA 1n Kagawa Online」は、2020/03/07と2020/03/08の両日に渡って行われた、RTAのオンラインマラソンイベントです。 運営は私含めて5人、私Cmaは一応主催として色々やってました。技術的なところだと、Miraiさんに多大なるご協力をいただき、自分のやりたいことを実現させてもらっていました。 もちろん私が技術的なところに力を注げたのは他の運営陣のおかげです。本当にありがたかったです。
イベントの特徴としては、
- ゲームをプレイするRTAプレイヤー（以下「走者」）が自宅から配信している映像、音声をミラー配信する
- イベントの制約として同時にプレイする走者は2人までとした
- 走者以外にも解説・ガヤとして話す人（以下「解説」）が任意の人数いる（今回は最大2人でした）
- 表示する画面比は（当初7種類の予定だったが）9種類。画面比の違いと画面数の違いにそれぞれ対応する
- セットアップ時間（RTA間の準備時間）には専用の画面を表示しつつ、BGMを流しておく
技術的にフォーカスされる部分はこの辺りかと思います。
この内容を、RTA 1n Kagawa Onlineでは「配信PCを操作して画面・音声を作る人」と「走者の配信やDiscordを予め見聞きしておいて事前準備をしておく人」の2人で回してました。 セットアップ時間は10分でしたが、イベントとしてはオンスケだったので無理なスケジュールではなかったです。運営陣の皆さん負担かけさせてたらごめんなさい。
こんなイベントで、どんな準備をして、どんなセットアップで進行していたかを書ければいいなと思います。
配信環境について
配信PCは、日頃からゼルダRTA交流会等で積極的にミラー配信を行ってくれているMiraiさんのPCをお借りしました。 お借りするとは言っても物理的に拝借するわけではなく、遠隔操作できる仕組みを利用して、私もMiraiさんのPCを使えるようにしただけです。
遠隔操作については、実現方法として2つ候補がありました。
- Windows標準のリモートデスクトップ機能
- AnyDeskを利用する方法
当初はWindowsのリモートデスクトップを利用する方向で進めていたのですが、Pro Editionでは1ユーザーに1人しか同時にログインできない＝1人が操作している間は他の人は画面すら見れないということで、リモートデスクトップでの実現は難しいね、という結論に至りました。そのため、RTA 1n Kagawa OnlineではAnyDeskを用いた方法で実現しました。AnyDeskの細かい使い方は各自ググっていただければすぐ出てきます。特別な使い方はしていないのでここでは省略します。
配信PCの遠隔操作の際には、新規のWindowsユーザーを準備し、そのユーザーで全ての操作を行いました。
これは、Administrator権限を持たせないことでセキュリティ的なリスク（私がMiraiさんのPCを悪用しようとするリスク）を避けること、イベント後にユーザーを消去することで使い捨てが効くことが大きな理由です。 ボランティア等を募って、より利用者が多くなるような場合は特に注意した方が良い点だと思います。
配信レイアウトについて
配信レイアウトは、おなじみNodeCGで実現しました。NodeCGについて細かいことは省略しますが、Webの仕組みで動的な配信オーバーレイを実装できるフレームワークです。 今回はデザインをkenさんにお願いして、テキストや画面の位置の配置・配色などもろもろを定義していただき、NodeCG上のWebページにCSSで実装しています。 これに関してはまた別に機会に。気になる方はGitHubにソースコードがあるのでご参照ください。
配信PC上では、NodeCGで作られたオーバーレイをOBS内のブラウザで取り込み、画面全体に表示します。 あとはオーバーレイに空いているゲーム画面のエリアに、走者が配信しているゲームの映像を当てはめることで、映像は完成します。
NodeCGのブラウザソースは、以下のような設定で取り込みます。
「カスタムCSS」は、意図しないスタイルが効くのを避けるためにデフォルトのものを消去しておきます。また、表示していない画面のブラウザが動くことで配信PCやOBSに負荷がかかるのを避けるために「表示されていないときにソースをシャットダウン」を有効にします。
逆に「シーンがアクティブになったときにブラウザの表示を更新」はチェックを外しておきます。最初はチェックした状態で進めていたのですが、OBSでトランジションした際に画面の読み込みが走ってしまうので解除しました。これをNodeCGの画面数分用意しますが、今回はOBSの1シーンに全てのNodeCGソースを作成しておきました。
上述した設定を反映したNodeCGソースを、とりあえず1つのシーンに集めておきます。実際にレイアウトを作るシーンは、このソースを「参照」するようにします。 各NodeCG画面ごとにシーンは作成しますが、仮に配信用のシーンを消してしまった場合も、元々のブラウザソースは残っているので、リカバリが容易かつ設定忘れを防ぐことができます。
ゲーム画面（映像）
続いて、走者が配信するゲーム画面の取り込みです。
走者の皆さまには、配信サイト「Mixer」での配信をお願いしました。チャンネルは4つ用意し、スケジュール順に各走者に割り振ります。4チャンネル用意したのは、イベントの同時プレイ数が最大2つであるためレースが連続しても事前に準備ができるようにするためです。同時画面数がより多い場合はチャンネル数を増やすか、スケジュールで前後の画面数を調整する必要があります。
オンラインイベントではよく使われるMixerですが、MixerにはFTL(Faster than Light)という配信プロトコルがあり、これによって1秒未満のラグで配信することができます。詳しくは後述しますが、ラグをできるだけ少ない状態で配信したい場合には、このFTL方式での配信を行うようにしました。
ただしFTL方式は配信側への負荷が大きいので、配信テストを行った上で問題なく配信できるかを確かめておいた方が良いです。
OBSでの取り込みですが、NodeCGソースと同様にOBS内のブラウザを利用します。Mixer取り込み時のブラウザソースの設定は以下の通りです。
今回はカスタムCSSは特に変更していません。代わりに「OBSに音声を再ルーティングする」にチェックを入れています。 これによって、各ブラウザの音声ソースがOBSの音声ミキサーに割り当てられます。各ゲーム画面の音声をOBSで操作するためのものです。詳細は後述します。
このままではブラウザにMixerのチャンネルページが表示されているだけなので、ゲーム画面のみを取り込むようにします。OBSのブラウザを操作するために、ブラウザソース上で右クリックして「対話」ウィンドウを開きます。
このウィンドウで配信を最大化すると、OBSのブラウザでゲーム画面のみを表示することができます。音量もブラウザで変更する必要がないように、最大にしておきます。
ゲーム画面の整形ですが、余分な外枠はOBSの「クロップ/パッド」フィルタで取り除きます。これでまず大本のゲーム画面のクロップを行います。
通常のゲームであればこれをうまいことNodeCGオーバーレイの裏に配置すればOKです。このクロップフィルタは元ソースに残るので、ゲーム切り替えの際にリセットするのをお忘れなく。
DS等の複数画面を表示するゲームでは、同じ画面ソースを複製・それぞれに変換でクロップを行うなどが必要になります。うまいことやってNodeCGの画面エリアにはめ込んで映像の準備は完了です。
音声について
セットアップ中に配信に乗せずにできるだけ準備し、音声が調整された状態でゲーム画面に切り替えられるように、音声については極力OBSから独立させます。
管理したい音声は、 - OBSから出力されるゲーム音 - Discordから出力される通話音 - Spotifyから出力されるBGM
の3つです。
音声の管理には、「Voicemeeter banana」を利用しました。 PC上で動かせる仮想ミキサ―で、PCに入力されている物理デバイスのほか、2つの仮想デバイスを設定することができます。ただし、今回管理したい音声は全てPC内のソフトウェアからの音声だったので、仮想デバイス2つでは足りません。ソフトウェアの音声出力を仮想の物理デバイスに見立てるために、「VB-Cable」を利用します。
今回はメインの出力音声であるOBSからのゲーム音を仮想の物理デバイスとして、Voicemeeter bananaに入力しました。OBSの音声の「モニタリングデバイス」を、VB-Cableで追加した「Cable Input」にします。
Mixerからの出力をOBSからの出力として利用するために、OBSのオーディオ設定を変更します。Mixerソースが配信画面に乗っている状態で、「オーディオの詳細プロパティ」から設定を変更します。
「音声モニタリング」を全て「モニターのみ（出力はミュート）」とします。モニターとして音声が再生されるので、Mixerからの音声はVoicemeeter bananaに入ります。配信への出力はミュートされるので、ブラウザソースから直接OBSを介して配信に乗るようなことはありません。レース時のゲーム音声のミュート／ミュート解除や、ゲーム音声同士のバランス調整はOBSで行いつつ、全体のバランスをVoicemeeter bananaで調整する、といった形です。
あとは、複数人の走者や解説とのDiscord通話の音声を適宜調整します。走者のプレイと音声、また解説にラグが起きないようにMixerのFTL配信を利用して、自然に通話ができ、配信に乗るようにしてあげます。
複数人の声を配信に乗せる場合はDiscordを利用するので、上記のようなセットアップになります。走者の音声のみの場合はもっと単純で、Mixerに走者の音声を乗せてしまいます。Mixer内であらかじめゲーム音とのバランスを調整しておき、Voicemeeter bananaでの調整は行いません。この場合はMixer配信はFTLである必要はありません。RTA 1n Kagawa Onlineでも、走者のみの音声であればFTLを避けるようにしました。
懸念点
今回のセットアップでの懸念点もあります。
OBSからMixerの音声を取ってくるには、配信にMixer画面が乗っている状態でないといけないことです。そのため、ゲーム画面に配信を切り替える前にゲーム音を聞くことができませんでした。
これに気づいたのは実は最初のゲームの直前だったのですが、対応としては、ゲーム画面にトランジションした後、Voicemeeter bananaのゲーム音量を少しずつ上げていくことでうまいところを探すようにしました。Discordを使わない場合は事前にMixer単体で確認できるのでそこまで大きな運用変更ではありませんでしたが、本当なら予めMixerの音声を聞いておきたいところでした。
他には、Discord通話を行う走者の配信では、MixerにDiscord音声を乗せないように対応してもらう必要があったことです。これに関しては私の伝達不足で、ハード的に難しいという方もいらっしゃいました。これは他の運営の方の起点で、Mixer配信にDiscordの音声を集めて予め調整をしっかりしてもらう等で対応してもらいました。配信テストの段階で、この辺りは周知できるとより良いと思います。
終わりに
今のところ思いつくのがこの程度なので、ここまでとしたいと思います。もし気になることがあればコメントなりTwitterでご連絡いただければ適宜追記したいと思います。
元ネタがオンラインイベントなので、今回の話はオンラインイベントが対象でした。オンラインイベントは恐らく皆さんが思っているより手軽なものなので、これを参考に運営してみてはいかがでしょう。
また、今回はオンラインイベントの話でしたが、オフラインイベントの技術的な話が気になる方は、Hoishinさんの「RTA in Japanを支える技術 ～オーディオ編～」が参考になると思います。併せてどうぞ。
以上です。ではまたどこかで。
