AWS Media Servicesを使ってラスベガスから動画配信してみた #reinvent #mediaservices

ラスベガスでAWS Media Servicesを使って弊社主催のカンファレンスイベント「Developers.IO 2018 in ラスベガス」を日本のみなさまに配信した際の構成や注意点、配信の様子、またそこに至るまでの試行錯誤の記録についてまとめてみました。
2018.12.10

はじめに

清水です。盛り上がりましたre:Invent2018、私は人生4回目の海外かつ4回目のre:Inventでした。今回のre:Inventですが私のミッションのひとつとして、ラスベガスで開催する弊社クラスメソッド主催のカンファレンスイベント「Developers.IO 2018 in ラスベガス」をAWS Media Servicesを利用して日本のみなさま配信する、というものがありました。本エントリではラスベガスから動画配信をするときに気をつけたことは何か、日本で勉強会を社内向けに動画配信するときとどのような点が異なったのか、といった点をまとめてみたいと思います。

なお、日本国内で私が社内向けに勉強会を配信している環境は下記のエントリなどにまとめています。あわせて読んでいただくと本エントリがより楽しめるかと思います。

また「Developers.IO 2018 in ラスベガス」のイベント自体は知恵蔵が下記エントリにイベントレポートをまとめています。こちらもお楽しみください!

クラメソ社員が現地から生配信!『Developers.IO 2018 in Las Vagas』イベントレポート #reinvent

全体構成と注意したポイント

まずはAWSインフラ含めた全体構成と注意したポイントについて要点をまとめます。ベースは日本国内で社内向けに勉強会を配信した際と同様の構成です。配信エンコーダ(MacBook Pro上のOBS Studio)からAWS Elemental MediaLiveに映像を送信します。AWS側はAWS Elemental MediaLive、AWS Elemental MediaStore、Amazon CloudFrontを連携させてHLS形式で配信します。視聴用ページはAWS re:Invent 2018 JAPAN PORTAL | クラスメソッドに動画プレイヤーを埋め込む形式でした。そのためポータルサイト管理者の知恵蔵と連携し、こちらの手順をベースにvideoタグやVideo.jsの埋め込み用コードをポータルサイトに追記していただきました。

以下に日本国内で社内向けに勉強会を配信したときとの違い、という観点で注意したポイントをまとめてみます。これらに至った経緯は本エントリ後半の「ラスベガス配信に向けての試行錯誤の記録」の項目に詳細をまとめます。

  • 配信エンコーダ
    • 日本での配信の場合は配信専用のMacBook Pro(配信時は他の作業をしない)を用意する
    • ラスベガスでは作業用PCと兼用のMacBook Proを使用
  • ネットワーク
    • 日本での配信の場合は現場のWi-Fiか、利用可能であれば有線LANを使用
    • ラスベガスの場合はホテルのWi−Fiを利用(上限が2Mbpsとのことだった)
  • 配信解像度やビットレート
    • 日本での配信の場合は配信エンコーダの上限などを踏まえて1280x720、3Mbpsの映像、128kbpsの音声で配信
    • ラスベガスでの場合はネットワーク環境から配信ビットレートを上限1Mbpsと想定。これに合わせて解像度も640x360、コンテンツを考えてフレームレート10FPS。音声は128kbpsとした
  • AWSリージョン
    • 日本での配信の場合は東京リージョン(ap-northest-1)のAWS Elemental MediaLive、MediaStoreを利用
    • ラスベガスからの配信ということでオレゴンリージョン(us-west-2)のAWS Elemental MediaLive、MediaStoreを利用した

実際の配信の様子

続いて配信の様子についてもまとめてみます。会場はF-Secure様のご厚意でお借りしましたVenetianホテルのスイートルームです(ありがとうございます!)。機材は以下のようにセッティングしました。演者さんの様子とともにご覧ください。

Webカメラについてはタブレット用のスタンドを使って机から少し高くなるようセットしています。マイクについて、はじめはWebカメラのマイクを使用することを考えていましたが、ちょうど菊池がJabraのスピーカーマイク(Web会議で使用するものですね)を持っていたのでこちらをお借りしました。右下が配信エンコーダを兼ねるMacBook Proですね。画面は以下のように、左に配信エンコーダのOBS Stuidoを表示、右半分でAWS マネージメントコンソソールを開いていました。

また私の前方(1枚目の写真右側)に進行役のtake3000 、後方にWeb担当の知恵蔵がスタンバイ、きちんとした配信なので、配信自体の他に始まりと終わりについても気をつけました。普段の社内向け配信ではなんとなく始めて、なんとなく終わるという具合です(社内チャットで別途連絡する具合ですね)。が、一般公開となるとそうとは行きません。サイトに動画プレイヤーを埋め込むタイミング、配信時に現場のカメラに切り替えるタイミング、フタ画像に戻すタイミングなど…。一部は事前に計画ができず、行き当たりばったりで進行してしまいtake3000、知恵蔵ご迷惑をおかけしてしまったなぁと思います。

