Amazon KVS WebRTCを使ってお絵描きアプリを作ってみた

Amazon Kinesis Video Streams WebRTC

Amazon Kinesis Video Streams WebRTC（KVS WebRTC）は、簡単にいうと、カメラやスマホ、ブラウザ間で映像や音声を低遅延でリアルタイムにやりとりする仕組みを、AWSがまるっと用意してくれるサービスです。

WebRTC自体はオンライン会議などに使われるオープンな技術ですが、自前で使うには、相手同士をつなぐためのシグナリングサーバーや、NAT越えのためのSTUN/TURNサーバーを構築・運用する必要があります。

ちょっと難しそう…と思って手を出せずにいたWebRTCですが、KVS WebRTCならそれらをAWSが肩代わりしてくれます。シグナリングチャネルを作ってSDKを組み込むだけで、思っていたより簡単につなぐことができました。

ということで、これを使って何か番組制作で使えそうなものが作れないかな？と考えました。
今回は細かい構築手順ではなく、KVS WebRTCを使ったら、タッチペンのお絵描きアプリが作れたよ！というご紹介です。

お絵描きアプリとは

そもそもお絵描きアプリって何？という方も多いと思うので、そちらの説明から。

例えばゴルフ中継で、注目の選手のスイングを見ながら『トップの位置の左肘の使い方が…』と解説したり、野球のキャンプでバットの軌道を説明したり、バレーボールで『空いているこの箇所を狙って…』とフォーメーションを説明したり。スポーツ中継で、解説者が映像に円や矢印を手書きで書き込んでいるのを見たことがある方もいるかと思います。

MBSではこれを『お絵描きアプリ』などと呼んでいて、スイッチングアウトの映像に、タッチパネルのモニターでお絵描きをしながら制作しています。

その機器からFILL（描いた線の絵柄）とKEY（その線の形を切り抜くための信号）の2種類を出力して重畳させることで、解説者の手書きのポイントを視聴者のみなさんのもとに届けています。

このお絵描きアプリの機器は、放送機器なので安定性に優れていて、重宝しています。ただ、お絵描きは急にオーダーが入ることも少なくありません。中継が長くなって、じっくりした解説が欲しくなったときや、解説者と制作チームの打ち合わせの中で『こういうところを説明したい！』となったり。

いざ使おうとすると、タッチペン用モニター、描画ソフト、そこから出るFILLとKEY、解説者に返す映像と、機材もケーブルも増えていきます。放送機器だと事前の準備が必要なことも多く、急なオーダーに対しては機材の量が重く感じることがあります。

これをAWSのマネージドサービスなども組み合わせながら、最小限のガジェットで構築できないか？と考えていたときに、KVS WebRTCを使ってみよう！となりました。

今回意識したこと

今回は、お絵描きをするタブレットと、お絵描きを受け取るパソコンを、ケーブルで繋がないことを前提に考えました。
つまり、送り返しの映像とお絵描きのデータを、それぞれインターネット越しに伝送します。

というのも、お絵描きをする場所と、CGを重畳する場所は、必ずしも近くにあるとは限りません。

例えば、CGを重畳するのは中継車、お絵描きをする解説者は現場の放送席、ということもあります。
会場のパッチ盤には限りがあるので、FILLとKEYと送り返しを毎回そこまで伸ばすのは難しい、という想定です。

アーキテクチャ

今回は、ページをAmplifyで公開し、放送席のiPadと中継車のパソコンをKVS WebRTCでつなぎました。届いた座標は、同じパソコンのTouchDesignerでαチャンネルとして出しています。

実際の画面

実際に作ったのはこのような感じです。

まずは中継車側のパソコンで、キャプチャーデバイスなどを使って、外部からの映像をカメラとして認識させます。
次に、ZoomやGoogle Meetのようにそのカメラを選択して、送り返しの映像を作ります。
あとは接続ボタンを押して待機します。

タブレット側でも接続ボタンを押すと、タブレットの画面に送り返しの映像が表示されるので、その上にお絵描きができます。

すると、ほぼ遅延なく、パソコン側の画面にもそのお絵描きが表示されました。

ここでのポイントは、送り返しはもちろん映像として伝送していますが、お絵描きは映像（画像）ではなく、JSON形式のデータで送っているということです。

WebRTCには大きく2種類の伝送ルートがあります。ひとつ目は、映像・音声を送るMediaStreamです。
もうひとつはDataChannelといい、こちらは映像・音声以外の任意のデータを送るためのルートです。

お絵描きはこのDataChannelで、こんなJSONデータを送っています。

{"type":"begin","strokeId":"……","x":640,"y":360,"t":12840,"color":"#e53935","width":18}
{"type":"move","strokeId":"……","x":710,"y":420,"t":12856}
{"type":"end","strokeId":"……","x":760,"y":450,"t":13102}
{"type":"clear","t":15220}

ペンを置いたらbegin、動かしている間はmove、離したらend、全消去はclearです。送っているのは座標と色・太さくらいなので、軽く、速く届けることができます。

次に、パソコンに届いたJSONデータを、WebSocketでTouchDesignerに送ります。

パソコン側の画面にある「TD 接続」を押すと、ws://127.0.0.1:9980へ、さっきのJSONデータをそのまま送るようにしました。
ちなみに、ここからはもうインターネットは使いません。パソコンの中だけの世界です。

TouchDesigner側の流れは、こうなっています。

ブラウザ →（WebSocket）→ Web Server DAT → Web Render TOP内のページ → Canvasに描画

TouchDesignerの中では、Web Server DATがそのポートで待ち受けています。Web Server DATは、Web Render TOPにお絵描き用のページ（html）を渡すと同時に、ブラウザから届いたJSONデータもそのページへ転送します。
Web Render TOPの背景は透明にしてあるので、中のCanvasがタブレットで描いたのと同じ線を描くと、線だけがαチャンネル付きの映像として出てきます。

今回のデモではSDIは出さず、TouchDesigner上でお絵描きの線をカメラ映像と重畳しました。実際の運用では、ここからFILLとKEYをSDIで出力することになります。

最後に

今回は、コードやコンソール画面を載せるような技術寄りの記事ではありませんでした。

ただ、AWSのサービスをいろいろ調べて、やってみよう！となったときに、何が役に立つか、どうしたら番組作りが楽になったり、かゆいところに手が届いたりするか、と考えながら作るのはとても楽しかったです。

今回やってみてポイントだと感じているのは、先ほども書きましたが、お絵描きを映像のまま返さなかったことです。

放送席へOAを送り返すときは、画質より低遅延が欲しいことが多いです。一方で、放送席で描いたものを映像のまま中継車へ返そうとすると、線が読めるだけの画質が必要になります。
そこを座標のJSONデータにしたことで、回線がそれほど太くない場所でも届けやすい形になったかなと思います。

オンプレの安定した機器を使うのももちろん大事です。
（正直、私はそういうのが好きでもあります）
そのうえで、オンプレでは届きにくいところをAWSで補っていけると、運用やコストも含めて、制作の現場はもう少し楽になるのではないかと思いました。

またいろいろ作ってみようと思います！