MXF: それは何ですか、どのように機能しますか、そしてなぜまだ世界の問題を解決していないのですか?

MXF は単なるファイル形式ではなく、大規模なファイルベースのワークフローを構築するためのツールであり、その成功はそれをどのように使用するかによって決まります。 AmberFin のテクノロジーディレクターであり、MXF 仕様の共著者である Bruce Devlin が、このトリビューンでフォーマットの現状と将来の予測についてレビューしています。

1990 年代、多くのエンドユーザーやメーカーを代表するエンジニアのグループが、ファイルベースのワークフロー内でビデオ、オーディオ、データ、および関連するメタデータの交換を容易にするオープンファイル形式を開発するという使命を持って集まりました。この取り組みは、2004 年に SMPTE によって承認された MXF (マテリアル交換フォーマット) の開発につながりました。

私たちが最初に MXF を設計したとき、いくつかの基本的な設計要件がありました。つまり、ファイルがディスク、NLE、またはプレイアウトサーバーに完全に転送される前であっても、ユーザーがファイルの作成中であっても使用および操作できるようにしたいと考えていました。私たちは、個別のコンポーネントの同期を可能にし、中断からの正常な回復を可能にし、そのファイルに十分な情報が含まれていて、最終的な破損から簡単に回復できるようにすることが重要であると考えました。そしてもちろん、オープンで標準化され、圧縮形式に依存しないものでなければなりません。しかし何よりも、シンプルかつ柔軟である必要がありました。

基本的な設計要件に加えて、MXF には主要な運用目標もありました。それは、MXF をさまざまなワークフローに適用でき、番組、映画、またはニュースクリップのライフサイクル全体にわたってメタデータと内容を忠実に伝えることです。

運用目標

コンテンツのライフサイクル中に、コンテンツはますます多くのエッセンスとメタデータを蓄積し、最終的には再生システムや他の種類の配信ネットワークや出版ネットワークに送信する準備が整います。

MXF は、制作チェーン全体でマテリアルを転送し、プロジェクトの進行に応じてメタデータとさまざまなバージョンのマテリアルを収集し、最終的にビットレート、解像度、サービス品質の要件が異なるさまざまな宛先にコンテンツを配信するように設計されています。

MXF はワークフローを念頭に置いて設計されているため、ユーザーにとってすべての処理プロセスはシームレスです。バックグラウンドで静かに動作するだけです。メタデータは、制作、再生、アーカイブのプロセスを通じてコアのビデオとオーディオに関連付けられたままとなるため、メタデータを再入力する必要はありません。

MXF メタデータビューと物理ビュー

運用目標を支援するために、MXF は 2 つの異なる方法で表示されるように設計されています。

ファイルのメタデータビューは、ファイルが表現しようとしている映画またはテレビ番組のタイプを表し、ファイルの物理ビューはハードドライブの表面上でバイトがどのように配置されているかを表します。

この図は、左側に MXF ファイルのメタデータビューを示し、右側にこれらのバイトがディスク上にどのように配置されるかを示す物理ビューを示しています。

メタデータビューには、2 つの異なるタイプのパッケージがあります。1 つは MXF ファイルのタイムラインと「再生」ボタンを押したときに何が起こるかを説明するマテリアルパッケージ、もう 1 つはファイルに物理的に保存されているビデオとオーディオを説明するファイルパッケージです。

ワークフローの一部の要素を最適化するために、同一のメタデータを持つ 2 つの MXF ファイルを 2 つの異なる方法で物理的に配置することができます。たとえば、タイプ OP1a のフレームラッパーを含むファイルでは、そのファイル内のすべてがフレームごとにインターレースされます。同じアセットを、MXF AS-02 バージョンファイルによって同期されたコンポーネントファイルのセットとして物理的に配置することができます。 MXF を使用すると、メタデータビューと物理ビューを分離できるため、メディアとそれに付随する重要なメタデータのシームレスな交換が可能になり、特定のワークフローに最適化されたさまざまなタイプの MXF を作成できます。

MXF のさまざまなタイプ

