「その構成、AWSに置き換えられますよ」。設備更新の相談をしたベンダーから、見慣れない構成図が返ってきます。図の中にはMediaLive、MediaConnect、MediaPackageと、似た名前のサービスが並んでいる。どれもAWSのロゴ付きです。エンコーダーの話なのか、回線の話なのか、配信サーバーの話なのか。名前を眺めているだけでは、自分たちの設備のどこに当たるのかが分かりません。マスターの更新に大きな投資を重ねてきた側からすれば、戸惑うのが自然です。

AWS Media Servicesは、ライブ配信とVOD配信に必要な工程をサービス単位に切り分けた、AWSのクラウドサービス群の総称です。工程単位に切ってある、という点が肝になります。放送設備が担ってきた「運ぶ」「圧縮する」「配信形式に整える」という仕事と、ほぼ一対一で対応づけられるからです。

AWS Media Servicesの構成要素、放送のどの工程に当たるか

AWS Media Servicesのライブ配信パイプラインとVOD変換レーンの構成図

入口はMediaConnectです。中継先や局舎からクラウドへライブ映像を運び込む伝送サービスで、 SRTプロトコル やRTP、Zixi、RISTを受けられます。専用線やFPUが担ってきた「運ぶ」工程に相当し、クラウド側に用意した受け口へ、地上の設備からストリームを打ち上げる形になります。

運び込んだ映像を圧縮するのがMediaLiveです。役割はマスターや中継現場に置かれてきたライブエンコーダーそのもので、受け取ったストリームから、画質の異なる複数の配信用ストリームを同時に作ります。スマートフォン向けの低ビットレートから大画面向けの高ビットレートまでを一度に吐き出す、ABR(アダプティブビットレート)配信の心臓部です。

MediaPackageは、エンコード済みの映像を HLSやMPEG-DASH といった配信フォーマットに整えて送り出す、パッケージングの工程を受け持ちます。リクエストに応じてその場で形式を組み立てるため、一つのソースからHLSとDASHの両方を出せます。DRMによる暗号化や追いかけ再生への対応も、この層の仕事です。

ここまでがライブの本線で、その下にもう一本、ファイルのレーンが走っています。MediaConvertです。完パケやアーカイブ素材を配信用ファイルに変換する、ファイルベースのVODトランスコーダーで、ライブの系統とは独立に使えます。実際、ライブには手を付けず、VODの変換だけをMediaConvertに出すところから始める例は少なくありません。

伝送、ライブエンコード、パッケージング、VOD変換。カタカナの名前を工程に置き直してしまえば、見慣れた放送の流れです。

Elemental LiveとMediaLiveの違い、名前が似ている理由

オンプレミス機器のElemental LiveとクラウドサービスのMediaLiveの対比図

調べていくと、もう一つ紛らわしい名前にぶつかります。AWS Elemental Liveです。MediaLiveと同じライブエンコーダーなのに、こちらはクラウドサービスではなく、ラックに収める機器として売られている。なぜ同じ会社に二つあるのでしょうか。答えは買収の経緯にあります。

AWSは2015年、米オレゴン州の映像エンコーダー企業Elemental Technologiesを買収しました。放送・配信業界で実績のあった同社の製品群は、買収後もAWS Elementalブランドのオンプレミス製品として残り、Elemental Liveはその代表格です。一方で、同じ技術の系譜をクラウドのマネージドサービスとして再構成し、2017年に発表したのがMediaLiveをはじめとするMedia Servicesでした。両者は兄弟のような関係で、血筋は同じ、提供形態が違うのです。

提供形態の違いは、そのまま運用の違いになります。Elemental Liveは資産として購入し、局内でSDI信号を直接受け、自分たちの手で保守する機器です。素材を外に出さず局内で完結できる代わりに、更新も故障対応も自前で抱えます。MediaLiveは起動時間に応じて課金されるサービスで、機器の保守もソフトウェアの更新もAWS側の仕事です。検索で両者の情報が混ざって出てきたら、「箱か、サービスか」で読み分けると迷いません。

放送局が導入する際の論点、冗長化・伝送コスト・既存設備

では実際に導入するとして、何を詰めておくべきでしょうか。放送の現場で最初に問われるのは冗長化です。MediaLiveのチャンネルにはスタンダードとシングルパイプラインという二つのクラスがあり、スタンダードでは二つのパイプラインを別々のアベイラビリティーゾーン(独立したデータセンター群)で並走させ、入力も二系統受けます。放送の現用・予備の考え方が、そのまま持ち込まれている設計です。ただし、二系統の入力を局側から本当に別経路で打ち上げられるかは、地上側の回線設計の問題として残ります。

次に伝送コストです。クラウドは、データを入れる方向はほぼ無償でも、外へ出す方向(エグレス)に課金されます。ライブ配信は流しっぱなしですから、視聴者へ届ける帯域だけでなく、確認モニター用に局へ引き戻す帯域にも課金が積み上がります。単価はリージョンや契約条件で変わるためここでは挙げませんが、「クラウドから出ていく映像は何本あるか」を数えることが、見積もりの出発点になります。

最後が既存設備との接続です。局内の伝送がSDIであれ SMPTE ST 2110 のようなIPであれ、クラウドへの入口はインターネットか専用接続を通るIP伝送になります。ここでMediaConnectのプロトコル対応が効いてきます。SRT対応のエンコーダーや伝送装置をすでに持っているなら、それをそのまま打ち上げ側に使えるからです。もっとも、未放送の素材をそもそも局の外に出せるのかという判断は技術より前にあり、 放送素材のセキュリティ設計 として別途詰めておく必要があります。

どの論点も、クラウドが使えるかどうかではなく、どう組み込むかの話です。

冒頭の構成図に戻りましょう。あの図が本当に問うていたのは、「設備をまるごとクラウドにするか」ではありません。伝送、エンコード、パッケージング、VOD変換という工程のうち、どれをいつ移すかです。VODの変換だけをMediaConvertに出す局もあれば、配信専用のチャンネルだけをMediaLiveで組み、本線のマスターはオンプレミスに残す局もあります。全部か無かの二択に見えたものは、工程ごとの設計問題でした。自分たちの設備を工程に分解したとき、最初に切り出せるのはどこでしょうか。

NAXAの取り組み

NAXAはテレビ業界向けの独自技術として、日本語に特化した音声認識エンジンと、テロップ・字幕に対応した画像解析・OCRエンジンを保有し、放送・映像分野のシステム開発を手掛けています。Media Servicesのようなクラウド基盤に映像が集まる構成では、その流れのどこに字幕生成や映像解析といったAI処理を差し込むかが設計の焦点になります。工程単位でクラウドと付き合う発想は、AIの導入でもそのまま通用します。

放送設備のクラウド移行や、クラウドとオンプレミスを組み合わせた映像パイプラインの構築に関心のある方は、お気軽にご相談ください。