RAY 1stワンマンライブ配信を支えた技術と撮影＆スイッチング（配信チーム編）
2020年8月24日 渋谷WWW Xから無観客で配信された、アイドルグループ「RAY」のファーストワンマンライブ「birth」。元々、同じ日に同じWWW Xで予定されていたワンマンライブ「アイドル」がコロナ禍の影響で中止となり、ライブ配信ならではの演出に振り切った「birth」となった経緯があります。
「birth」は4部構成で、RAYのメンバーがそれぞれを担当して演出を考える形で行われました。それぞれのパートは「VJパート」「カメラいろいろパート」「映像エフェクトパート」「照明がすごいパート」と銘打ち、それらを実現するために、huezさんによる映像加工と照明、VJ BoriさんによるVJ、僕ら撮影＆スイッチング＆配信音声＆配信技術チーム、PAの田川さんらが支えました。
このnoteは「配信チーム編」としたように、全編のベースとなるライブ映像の撮影＆スイッチングと、全体的な今回の配信システムのお話をしたいと思います。huezさんの映像加工部分やVJ BoriさんによるVJについては、僕自身が語れるわけではないので、他のパートのお話がされる機会があるかどうかはわかりません。
一部楽曲のみ無料でご視聴いただけるダイジェスト版が公開されましたが、まずはそちらをご覧いただいたうえで、全編フル尺映像もぜひ！ チケットぴあにて、本日2020/8/30(日) 23:59までご購入可能（2,000円）で、明日8/31(月) 23:59まで視聴可です。
以下でご覧になった方の感想ツイートもまとまっていますので、ご覧ください。
https://togetter.com/li/1583029
過去と現在を「同期」させスイッチングした「Fading Lights」
huezさんがゴリゴリに映像加工した「映像エフェクトパート」にしても「VJパート」にしても、基本的にはリアルタイムにその場で撮影された映像をスイッチングしたものをベースとしています（多少時間軸上の巻き戻し、リプレイ的なことは行われていますが）。対して、素直にライブ配信映像を送っているように見えた「カメラいろいろパート」の1曲目「Fading Lights」は実は、完全なリアルタイムではありませんでした（無料のダイジェスト版には含まれていませんので、ぜひとも有料版をご覧いただきたいところです）。
Fading Lightsでは、その場でリアルタイムで撮影している4台のカメラ（ほかにもカメラはあるのですが、この曲では使用していません）の映像に、リハの最後に本番と同じ衣装とメイク、照明で、カメラマンの二宮ユーキさんがステージ上でジンバルを使用して撮影した映像を加えて、ライブでスイッチングしています。そのため、二宮さんが撮影した過去の映像から、二宮さんが撮影する現在の映像へのスイッチングなどという不思議なことも起こりました。
当初、演出側から来たリクエストでは、事前に撮影した映像を手動でオケに合わせて再生して（いちおう、冒頭にカウントはあるのでまったく無理ではない）、スイッチングするというお話だったのですが、もしも再生タイミングがズレると、どう頑張って合わせようとしても、最悪曲が終わるまで合わないために使えない可能性もあるため、なんらかの形でオケとタイミングを合わせる必要がありました。この曲の映像が演出意図どおりに違和感なく見えるかどうかは、タイミングこそがすべてなので、オケと映像が必ず同期するシステムを用意することにしました。
【2022年4月29日追記】当日の「Fading Lights」の配信映像の一部と当時のリハでの撮影風景、スイッチャーのマルチビューなどの映像が、RAYの3周年ワンマン「works」に向けた僕ら配信チームへのインタビューのなかで紹介されていますので、併せてご覧ください。
今回はRAYの運営さんのMac上の「Logic Pro X」でオケ出しするということでしたので、今回採用したアイデアは制御用に「外部MIDIトラック」を追加してもらい、曲の頭に特定の「ノート（MIDI音源などの音を鳴らしたりする情報）」を打ち込み、MIDIインターフェイスを利用して、最終的に配信チームの動画再生環境を叩くというものです。
今回の収録映像の再生環境は配信チームのMac上のAdobe Premiere Proを利用しました。Premiere Proを採用したのは、MIDIコントローラで外部から制御できること、Blackmagic Design Mini MonitorなどでHD-SDIなりHDMIで映像を出力でき、OSの画面などが出力される事故も起こらないこと、また、撮影したデータをシーケンスに配置して、タイミングを合わせるための作業がやりやすいことも採用の大きな理由です。
もちろんオケ出しそのものを映像送出ができるシステムにして、音と映像を同時に再生すれば問題ないのですが、実際のオペレーションを考慮すると現実的ではありません。
また、リアルタイムで撮影しているカメラも基本はすべてワイヤレスシステム（Hollyland MARS 400Sを使用）で転送してスイッチャに入力していることや、カメラ自身が撮影映像を出力するまでのタイムラグもあるため、スイッチャーに入力されている映像は現実よりは0.4秒程度遅れています（カメラやワイヤレスシステム、撮影時のフレームレートでも変わってきます）。したがって、再生する動画もその程度遅らせていないと、他のカメラの映像とズレてしまいます。
そうした調整を運営さん側のMacで行うのは現実的ではありません。またリハ中に合わせておける必要もあるため、事前に撮影されていたゲネの映像を元にリハではタイミングを合わせておくことにしました。当日リハの終わりがけに撮影した映像を、ゲネの映像の音と同じタイミングになるようにPremiere上で差し替えればよいため、当日の限られた時間のなかでのオペレーション上も事故がない方法だと考えました。
実際には、撮影前のリハで1回（ここではゲネの映像とのスイッチングでテスト）、リハ後半で実際に撮影、そしてリハ最後に撮影映像に差し替えて曲の冒頭のみテストしてタイミングに問題がないか確認しました。
専用のUSB MIDIコントローラを開発
原理的には運営さんのMacにMIDIインターフェイス付きのオーディオインターフェイスを接続して、配信チームのMacにも同様にMIDIインターフェイスを接続して、MIDIケーブルで双方を接続すれば実現できるのですが、双方のMacの設置位置が離れていること、現場で何か問題があった場合に、運営さんのLogic Pro Xのデータを修正するのではなく、配信チーム側ですべて吸収できるようにしたいということで、今回は別のアプローチを取りました。
双方のMIDIインターフェイスは汎用のものではなく、「Arduino」というマイコンボードを使い、それをUSB MIDIインターフェイスとして動作するようにして、双方の通信はEthernetシールドによりTCP/IP（UDP）で行う設計としました。
動作は普通にプログラミングできる（というかプログラムしないと動かない）ので、送信側（Logic Pro X側）で受信するノートと、受信側（Premiere Pro側）で送るノートは異なっていても問題なく、設計上の自由度も高い構成となります。これによって、Logic Pro Xで1つのノートオンの信号を送るだけで、Premiere Proには、映像の先頭に再生位置を移動して再生開始をする2つのアクションを送ることを可能にしてます（今回はMACKIEコントロールのプロトコルを使いました）。
また、この構成であれば汎用のLANケーブルで双方が結線できること、通信部分含めて既存のハードウェアを利用できるため、短い開発期間でも信頼性を担保できます。USB MIDIの実装はUSBMidiKliKというオープンソースのファームウェアを利用しました。これによって、Arduinoを簡単にUSB MIDIインターフェイスに仕立てることができます。Macへの接続はUSBケーブルでいけるので、極めてシンプルな構成となります。なお、現在のEthernetシールド2は、AutoMDI/MDI-Xの機能がないため、直接結線するためにはクロスケーブルを利用する必要があります（今回はクロス変換と長い通常のLANケーブルを利用しました）。
最終的な映像と音の同期をどうとったか
現代の多くの映像機器では、映像の処理は一旦1つのコマ（フレーム）の映像をメモリに取り込んで処理したうえで再度送り出したり、スイッチャであれば他のカメラからくる映像のズレを補正するための処理などが発生するため、カメラにせよスイッチャにせよ、コンバータにせよ必ず遅延が発生します。
したがって、PAさんのツーミックスやエアーマイクなどの音声信号とカメラの映像をそのままスイッチャに入れても、その時点ですでにズレが発生しています。通常は、スイッチャに入れる前に音声を遅れせるか（ディレイ）、オーディオディレイの機能のあるスイッチャであれば、スイッチャ内部で同期させることが必要です。
今回のライブ配信は、配信チームがスイッチングした映像を、さらにhuezさんのシステムに入力して、その出力を配信チームの最終段のスイッチャに入れています。また、huezさんパート以外では、配信チームのスイッチング映像をそのまま最終段のスイッチャに入れて、パートごとに切り替える構成となっているのですが、そのままでは、huezさんパートへの切り替えのタイミングで時間軸上のズレが発生してしまいます。
基本的に音は常に同じ時間の流れで進行していますので、それに各映像が同期しているべきという考え方で今回のシステムは設計しました。一番処理に時間がかかるのは、huezさんの映像エフェクトのためのシステムを経由しているルートですので、音声はそれに合わせて遅延をかけ（カメラやワイヤレスシステムと最初のスイッチャなどの遅延を積み重ねるとだいたい0.8秒くらい）、最終段のスイッチャに入れるようにしました。huezさんシステムを経由しない映像も、同程度の遅延をかけて、最終段のスイッチャに入れる必要がありました。
映像に対する遅延がかけられる製品としては、一般的に入手しやすいのは、ローランドさんのVC-1-DL（通称「FS Delay」）です。ただし、最長4.5フレームまでの遅延（今回採用している秒24コマの24Pでは、0.187秒）となり、それでは遅延量が足りない可能性があること、今回チームで用意できたFS Delayは1台だけで、有線でスイッチャに接続するカメラ用に利用することになっていたので、huezさんシステムと遅延を合わせるシステムとして、今回はWirecastを使用したシステムを使うことにしました。
Wirecastは以前のnoteでも書いたように音声周りで事故の発生する不安があるものの、今回は音声は最終段のスイッチャに入れるため映像のみの扱いであることから、最新版のWirecastを利用し、映像の入出力のインターフェイスにはDecklink Duo 2を使いました。Wirecastには入力ごとに音声・映像を独立して遅延させる機能が搭載されています。今回は撮影・スイッチング・送出ともに24Pであるので、Wirecastの内部処理も24Pとするべきでしたが、実験の結果それだと最小でも7フレーム分の遅延となってしまうことがわかりました。
今回、huezさんパートと合わせるためには4〜7フレーム程度の遅延で収まりそうだったため、実験の結果、内部処理を50Pとすれば、ほぼフレーム落ちが目立たないかたちで、最小4フレームの遅延が実現できることが事前の実験で確認できました。4フレーム以下の遅延は実現できませんが、それ以上であればWirecast側で任意の時間遅延させられるため、FS Delayなどでは対応できない長時間の遅延も実現可能です。現実には、これによって一部でフレームが微妙に欠落する（直前と同じ映像のフレームが連続する）事象が発生してしまっていました。
これは24P→50P→24Pと変換するなかで発生するもので、huezさんのシステムも内部が59.94P処理であったために、一部コマ落ちが発生していたようです（視覚的に気になるレベルではありませんが、わかる人にはわかる程度ではあります）。撮影上不利な点もないわけではないのですが、今回のようなシステムでは、全体を59.94P（ないし60P）で構築して、送出する直前で24Pにすることも考えられるなとは思いました。そのほうが各段階での遅延は実時間的には短くなる＝大抵の機材はフレーム単位で遅延していくため、各カメラごとの遅延量のばらつきも目立ちにくくなることが期待できます。
また、huezさんシステム、WirecastともPCやMacをベースとしたシステムで、事故が起こらないとも限らないので、最悪の場合のバイパスとしてメインのスイッチャと最終段のスイッチャを直結して、なにかあった場合でも映像を途切れさせないようなバックアップは用意していました（その場合、音が0.2〜0.3秒ほど遅れてしまうので、状況によっては配信用の音響卓で遅延量を小さくすることも最後の手段としては考えてはいました）。
VJパートの合成は
VJパートの合成は、メインのスイッチャのDSK（ダウンストリームキーヤー）でルマキー（映像の明るさに比例して、明るい部分のみが元の映像に載る）で合成しました。実際のオペレーションでは、Windowsのタスクバーが表示されてしまう問題が本番で発生して、トラブル対処のためにスイッチングと並行して、DSKのオンオフが必要になってしまったのと、そもそも表現的に数フレームのズレは許容できる内容であったため、最終段のスイッチャでの合成とすれば、オペレーションの担当も分けられたため、よかったのではないか、というのが今回の反省でもあります。
技術は必要なものだけど、大事なのは何を見せるか？
延々技術的な話をしてきましたが、本当に重要なのは「何を見せるのか？」「何を表現するのか？」という部分です。技術はそれを支えるためには必要だけれど、それが目的になってしまうと本質を見失ってしまいます。技術的な部分は簡単に真似もできますし、お金を出せばもっといい手段も利用できます。たとえば、Wirecastを利用した遅延部分も、FS Delayを複数台使うとか、数十万円〜数百万円する専用機材を利用して信頼性と品質を担保することもできます（例: Theatrixx Technologies 3G-SDI Line Delay）
今回のライブ配信を観ていただいた方の感想でも、カメラワークやスイッチング、メンバーの月日さんに持っていただいた手持ちカメラの映像のエモさ、フロアにメンバーが降りてくる場面の楽しさ、huezさんパートもVJパートもちゃんと曲の世界を表現していたといった演出面、メンバーのパフォーマンスを評価する声が大きかったのは、ほんとうによかったなと思います。
以前、CROAK Prime Studioさんにて開催された「ライブ配信まるごと大相談会」に登壇して、「無観客アイドルライブ配信の現場から」と題してお話しさせていただいたときにも触れたのですが、アイドルのライブ映像をつくるにあたって、アイドルのステージの表現の大きな要素として「ダンス」の表現をしっかりとみせていくことは重要で、今回もそれを強く意識して映像を制作しています。
RAYもそうですが、多くのアイドルのダンスは「フォーメーションダンス」と呼ばれるスタイルで、メンバー全員の「群」がつくるカタチが表現の重要な要素となっているため、グループ全体の動きがわかる全身を押さえたショットが極めて重要です。ダンスは指先からつま先まで、全身をつかった表現であることも重要なポイントとなります。
楽曲のストーリーをダンスを通して表現しているため、いかに歌唱しているメンバーに寄ったショットを押さえつつも、全体のフォーメーションが伝わる画も入れていくのかに腐心することになります。寄り画より引き画のほうが情報量が多く、引き画によってその場の全体の状況を伝えるという映像制作の基本に立ち返る大切さも強く実感します。
そして、カメラの切り替えのタイミングは音もそうですが、ダンスの動と静、身体を開く動きなのか、そこから閉じていく動きなのか、フォーメーションの広がりなどを意識してカットをつないでいくことで、よりいいものになると考えています。
歌割りを追っていくことも、もちろん大事な要素ですが、歌っていないメンバーの動き、表情もまた重要です。ある意味、ヲタク（ファン）が、実際のライブ会場でステージを観るときに行っている『脳内カメラワーク』を再現する行為なのかもしれません。
最後に今回の制作チームのクレジットを記載して終わりにしたいと思います。撮影・配信チームは、ここ最近やらせていただいている、MIGMA SHELTERさん、NILKLYさんのライブ配信のほか、多くの現場で一緒になることが多いメンバーで（他にも今回参加できなかったメンバーが多数います）、毎回非常によい仕事ができているのではないかと思っています。今回技術サポートで入っていただいた岩沢さん以外は、一緒にやるようになったのは、この3月からですが、非常にいいチームになっていると思います。
《演出》
音響：田川詞也
照明：アナミー(huez)
VJ（「VJパート」M1〜M5）
：VJ Bori
映像エフェクト（「映像エフェクトパート」M10〜M13）
：YAVAO(huez)、羽賀優天(huez)
《撮影・配信》
監督・撮影：二宮ユーキ
撮影 ：水島英樹、川﨑雄太、モリカワタイヘイ
配信音声 ：大畑“gumi”修平
スイッチング・技術：加賀誠人
技術サポート ：岩沢卓
《制作》
田村庄平(Edenhall Inc.)
なお、今回のライブ配信で使われた各カメラの撮影映像＆ワンマングッズが購入できるセットも販売されています。各カメラの映像については、編集してSNSなどへのアップも可能というおもしろい取り組みもされていますので、少々お高いですが、ご興味があれば、ぜひ！
いいなと思ったら応援しよう！