ラスベガス配信に向けての試行錯誤の記録

さて、以上で全体構成と注意したポイント、配信の様子までお伝えしました。しかしここに至るまで、配信エンコーダの選定やネットワーク環境など、いろいろな調査や検討がありました。実際に検討だけで済んだことが多いのですが、以下に書き連ねてみたいと思います。

配信エンコーダについて

まずは配信エンコーダについてです。国内の社内勉強会の配信では配信専用(配信時は他の作業をしない)のMacBook Pro (Retina, 13-inch, Early 2015)を準備しています。しかしラスベガスに作業用のMacBook Pro (13-inch, 2017, Four Thunderbolt 3 Ports)と配信用のMacBook Proの2台を持ち込むのは正直避けたいところでした。(なにせ私の旅の荷物は多いので…) そのため、MacBook Pro + OBS Studio + Webカメラ/マイク、という構成ではなく、iPhoneに配信エンコーダアプリを入れ配信することも検討しました。iPhoneからの配信は後述しますがネットワーク環境が悪かった場合にテザリングを行わずに配信できるというメリットもありました。

iPhoneで動作する配信エンコーダも以前iPadで利用したことのあるRTMP Streamerの他、Zixi ONAIRなども日本国内で検証していたのですが、結果的には作業用のMacBook Pro (13-inch, 2017, Four Thunderbolt 3 Ports)にOBS Studio、Webカメラ、Webマイクという組み合わせで行いました。この理由として、Webカメラを利用することでカメラアングルの自由度が高くなること、配信中の状況確認がiPhoneアプリよりもOBS Studioのほうが(PC画面であるため)行いやすいことなどが挙げられます。作業用のMacBook Proで配信専用(配信時には他の操作をしない)ではないため、OBS Studioで配信しながらAWSマネージメントコンソソールを確認する、という使い方もしましたが、配信解像度/ビットレートを低くしているからかOBS Stuidoの負荷が高くなく、配信に影響を与えることはありませんでした。(それでも、配信中はなるべくMacBook Proを使わずにスマホで情報収集をする、という具合でしたが。)

配信解像度/ビットレートについては、後述します現場ネットワーク環境も踏まえて、上限を1Mbps程度としました。また映像で魅せるコンテツというよりも、演者さんのトークが主体のコンテンツです。映像については思い切ってHD画質以下となりますが解像度640x360、フレームレート秒間10としました。ビットレートもOBS Studioの設定としては572kbpsとなります。対して音声としてはあまり低品質にすることはせず、ビットレート128kbpsです。トータルビットレートは700kbpsとなります。映像として少しカクカクしたり(いわゆるヌルヌル動く映像ではない)、拡大すると絵が潰れたりしますが、音声としてはクリアに聞こえる、という映像を意識しました。

実際には使用しませんでしたが、検証したiPhoneの配信アプリについても記しておきます。以前、RTMP Streamerという配信アプリを使用したことがあり、今回も同アプリの使用をまず検討しました。ただ、設定として画面解像度(1080p, 720p, 480p)の設定しかできず、ビットレートやフレームレートの設定ができませんでした。実際にどのぐらいのビットレートで送信しているかも不明であり、別のアプリを検討することにしました。Larix Broadcasterなども検討したのですが、最終候補として残ったのが、Zixi ONAIRです。映像解像度とビットレートとして360p, 700kbps, フレームレートとして15FPSを選択できたことが大きな理由で、1時間程度ランスルーテストのように配信しっぱなしにしても問題はありませんでした。また、こちらもネットワーク環境という点が大きいですが、万が一MediaLiveへ映像を送る際にRTMPが使えなかった場合に備えて、It's My Lifeというアプリもチェックしていました。RTMPでの映像送信の他、HTTP、つまりHLSで直接の送信も可能なアプリです。Webブラウザやホームネットワーク向けとの記載ですが、MediaLiveのHLS形式のInputが対応するのかな、と考えています。(実際には未検証ですが、追って確認できればと思います。)

現地のネットワークについて

続いて配信現場からのネットワークについてです。今回配信現場はF-Secure様のご厚意でお借りしましたVenetianホテルのスイートルームでした。(ありがとうございます!2回目。)現場のネットワークについてはホテルのWi-Fiを利用することが前提でしたが、配信に使えるかは現場で確認してみないとわかりません。十分な帯域が出てない、RTMPがブロックされる、などの事態が発生することが考えられました。そのため、配信ビットレートはトータルで上限1Mbpsと想定し、RTMPではなくHLSでの配信方法も考慮しておきました。また万が一ホテルのWi-Fiが利用できなかったときのため、予備としてモバイル回線を準備しました。

まずは海外で利用できるモバイルWiFiルータです。海外用モバイルWi-Fiルータのレンタルについてはすでに下記エントリで濱田がまとめていますが、今回は無制限プランが利用できることを条件にしました。

