この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
清水です。AWS re:Invent2018にてセッション CTD317 「Speed and Performance: How to Manage and Originate Live Video at Scale」を聴講してきたのでレポートします。
セッションの概要は下記になります。
Sports fans demand the best when it comes to live-streaming experiences. In this session, CBS Sports Digital shares how it is using AWS Elemental MediaLive and AWS Elemental MediaStore to give viewers high quality, live-streamed sports coverage. Learn how CBS Sports Digital layers MediaLive, MediaStore, and other AWS services to build an architecture that scales for growing audiences, exacting performance requirements, and increasing redundancy.
スピーカーは下記のお三方です。
- Khawaja Shams - VP of Engineering, AWS Elemental
- Jeff Platter - Principal Architect, CBS Interactive
- Stephanie Lone - VP Engineering, CBS Sports Brands
レポート
驚くような視聴者体験の提供
- 現実の課題点
- プレイヤーの帯域の変動する
- パッケージャのインフラストラクチャの中断
- エンコーダのインフラストラクチャの中断
- contribution時のネットワーク接続
- 現場のネットワークやカメラ
- 典型的なワークフロー
- Live Channel Source
- ネットワークの回復性
- 複数ソースの対応
- AWS Elemental MediaLive
- Synchronized Outputs
- AWS Elemental MediaPackage
- 冗長Inputs
- スケール可能なオリジン
- Multiple OTT Devices
- Adaptive Bitrates
- Quality-defined Variable Bitrate Control (QVBR)
CBS SPORTSでのユースケース紹介
大規模イベント配信
- 課題
- 何百万のストリーミングユーザに最適なビデオ体験を提供
- インジェストと配信では冗長性では、100%のアップタイムを維持するのが鍵
- HLSストリームの整列を維持する出力ロック
- AWSのOriginソリューションの選択: AWS Elemental MediaStore V.S. AWS Elemental MediaPackage
- 大規模イベント配信のワークフロー
- さまざまな場所にあるプライマリとバックアップのエンコーダがAWS Direct Connectを通して複数のリージョンにビデオを配信
- 追加の依存関係を排除するため、AWS Elemental MediaLiveではなくエンコーダでAdaptive Bitrateスタックを生成
- 出力ロック 2.0は一貫したシーケンスIDとセグメント番号を保証
- エンコーダへのSDIビデオ入力内に埋め込まれたタイムコードは、PTSアライメントを保証
- 古くなったマニフェストは、404のために削除することができ、プレイヤーはレンディションを切り替えることができる
- CDNレベルのロジックが4xx/5xxエラーを検出し、代替エンコーダに切り替える
- 広告について
- 従来のクライアントとサーバー側の広告挿入をバイパス
- SCTE-104広告メーカをブロードキャスト信号に挿入すると、カスタムWebアプリケーションへのESAM信号コンディショナのコールバックがトリガされる
- SCTEC-35からID3メタデータへのESAM変換
- AWS Elemental Live APIを利用してダウンストリームクライアントのストリームにメタデータを再挿入
- SCTECよりも仕様が断片化されていないため、ID3はより広範にサポートされる。トラッキング目的で広告サーバーへのビーコン配信を処理するために、クライアントでVAST解析を実施
- AWS Elemental LiveとAWS Elemental MediaLive APIは互換性がない
- MediaStoreとMediaPackageの比較
- MediaStoreはピュアなオリジン。セグメントファイル、マニフェストファイルの変更はしない。
- MediaPackageはマニフェストファイルを動的に再生成する。DRMとDVRのサポート。
- ワークフロー構成図
24/7のライブストリーミング
- CBS SPORTS HQ
- 24/7のライブストリーミングプロダクト
- 動的なDVR再生
- ライブクリッピング
- MediaPackageを利用したDVR自動化
- ブロードキャストレベルのイベントをトリガとして、セグメントレベルのDVRを生成するために、「Fusion」バックエンドAPIを呼び出し
- 開始/終了パラメータのエポックタイムはストリームURLに渡され、オンザフライでDVRを生成
- 現在、DVRウィンドウは72時間から14日に延長され、short-livedコンテンツの理想的なVODの代替となった
- DVRはHLSセグメントと同じぐらいの正確さで、コンテンツがきれいに開始することが保証されていない
- AWS Elemental MediaPackageへの入力ロスは有効なマニフェストを生成する問題を引き起こす可能性がある
- ライブクリッピング
- AWS AWS Elemental MediaPackageから任意の長さのDVRセグメント作成するツール
何百という同時イベント
- 毎年3万件以上のライブイベントがCBS Sports Digitalとパートナーを介してストリーミングされている
- コンセプトから納品まで5ヶ月
- 従来の方法と比較して90％のコスト削減と資本コストなし
- インフラストラクチャはオンデマンドに作成される
- 最初の2ヶ月で10倍のイベント処理能力
SPORTSLIVEでのユースケース
- www.collegesportslive.com
- コアなファン向けのイベント配信（サッカー、バレーボール、ホッケー）
- 放送品質の配信
- 複数種類のエンコーダを想定（OBSやWirecastからTeradek、AWS Elementalまで）
- スケール可能なアーキテクチャ（マイクロサービス、クラウドネイティブ）
- スケールするMediaLiveの管理
- MediaLiveで数百のRunnnig状態のChannelを管理する
- イベントごとに個別のChannelを利用。終了後は自動でアーカイブする
- MediaLiveのTPS上限
- アカウントごと5TPSのハードリミット
- MediaLiveでChannelのcreate/startは多くのステップとAPI呼び出しが必要
- Channel作成
- 複数のステップ
- Channel作成が1分以内
- Channelスタートが2分以内
- Channel作成がLambdaのタイムアウトに引っかかってしまうことも
- 何百ものChannelを同時に開始する
- まったく同じ時間に開始する予定の大規模なイベントのために、MediaLiveのChannelをどのように管理すればよいか
- MediaLiveで数百のRunnnig状態のChannelを管理する
- Encoder Managementワークフロー
- 課題
- 入力ストリームについて動的なIPとBasic認証を扱う
- システムはクライアントエンコーダーのエントリーポイントとして1つのドメインをサポートし、各入力の基本認証をサポートする必要がある
- シングルドメインアクセス
- クライアントはエンコーダ側の設定を変えたくない
- 個別のエントリーポイントを動的にチャンネルに割当
- 認証
- AWS Elemental MediaLiveの認証機能はSecurity GroupによるIPアドレスベースのものだけ
- カスタマのIPは不定
- 既存の認証基盤を利用したい
- RTMPでの音声だけのイベント配信
- イベンtのの3割は音声だけの放送
- MediaLiveではRTMPストリームに映像も存在している必要がある
- 入力ストリームについて動的なIPとBasic認証を扱う
- Proxy Streamingワークフロー
- Encoder Management Interface(EMI)
- ライブストリームの状態表示
- スケジュール管理
- プロキシ経由のストリームログ表示
- ストリームのプレビュー表示
- 今後の課題
- マルチビューのモニタリングシステム
- Amaozn Rekognitionを利用した自動Ad挿入
- Amaozn RekognitionやAmazon Transcribeを利用したCMSでのメタデータ付与
感想
MediaLiveやMediaStore/MediaPackageを使ったライブ動画配信の基本構成を抑えつつ、CBS SPORTS/SPORTSLIVEでの事例をもとに実際のユースケースを紹介するセッションでした。チャンネルが多くなったり、また既存の仕組みをベースにAWS Media Servicesを使うとなるといろいろと工夫が必要となりますね。とはいえ、AWS Media Serivcesのアップデートもあり工夫次第で要件を満たしたアーキテクチャの構築が可能です。またAWS Media ServicesのみにとらわれずAWSのソリューションとして考えるということが大事だと思いました。
25