MXF は、フォーマットがユーザーコミュニティのニーズを真に満たすものであることを保証するために、ユーザーコミュニティからの膨大な量の意見をもとに開発されました。結果として得られた柔軟性により、ベンダーは競争上の差別化要因として自社のコーデックの標準の独自の解釈を開発することもできました。この固有の柔軟性により、多数の異なるタイプの MXF が実装され、それぞれが同様の MXF メタデータを持ちますが、異なるアプリケーション向けに最適化された異なる物理ビューが適用されます。

一般的な OP1a から始めましょう。OP1a は、MXF 形式の単純な「テープのような」実装であり、オーディオデータとビデオデータを単一のインターリーブ MXF ファイルに保存します。これは柔軟性があり、ファイル構築ルールに実際の制限はありません。これにより、アプリケーションが実際に非常にシンプルになります。ただし、異なるプロバイダーが相互運用する場合に相互運用性の問題が発生するという欠点があります。

OP1a に近いのは、XDCAM HD フォーマットです。 Sony によって設計された XDCAM HD は、OP1a よりもはるかに制限されています。相互運用性がはるかに優れており、主に 50 Mbps の HD などの低ビットレートを必要とするワークフローで使用される傾向があります。欠点は、最大 8 つのモノラル AES オーディオチャネルを持つように指定されており、これらの制限があっても相互運用性の問題が残ることです。現在、Advanced Media Workflow Association (AMWA) 内にワーキンググループがあり、XDCAM の相互運用性を検討し、AS-10 と呼ばれるさらに限定されたバリアントを定義しています。

それでは、MXF の最も一般的なコンポーネントバージョンの 1 つである OP-Atom を見てみましょう。

Avid は MXF 標準への主要な貢献者であり、MXF の特定のバリアント、いわゆる Op-Atom の作成を後援しました。これは非常に制限されており、許可されるコンポーネントは 1 つだけであり、すべてのコンポーネントの同期は AAF ファイル内で行われます。ただし、Avid Media Composer によって生成された OP-Atom ファイルには、MXF 以外のメタデータが含まれることがよくあります。これは「ダークメタデータ」として知られており、異なるメーカー間でファイルを交換する際に相互運用性の問題が発生する可能性があります。

Panasonic P2 システムも OP-Atom を使用して、ビデオとオーディオの本質を記録します。 P2 形式は非常に制限されており、優れた相互運用性とメタデータの拡張可能な使用を備えています。ただし、P2 ファイルのサイズには一定の制限があり、動作上の問題が発生する可能性があります。一方、P2 設計では、オーディオとビデオを同期するために MXF ではなく XML 形式を選択しました。 XML 同期ファイルは保存された MXF メディアを参照しますが、XML 構造は汎用 MXF ファイルとの往復でメタデータを失う可能性があります。

デジタルシネマで使用される別の種類のコンポーネント MXF があり、これも CPL (コンポジションプレイリスト) と呼ばれる、ファイルを同期する別の方法を使用します。この XML ファイルの構造は、P2 XML および AVID AAF とは異なります。これは非常に限定された形式であり、デジタルシネマ配信のあらゆる側面に非常に適していますが、RGB および JPEG 2000 色空間に限定されているため、汎用の交換形式としては制限が多すぎ、テレビのワークフローには適していません。

さまざまなベンダー間でのシームレスな動作を保証するための MXF 標準の取り組みにもかかわらず、MXF のさまざまな「タイプ」が非互換性の問題を引き起こし続けていることがわかり始めています。また、メーカーが標準のより適切な実装を学ぶにつれて相互運用性は向上していますが、ユーザーは依然として、MXF ファイルの互いのバージョンを読み取れない互換性のないシステムによって引き起こされるいくつかのフラストレーションを抱えています。

この問題により、AmberFin を含むメディア企業と AMWA を通じた十数社のベンダー間の新たな協力が行われ、シンプルで簡単な相互運用性の基礎としていくつかのアプリケーション仕様 (AS) が開発されました。

アプリケーション仕様は、どのプロバイダーにも固有のものではありません。これらは、ワークフローの特定の時点での技術的および運用上の要件に一致するように、ファイルの構築方法に関する一連の制約を定義します。

