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

MXFはファイル形式であるだけでなく、成功が使用方法に依存するファイルに基づいて大規模なワークフローを構築するためのツールです。アンバーフィンテクノロジーのディレクターであり、MXF仕様の共著者であるブルースデヴリンは、フォーマットの現在の状況と将来の予測をレビューします。

1990年代、多くのエンドとメーカーを代表するエンジニアのグループがミッションに会いました。ファイルベースのワークフロー内のビデオ、オーディオ、データ、関連するメタデータの交換を容易にするオープンファイル形式を開発します。このイニシアチブは、2004年にSMPTEによって承認されたMXF（Exchange Format Material）の開発につながりました。

最初にMXFを設計したとき、一連の基本的な設計要件がありました。ディスク、NEL、またはPlayoutサーバーに完全に転送される前に、ユーザーが作成されたときでさえ、ユーザーがファイルを使用して使用することを望んでいました。コンポーネントの同期を個別に許可し、中断の前に風通しの良い回復を提供することが重要であるように思われ、そのファイルに含まれる十分な情報があることを保証して、最終的な腐敗から簡単に回復できるようにします。そして、もちろん、それはオープン、標準化され、圧縮形式から独立している必要がありました。しかし、何よりも、それはシンプルで柔軟でなければなりませんでした。

基本的な設計要件とともに、MXFの主要な運用目標もありました。プログラム、映画、またはニュースクリップのライフサイクル全体で、メタデータとエッセンスを忠実に運ぶために、さまざまなワークフローに適用できるようにしました。

運用目標

ライフサイクル中、コンテンツは、最終的にプレイアウトシステム、またはその他のタイプの流通または公開ネットワークに送信する準備ができるまで、ますます多くのメタデータを蓄積します。

MXFは、プロジェクトが進行するにつれて、生産チェーン全体に材料を輸送し、メタデータとさまざまなバージョンの素材を収集するように設計されており、ビットレート、解像度、およびサービス品質の異なる要件を持ついくつかの目的地に最終的にコンテンツを配布することを目的としています。

MXFはワークフローについて考えて設計されているため、すべての操作プロセスはユーザーに最適です。単に沈黙の中で、背景に作業します。メタデータは、制作、プレイアウト、アーカイブプロセスを通じて、ビデオとオーディオの本質と統合されたままであるため、メタデータを再導入する必要はありません。

メタデータのビューとMXFの物理的見解

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

ファイルのメタデータビューは、ファイルが表現しようとしている映画またはテレビ番組の種類を表し、ファイルの物理的ビューはハードドライブの領域でバイトの配置方法を表します。

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

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

ワークフローの要素を最適化するために、同一のメタデータを持つが、2つの異なる方法で物理的に配置された2つのMXFファイルを用意することができます。たとえば、OP1Aタイプフレームラッピングを備えたファイルでは、そのファイル内のすべてがテーブルごとに絡み合ったフレームです。同じ資産は、AS-02 MXFバージョンファイルによって同期されたコンポーネントファイルのセットとして物理的に配置できます。 MXFはメタデータと物理的ビューのビューを分離できるため、それに伴う非常に重要な平均とメタデータの完全な交換を可能にし、特定のワークフローに最適化されたさまざまなタイプのMXFの作成を可能にします。

さまざまなタイプのMXF

MXFは、フォーマットが実際にニーズを満たすことを確実にするために、ユーザーコミュニティからの膨大な貢献で開発されました。結果として生じる柔軟性により、サプライヤーは、競争力のある差別化要因として、コーデックの基準の独自の解釈を開発することもできました。この固有の柔軟性により、それぞれが類似したMXFメタデータを持つ一連の異なるタイプのMXFが実装されていますが、異なるアプリケーションに最適化された異なる物理的ビューを適用しています。

一般的なOP1A：OP1Aは、MXF形式の単純な「テープのような」実装であり、オーディオとビデオデータを単一のMXFファイルに絡み合って保存します。柔軟性があり、ファイルの建設基準に実際の制限が含まれていません。これにより、アプリケーションは非常にシンプルになります。しかし、異なるサプライヤーがそれについて相互作用する場合、相互運用性の問題に苦しむという不利な点があります。

OP1Aの近親者はXDCAM HD形式です。 Sonyによって設計されたXDCAM HDは、OP1Aよりもはるかに制限されています。相互運用性がはるかに優れており、50 MbpsでのHDなどの低ビットレートを必要とするワークフローで使用される傾向があります。負の側面は、最大8つのAESモノオーディオチャネルを持つように指定されており、これらの制限があっても、相互運用性の問題が持続することです。現在、XDCAMの相互運用性を調べ、AS-10と呼ばれるさらに限られたバリアントを定義するAdvanced Media Workflow Association（AMWA）内にワーキンググループがあります。

そのため、MXFの最も一般的なバージョンの1つであるOp-Aatomを見てみましょう。

