AWS Elemental MediaLiveのスタンダードパイプラインチャンネルを検証してみた
そもそも AWS Elemental MediaLiveとは
AWS Elemental MediaLive (AWS エレメンタル メディアライブ)は、リアルタイムの動画サービスでブロードキャストおよびストリーミング配信用のライブ動画を簡単に作成できるサービスです。また、AWS Elemental MediaLiveを使うことで、長時間のライブイベントも簡単に作成可能で、作成の際にはリアルタイムで取得したサイズの大きいライブ動画をインターネットテレビやスマートフォン、PCなどで視聴できる小さいサイズに高品質に変換します。
AWS Elemental MediaLiveは、現在使用されている多くの業界標準規格がサポートされているため、ユーザーが視聴する各種ツールに対応します。
- 動画圧縮規格 H.264/AVC 、H.265/HEVCなど
- 通信プロトコル RTP、HLS、RTMPなど
ちなみに、少し宣伝とはなってしまいますが・・・
弊社では、AWS Elemental MediaLiveの他にもElemental MediaLiveと同様に、高品質な映像のリアルタイムエンコードが可能なオンプレミスのエンコーダ「AWS Elemental Live」もご紹介可能ですので、クラウドではなくオンプレでないと要件的に厳しい方でも、まずは、お気軽にご相談いただけばと思います。
AWS Elemental MediaLiveのチャンネルタイプとは
AWS Elemental MediaLiveのチャンネルには下記の2種類あります。
- Standard Channel（標準チャンネル）
2つのパイプラインを使用した冗長構成でリソースが作成される（デフォルト）。
- Single Pipeline Channel
冗長構成ではなく、単一のパイプラインのみで構成されるリソースが作成される。冗長構成ではない分、Standard Channelよりも安価に利用できる。
Standard Channelの構成例
Single Pipeline Channelの構成図
今回は、下記の要領で、AWS Elemental MediaLiveのStandard Pipeline Channel で MediaLive を使用する動きを検証していきます。
INDEX
- 構成はプライマリ、バックアップと2本の入力ソースを用意し、Pipeline0、1とそれぞれに入力してHLSを1系統出力する
- Redundant HLS Outputs in Top-Level Manifest機能を使ってみる
- input switch機能（フタかぶせ）を使ってみる
- input failover機能を使ってみる
※02以降は、01の構成を変更せずに行った。
構成はプライマリ、バックアップと2本の入力ソースを用意し、Pipeline0、1とそれぞれに入力してHLSを1系統出力する
-
※今回は同一筐体のKiloviewを使ってテストを行う。
※main、backupでKiloviewの筐体が別の場合は、時刻情報は数秒ズレることが予想される。- main、backupと2種類のm3u8が生成されている状態（図1）
- main.m3u8を画面上は再生している
- backup.m3u8を画面下は再生している
- Pipeline0、1とそれぞれ別の入力ソースを認識しているかを確認したのが、図1。
backup側はあえて時刻表示を外して出力している。
正しく認識・再生されている事が確認できた。
- main、backupと2種類のm3u8が生成されている状態（図1）
- （図1）
※今回は同一筐体のKiloviewを使ってテストを行う。
※main、backupでKiloviewの筐体が別の場合は、時刻情報は数秒ズレることが予想される。
- main、backupと2種類のm3u8が生成されている状態（図1）
- main.m3u8を画面上は再生している
- backup.m3u8を画面下は再生している
- Pipeline0、1とそれぞれ別の入力ソースを認識しているかを確認したのが、図1。
backup側はあえて時刻表示を外して出力している。
Redundant HLS Outputs in Top-Level Manifest機能を使ってみる
Redundant HLS Outputs in Top-Level Manifest機能を有効化した状態で、プライマリ側のKiloviewのRTMP出力を意図的に停止させ、この時Player側の挙動がどうなるのかを確認する。
結 果
一度だけ”main_1280x720_5000k.m3u8”の取得に失敗したものの、直ぐに“backup_1280x720_5000k.m3u8”を再取得して再生を続けている。
Player側で再生を見ている分には、かなりシームレスに切替わっている※1。
MediaLive側ではきちんとinputエラーを検知できている。
※1）main、backupを出力するKiloviewの筐体を別で用意した場合も挙動に変化無いかどうかは確認する必要がある。
backupのplaylistだけを参照するように自動的に切り替わっている
Kiloviewを再度出力開始した後に、main.m3u8を再生していたplayerを再読み込みしたところ、再生する映像もmain.m3u8に戻り、master.m3u8の中身も、main、backup両方が記載されている内容に戻った。
input switch機能（フタかぶせ）を使ってみる
-
- main、backupと2種類のm3u8が生成されている状態（図1）
- main.m3u8を画面上は再生している
- backup.m3u8を画面下は再生している
- main、backupと2種類のm3u8が生成されている状態（図1）
-
- MP4のFileInputを新たに追加した状態で、Input Switch（フタかぶせ）を実行してみる
- main.m3u8を画面上は再生している
- backup.m3u8を画面下は再生している
- 同じタイミングでどちらもフタかぶせが実行された
- MP4のFileInputを新たに追加した状態で、Input Switch（フタかぶせ）を実行してみる
-
- 片系を停止させた状態でフタかぶせを実行した場合も問題なく動作した
補足：input Switch使用時の切り替わり速度について同期の正確さは、±0.272秒だった
input failover機能を使ってみる
- MediaLive側の設定状況としてはこうなる
- ykoba-test01 = Standard input: A
- ykoba-test02 = Standard input: B
結 果
※FailOver前後でm3u8の記述に差異は無し
master.m3u8、main_1280x720_5000k.m3u8(未掲載) のどちらを確認しても、m3u8の中身からfailoverされたことを確認することはできなかった。またfailoverする際に、数フレですが黒味が入った。
入力ソースにタイムコードがembedされていれば、黒味を入れずに切り替えることも可能。
MediaLiveのログ上は、failoverが発生したことは検知できた。
参考：MediaLiveをStandard、Singleのどちらのチャンネルタイプで使用するべきか…
検討する上での前提条件
- Kiloviewはmain、backupで筐体が異なるためストリーム同期はできないものとする
- KiloviewへのSDI入力素材にタイムコードはembedされていない
- failOverする際に黒味が映像にのることは原則NGとする
検証結果から
- 下記の構成でMediaLiveのStandard Pipeline Channelを使用することを推奨する
毎日チャレンジャー業務系のシステム開発やWEBサービスの企画・開発、SaaSサービスの営業等を長きにわたり経験したのちイノコスへ。放送や映像業界には全くの素人ながら業界に飛び込み、全力で勉強中。趣味はジム・ヨガ・旅行・グルメ・ウォーキング・Netflixと多彩。