たとえば、放送局、番組の特定のジャンル、または配信チャネルの技術的慣行など、さらに厳しい制限が必要な場合、これらは「ウェッジ」、つまり施設固有の一連の制限として定義できます。これは企業によって定義され、管理およびバージョン管理された文書に記述されます。

たとえば、MXF の AS-02 および AS-03 は、組織内および組織間のファイルベースのワークフローを合理化するように設計されています。

AS-02 はマスタリングツールです。は、バージョン管理ソフトウェアの課題に直面しているコンテンツ作成者や配信者のニーズを満たすように設計されています。 AS-02では、音声、映像、データを別々のメディアファイルに保存し、配信するプログラムの効率的なバージョン管理を可能にします。 AS-02 は「コンポーネント化」ファイル形式です。これは単一のファイルではなく、パッケージの概念に基づいて結合され、フォルダーに収集された一連の要素です。パッケージは完全に自己完結型であり、複数バージョン、複数言語、複数配信メディア環境で使用するために、複数バージョンのプログラムを生成するために必要なすべての資産とメタデータが含まれています。

現在、この形式の「読み取り」サポートは非常に充実していますが、「書き込み」サポートは遅れています。 AS-02 フレームワークは、マルチバージョンのワークフローを非常に高速化することができ、施設のネットワークインフラストラクチャにある程度の負荷をかけることができます。

MXF の AS-03 は、完成したコンテンツをプレイアウトサーバーに直接配信することを目的としています。 AS-03 は、MXF ツールボックスに、コンパクトで堅牢かつ直接再現可能な形式で最終結果を効率的に提供するように強制します。 AS-03 ファイルは、常に 1 つのプログラムに対して 1 つのファイルです。これらのファイルの内容は処理を目的としたものではなく、サーバーから直接再生することを目的としています。ファイルには、完成したプログラムまたはプログラムセグメントとそれに関連するメタデータが含まれており、通常はビデオ、オーディオ、字幕に加えて、ファイルを説明する技術的なメタデータと AS-03 固有のメタデータが含まれます。 AS-03 ファイルには、配信されたトラフィックメタデータに対するコンテンツの識別と検証のために、定義されたメタデータセットが含まれています。

AS-03 は、MPEG2 コンテンツをプレイアウトサーバーに配信する場合には完璧に機能しますが、放送局とポストプロダクション会社の間で同じフォーマットを使用して投稿する場合は、いくつかの変更が必要です。これらのアプリケーションの違いに対処するために、AMWA は、番組制作者から放送局または番組作成施設に完成した番組を配信するためのファイル形式である AS-11 を開発しています。 AS-03 をベースに構築された AS-11 では、コントリビューションの目的で、より高いビットレートの MPEG (または非 MPEG) コーデックを許可する必要があります。 AS11 の最初の実装は、AVCIntra コーデックに基づいて UK Digital Production Partnership によって提案されています。

これは、最も一般的な MXF 形式のいくつかについての非常に簡単なツアーでした。ワークフローを計画するときは、それぞれをいつ使用できるかを慎重に検討する価値があります。オーディオのバージョン管理ワークフローを実行したい環境、またはさまざまなワークフロービットごとにさまざまなコンポーネントを保存する必要がある環境にいる場合は、AS-02 のようなものが非常に合理的です。ただし、A から B に移動する場合など、エッセンスとメタデータを一緒に移動しようとしている場合は、AS-03 や AS-11 のような形式の方が適切である可能性があります。結局のところ、これらのアプリケーション仕様は、ユーザーコミュニティがより優れた相互運用性を獲得し、適切な時と場所で適切な MXF 形式を選択しやすくなるように特別に定義されています。

MXF に取り組んでおり、その継続的な開発に貢献することに興味がある場合は、SMPTE Web サイト http://smpte.org にアクセスして、標準コミュニティに参加してください。 Web サイトには、参加できるすべてのグループのリストが含まれています。 MXF の本もあります。これは、MXF 標準の目的についての優れた資料を提供します。何よりも、MXF は単なるファイル形式ではないことを覚えておいてください。これは、大規模なファイルベースのワークフローを構築するための単なるツールです。 MXF の成功は、そのツールをどのように使用するかにかかっています。