AvidはMXF標準の主要な納税者の1人であり、そのため、MXFの特定のバリアントであるいわゆるOP原子の作成を後援しました。これは非常に制限されており、コンポーネントのみを許可し、コンポーネントのすべての同期はAAFファイルで実行されます。ただし、Avidの平均的な作曲家によって生成されたOP原子ファイルには、多くの場合、非MXFメタデータが含まれています。これは「暗いメタデータ」として知られており、異なるメーカー間のファイルを交換する際に、相互運用性の問題につながる可能性があります。

Panasonic P2システムは、Op-Atomを使用して、実際のビデオとオーディオエッセンスを記録しています。 P2形式は非常に限られており、相互運用性が良好で、メタデータの拡張可能な使用があります。ただし、P2ファイルのサイズには一定の制限があり、運用上の問題を引き起こす可能性があります。一方、P2デザインは、オーディオとビデオを同期するために、XMLおよびNO MXF形式を選択しました。 XML同期ファイルはMXF保存平均を指しますが、XML構造は往復で一般的なMXFファイルでメタデータを失う可能性があります。

デジタルシネマで使用されるコンポーネントを備えた別のさまざまなMXFがあります。これは、CPL（構成プレイリスト）と呼ばれるファイルを同期する別の方法を再度使用します。このXMLファイルには、P2のXMLの構造とAAFのAAFが異なります。非常に限られた形式であり、デジタルシネマ配信のすべての側面に非常に適していますが、RGBとJPEG 2000のカラースペースに限定されているため、汎用交換形式に制限があり、テレビワークフローには適していません。

私たちが見始めているように、さまざまなサプライヤー間で機能せずに裂け目を確保するためのMXF基準の努力にもかかわらず、MXFの異なる「タイプ」は非互換性の問題につながり続けています。また、メーカーが標準をより適切に実装することを学んでいるため、相互運用性が向上していますが、ユーザーはMXFファイルの外部バージョンを読み取れない互換性のないシステムによって作成された不満を抱えています。

この問題により、シンプルで簡単な相互運用性の基礎として、いくつかのアプリケーション仕様を詳しく説明するために、AmberfinとAmwaを介したダースのサプライヤーを含むメディア企業間のコラボレーションが新たになりました。

アプリケーションの仕様は、どのサプライヤーにも特別ではありません。ファイルの構築方法に関する一連の制限を定義しているため、ワークフローの特定のポイントで技術的および運用上の要件と一致します。

たとえば、より厳しい制限が必要な場合、たとえば、放送、特定のプログラム、または流通チャネルの技術的慣行では、これらは「ウェッジ」、インストール固有の制限のセットとして定義できます。

たとえば、MXFのAS-02およびAS-03は、組織内および組織間のファイルに基づいてファイルフローを最適化するように設計されています。

AS-02はマスターツールです。バージョン制御プログラムの課題に直面しているクリエイターとコンテンツディストリビューターのニーズを満たすように設計されています。 AS-02を使用すると、オーディオ、ビデオ、およびデータは独立したメディアファイルに保存され、プログラムを効率的に制御できるように配信します。 AS-02は「コンポーネント」ファイル形式であり、一意のファイルではなく、フォルダーに収集されたパッケージの概念の下にある要素のセットです。パッケージは完全に自律的であり、平均的なマルチバース、マルチダイオーム、マルチセンターの環境で使用するために、プログラムのいくつかのバージョンを生成するために必要なすべての資産とメタデータを持っています。

今日、私たちはこの形式の非常に良い「読書」サポートを持っていますが、「執筆」のそれは遅れをとっています。 AS-02の構造は、マルチバージョンワークフローを非常に速くすることができ、インストールのネットワークインフラストラクチャに特定の負荷を生成できます。

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

AS-03は、MPEG2コンテンツをプレイアウトサーバーに配信するために完全に機能しますが、放送局とポストプロダクション会社間の貢献に同じ形式を使用する場合は、いくつかの変更が必要です。これらのアプリケーションの違いに対処するために、AMWAは、完成したプログラミング、放送局のプログラムプロデューサー、またはプログラム作成施設の配信のためのファイル形式であるAS-11を開発しています。 AS-03に基づいて、AS-11は、拠出目的で、ビット率が高いMPEG（または非MPEG）であるコーデックを許可する必要があります。 AS11の最初の実装は、Avcintra Codecに基づいて、英国の英国デジタル生産パートナーシップによって提案されています。

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

MXFで作業しており、その継続的な開発に貢献することに関心がある場合は、SMPTE Webサイトhttp://smpte.orgにアクセスして、標準コミュニティに参加できます。ウェブサイトには、参加できるすべてのグループのリストが含まれています。 MXFの本もあります。これにより、MXF標準が意図していることについての優れた読書リソースが提供されます。とりわけ、MXFは単なるファイル形式ではないことを忘れないでください。これは、ファイルに基づいて大きなワークフローを構築するための単なるツールです。 MXFの成功は、そのツールの使用方法によって異なります。