AWS Elemental MediaTailor

配信で広告を差し替える仕組みを自前で作ると、視聴者ごとのマニフェストの生成、広告素材の画質段そろえ、視聴計測の通知まで抱えることになります。MediaTailorは、その部分をAWS側に任せるためのサービスです。もう1つの機能であるチャンネルアセンブリは、手持ちのVOD素材から放送のような編成の流れを作ります。

MediaTailorが使われる場面

広告付きの無料配信や、24時間編成で番組を流し続けるチャンネルの運用で使われます。SSAIの構成をゼロから組むと、同時視聴者数に合わせてマニフェスト生成の処理能力を用意する必要がありますが、マネージドサービスならそこを設計から外せます。

放送の同時配信でも使われます。放送で流すCMのうちネット配信の権利がない枠を、ネット向けの広告や差し替え映像に置き換える用途です。枠の位置は上流の送出設備やエンコーダーが打ったSCTE-35のキューで伝わります。

チャンネルアセンブリは、過去の番組やアーカイブ素材を並べて擬似的な編成を作る場面で使われます。すでにエンコードとパッケージングが済んだVODのマニフェストを並べ直すだけなので、24時間分をもう一度エンコードし直す必要がありません。

MediaTailorの仕組みとオリジンに必要なもの

広告挿入の機能は、プレイヤーとオリジンの間に入ってマニフェストを書き換える形で動きます。オリジン側に要るものは次の通りです。

• HLSまたはMPEG-DASHのマニフェストを返すオリジン。AWS Elemental MediaPackageのようなパッケージャーを置くのが一般的な構成
• ストリームに入ったSCTE-35のキュー。ライブの広告枠はこれを手がかりに見つける
• 標準のHTTPまたはHTTPSのポート。独自のポート番号を使うオリジンは扱えない
• 広告判断サーバー（ADS）。MediaTailorが問い合わせ、VASTやVMAPで返ってきた広告を枠に当てる

チャンネルアセンブリはこれとは性格が違い、マニフェストだけを扱います。セグメントには手を触れず、オリジンから視聴者へ直接配られます。MediaTailorはVODのマニフェストを取ってきて、ライブのようにスライドしていくマニフェストの窓を組み立て、素材が切り替わってもメディアシーケンス番号が連続するよう面倒を見ます。チャンネルアセンブリで広告枠を入れる場合は、素材にSCTE-35のキューを仕込んでおく必要がありません。スケジュールの側で枠を指定できます。

MediaTailorの運用で間違えやすい点

• 広告素材の画質段が本編とそろっていない。MediaTailorは初めて見る広告素材を変換してから使うため、変換が済むまでその広告は飛ばされ（ログ上はNEW_CREATIVE）、枠はスレートか本編で埋まる
• 広告と本編で音量の基準が違い、広告だけ大きく聞こえる。ラウドネスの正規化は入稿の段階で済ませておく
• 視聴者ごとにマニフェストが変わるため、マニフェストはCDNでそのままキャッシュできない。セグメントは従来通りキャッシュできる
• 広告の再生を広告サーバーへ知らせる通知を、サーバーから送るかプレイヤーから送るかで計測の数え方が変わる
• 本編だけDRMで暗号化し広告は暗号化しない構成で、境目の切り替えに対応できない端末が出る

よくある質問

MediaTailorとMediaPackageはどちらが必要ですか

役割が違うので、広告を差し替えるなら両方を組み合わせるのが標準的な構成です。MediaPackageがセグメントとマニフェストを作ってSCTE-35をマニフェストに書き出し、MediaTailorがそのマニフェストを視聴者ごとに書き換えます。

チャンネルアセンブリはエンコードもしてくれますか

しません。マニフェストだけを扱うサービスなので、素材はあらかじめ複数ビットレートでエンコードしてパッケージングしておく必要があります。逆に言えば、既存のVOD素材があれば追加のエンコード費用なしで編成を組めます。

MediaTailorの広告は広告ブロッカーで消せますか

広告が本編と同じ形式のセグメントとしてマニフェストに並ぶため、ブロッカーでは見分けにくく、消されにくくなります。ただしプレイヤーから送る計測の通知は止められる場合があります。