TAMS

収録した素材から3分だけ切り出したい。そのために素材全体をコピーして、別のファイルとして保存する。ファイルを単位にした運用では当たり前の動きですが、同じ映像が何本も増えていきます。TAMSは、素材を時刻で指し、実体を複製せずに扱うための取り決めです。

TAMSが使われる場面

想定されているのは、収録した映像を止めずに受け続けながら、その途中から切り出して次の工程へ渡す使い方です。長時間の生中継や、複数カメラの収録を丸ごと受けておく運用では、素材が「いつ終わるか分からない連続した流れ」になります。ファイルとして閉じるのを待たずに、時刻を指定して取り出せることに意味があります。

クラウドでの制作でも使われます。素材をオブジェクトストレージに置き、編集や書き出しの処理をその場で立ち上げる構成では、素材をダウンロードして渡す手間が処理時間の大半を占めることがあります。参照だけで済ませられれば、必要な区間のオブジェクトだけを読めば足ります。

アーカイブから使い回す場面でも効きます。過去の番組から5秒だけ引用するとき、映像アーカイブから全体を取り出さずに済みます。MAMが検索と権利を扱い、その下でTAMSが実体の出し入れを担う組み合わせが想定されています。

TAMSの仕組み

TAMSはHTTPのAPIとして定義されていて、扱う概念は次のように分かれています。

• Source は「この内容」という抽象的な単位です。1つの収録に対して、高画質のものと確認用の軽いものというように、複数の実体を束ねます
• Flow は無限に続くタイムライン上に置かれた実体です。UUIDで識別され、いったん書いた部分は書き換えません。後ろへ伸ばすことと、隙間を埋めることはできます
• Flow Segment は、Flowを区間に割ったものです。区切りは単独でデコードできる単位に合わせ、MPEG-TSなどの入れ物に包まれます
• Timerange は、タイムライン上のどこからどこまでかを表す指定です。読み書きはこの指定で行います
• Media Object は素材の実体で、オブジェクトストレージに置かれます。メタデータは別のデータベースが持ちます

実体とメタデータを分けた効き目が、コピーオンライトの扱いです。複数のFlowが同じMedia Objectを参照できるので、クリップを作っても、プロキシを別に持っても、変わっていない区間は元のオブジェクトを共有したままになります。ファイルを単位にした運用で起きる「ほぼ同じ映像が何本もある」状態を避けられます。

AWSのawslabsからは参照実装が公開されていて、API GatewayとLambdaでAPIを受け、メタデータをDynamoDBとNeptuneに、実体をS3に置く構成になっています。仕様の版はバージョン7に対応し、保管先を差し替えられる形です。開発環境での利用を想定したものと説明されています。

TAMSで間違えやすい点

• TAMSは製品ではなくAPIの仕様です。導入するには仕様に沿った実装を選ぶか、自分で組む必要があります
• Flowは書き換えない前提です。素材を直したい場合は新しいFlowを作り、Sourceの下に並べる形になります
• 時刻で指すといっても、指しているのはFlowのタイムライン上の位置です。収録時のタイムコードや放送の実時刻との対応付けは、別に管理する必要があります
• 編集ソフトが直接TAMSを読めるわけではありません。既存のワークフローにつなぐには、区間を取り出してファイルとして渡す層が要ります
• オブジェクトストレージの読み出し回数と転送量が費用になります。ファイル1つを読む構成とは費用の出方が変わります

よくある質問

TAMSとMAMはどちらを導入すればいいですか

層が違うので置き換えにはなりません。MAMは検索、権利、工程の管理まで含む仕組みで、TAMSはその下で素材の実体を時刻で出し入れするAPIです。MAMの保管層としてTAMSを使う、という組み合わせが想定されています。

TAMSはファイルベースの運用と何が違いますか

ファイルベースでは、切り出しや画質違いを作るたびに実体が増えます。TAMSはFlowという参照の集まりで表現するので、変わっていない区間は同じオブジェクトを共有したままになります。素材が閉じるのを待たずに途中から読める点も違いです。

TAMSはどこで仕様を読めますか

BBCがGitHubで公開しており、Apache License 2.0のもとで利用できます。APIの定義と解説がまとめられていて、AWSのawslabsからは参照実装も公開されています。