無制限プランがあるWi-Ho(ワイホー)、U.S.データ、JAL エービーシーのうちから、今回はJAL エービーシーを選択しました。選択した理由ですが、コスト面とVerizonの回線であるということが記載されていたことが大きな理由です。

アメリカではVerizon、AT&T、T-Mobile、Sprintの4つの通信キャリアがあります。場所によってどのキャリアが良いかはまちまちなそうで、簡単にですがWebで調べた結果、以下の記事が見つかりVerizonが良さそうでは?と考えたのでした。

Best 4G LTE in Las Vegas? [AT&T vs. T-Mobile vs. Sprint vs. Verizon vs. Project Fi][Wynn Hotel] | HighOnAndroid.com

続いて現地SIMカードです。幸い私の手元には昨年のre:Invent2017渡航に際してSIMロック解除したiPhone 6sと、なぜか発売日に購入し、即刻re:Invent2018渡航のためにSIMロックしたiPhone XS、2台のSIMロック済み端末があります。また場所によってどのキャリアが良いかまちまちということは、実際に比較計測してみると面白いのでは?ということもあり、結局以下3種類のSIMを事前に準備し渡航しました。AT&T、T-Mobile、そしてモバイルWi-Fiルータと同じキャリアですがVerizonですね。

  • MOST SIM - AT&T アメリカ SIMカード、7日間 高速6GB (通話+SMS+インターネット無制限使い放題) 回線は全米で最大の通信網を誇るAT&T USA SIM ハワイ
  • MOST SIM - アメリカ SIMカード インターネット 7日間 高速データ通信無制限使い放題 (通話とSMS、データ通信高速) T-Mobile 回線利用 US USA ハワイ
  • 【国内 開通済み アメリカ用 プリペイドSIMカード(Verizon) アメリカ国内通話・SMSし放題 データ容量22GB

と、ここまで準備したのですが、実際にはVenetianホテルのWi-Fiで安定して配信が行えました。使用上限が2Mbpsとのことだったので、配信ビットレートを上限1Mbpsとなるように抑えたのも良かったのかもしれません。(ホテルの回線全体としては大容量のものを用意しているが、個々の端末で2Mbpsに抑えているのでは?と推測していました。)

せっかく揃えた3つのキャリアの速度比較については、配信現場とは異なりますがTreasure Island Hotelから速度計測をしてみましたので、ご参考にどうぞ。

AWSリージョンの選定について

AWSの全体構成としては日本国内で配信を行う場合と同じではありますが、AWSのリージョンには注意しなければなりません。配信エンコーダから映像を受け付けるAWS Elemental MediaLive、またMediaLiveより映像を受けるAWS Elemental MediaStoreのリージョンについては、可能な限り現地ネットワークから近いところが望まれます。ラスベガスはアメリカ大陸の西側なので、以下2つのリージョンがまず候補に挙がりました。

  • us-west-1 / 米国西部 (北カリフォルニア)
  • us-west-2 / 米国西部 (オレゴン)

地図を見ると、どちらも地理的な距離ならラスベガスと同じぐらいの距離のようです。さらに、AWSリージョンテーブルでMediaLive/MediaStoreが利用可能か確認してみると、us-west-1(北カリフォルニア)リージョンではMediaLive/MediaStoreとも利用できないことが確認できます。対してus-west-2(オレゴン)リージョンではMediaLive/MediaStoreとも利用できるので、us-west-2(オレゴン)リージョンを使用することとしました。

オレゴンリージョンでのMediaLive/MediaStoreの構築ですが、いつも東京リージョン向けにリソース作成で使用しているAWS CLIのスクリプトでリージョンをus-west-2と指定するだけで作成が可能でした。

なお実際の視聴者への配信はAmazon CloudFrontから行われます。オリジンとなるMediaStoreはオレゴンリージョン、日本国内の視聴者からのCloudFrontエッジは日本のものとなりますが、ここについては問題なく配信できるだろうと考えていました。過去の社内勉強会配信の際に東京リージョンのMediaLive/MediaStoreを使用してCloudFront経由で配信していましたが、弊社ベルリンオフィスのメンバーから良好に視聴できている、という情報をもらっていたからです。あくまで配信エンコーダからMediaLiveまでを近くしておくことが重要で、実際の視聴ユーザへの配信はCluodFrontでカバーできるということですね。

まとめ

ラスベガスでAWS Media Servicesを使って弊社クラスメソッド主催のカンファレンスイベント「Developers.IO 2018 in ラスベガス」を日本のみなさまに配信した際の構成や注意点、配信の様子、またそこに至るまでの試行錯誤の記録についてまとめてみました。エントリに記載したとおり、いろいろなことを想定して可能な限り準備はしておきましたが、割と大きな問題なく配信ができたかなと思います。ただ実際に一般公開として時間を決めて配信するとなると、サイト遷移など含めた進行などきちんと決めておかないいけない、といった課題も見えてきました。とはいえ実際には無事に配信が行えて何よりでした!