最近、MXFファイルという言葉をよく耳にするようになった。しかし、その中身についてはまだまだ知られていないことも多い。ここでは、ワークフロー構築の前に知っておきたいMXFの概要と課題についてまとめておこう。

MXFは、Material eXchange Formatの略称で、映像・音声を機器間やシステム間でやりとりする際のデータの持ち方を規定した規格である。1999年頃から業界団体のPro-MPEGフォーラム（*1）、米国SMPTE（*2）、欧州EBU（*3）が共同で開発してきたものだ。2003年にSMPTEから、SMPTE 377Mとして規格書が発行され、ファイルによる映像制作業務を進める上で必要となるさまざまな機能を盛り込んだ規格として標準化された。MXFは、ソニーのXDCAMやパナソニックのP2、池上通信機のGFで採用されて一般に知られるようになったが、もともと業務用映像ファイルフォーマットの標準として策定されてきたことから、最近ではカメラやビデオレコーダだけでなく、素材から送出に至るまでの幅広い用途で活用されてきている。

（*1）Pro-MPEGフォーラム：英国国営放送局BBCを中心に結成され、世界の放送局やプロダクション、メーカーなど130社以上が参加して標準規格を策定する業界団体。
（*2）SMPTE：Society of Motion Picture and Television Engineers＝映画テレビ技術者協会。「シンプティ」と呼ばれる。米国内の映画、テレビに関わる技術者を中心に、映像技術全般の標準化を進めている団体。参加は、法人、団体、個人を問わない。
（*3）EBU：European Broadcasting Union＝欧州放送連合。欧州の放送事業者を中心として、標準化を進める団体。

自由度の高い、幅の広い規格として策定

MXFは、特定の映像や音声の圧縮技術（コーデック）に依存しない、自由度の高い、幅の広い規格として設計されている。規格策定をする段階において、「使用するコーデックは特定できないし、特定をすべきでもない」という観点で、さまざまなコーデックを許容しているのだ。映像・音声のファイルは、非圧縮であったり、圧縮技術を使用して圧縮したデータであったりする。MXFでは、これらの映像データ、音声データに加え、タイムコードやSDIのアンシラリ情報についても同期をとってファイル化する必要がある。そこで、MXFでは、「ラッピング（wrapping）」という概念を持ち込み、映像データ、音声データを「包む」「器」としてのフォーマットとなった。

さらに、MXFでは、ファイル上でのデータの持ち方も、「オペレーショナルパターン」という分類でレベル分けすることで、複数の方式を許容している。規格のどの部分をどう使うかについては、実装者である機器メーカーやソフトウェアメーカーにゆだねられている。このため、MXFという枠組みでは共通で互換性があるのだが、実用の観点で見ると、MXFと言いながらも共通ではなく、互換性のない（少ない）別のフォーマットとして見えるMXFファイルが存在することになってしまった。

データの持ち方の違い、つまりラッピング形式の違いは、比較的容易に差し替えることが可能だ。まだ対応しているソフトウェアは少ないが、ラッピングの変更だけであれば画質も劣化しないし、ファイルの読み書きの速度に近い速度での処理が可能になる。MXFの互換性で一番留意が必要な点は、コーデックの違いだ。コーデックが異なると、再エンコード処理が必要となるばかりか、画質が劣化し、処理時間もかかってしまう。コーデックが違っていても、ノンリニア編集ソフトウェアなどの読み込み側が対応していれば再エンコードは必要なくなる。そのため、最近のノンリニア編集ソフトウェアでは、複数のコーデックを搭載することで、コーデックの違うMXFファイルも読み込めるようになりつつある。ソフトウェアが、使用するMXFに対応しているかどうか。処理にかかる時間や運用性には十分留意する必要がある。

例えば、XDCAMのMXFファイルとP2のMXFファイルでは、互いに互換性はないものになっている。オペレーショナルパターンで見れば、ソニーは同一ファイル中に映像・音声を格納するOP1aを採用し、パナソニックは映像・音声を別ファイルとして格納するOP-Atomを採用している。ノンリニア編集ソフトウェアで扱うのには、映像・音声が別ファイルの方が読み書きが容易ではある。しかし、OP1aが編集に不向きかと言うと、そうとも言い切れない。最近のPCの性能向上を考慮すると、ソフトウェアで吸収できる範囲だろう。

むしろ、ノンリニア編集で影響が大きいのは、ファイル形態よりも、映像そのものがフレーム独立か否かという部分だ。パナソニックP2のDVCPRO HD（DV100）やAVC-Intraはフレーム独立のコーデックであるし、ソニーXDCAM HDのMPEG-2 Long GOPではフレーム間圧縮をしているコーデックとなっている。もちろんフレーム独立のコーデックの方が編集は容易だが、コーデック処理の重さという観点からみると、MPEG-2 Long GOPよりAVC-Intraの方が重いということになる。

ノンリニア編集ソフトウェアでのMXFファイルの処理速度は、これらのバランスで決まってくるから難しい。

エッセンスをサンドイッチにした構造

MXFの構造は、大きく分けて、「ヘッダ／フッター」と「エッセンス」の2つに分けられる。この役割については後で解説する。MXFでは、各種メタデータの入ったヘッダ／フッターの間に、エッセンスが含まれるサンドイッチ構造を採っている。さらに、さまざまなデータを格納するための工夫もなされている。MXFファイルは、「KLV（Key-Length-Value）」と呼ぶデータ要素の集まりで構成されており、メタデータ、映像・音声データなど、すべてのデータがKLV構造をとっている。KLV構造は、各データにその中身とデータサイズが分かるようにKey(タグ)が付けられたものであり、読み込み側で扱えないデータについては、Keyを見て読み飛ばすことも容易になっているわけだ。

これが、MXFの基本的な構造だが、もう少し詳しく見ていこう。MXFでは、格納される映像・音声データを「エッセンス」と呼んでいる。現在、以下の表にあるようにエッセンスが規定されている。

ビデオ	非圧縮	4:2:2、4:4:4:4
	DV	DV25（DV、DVCAM、DVCPRO）、DV50（DVCPRO50）、DV100（DVCPRO HD）
	D11	HDCAM
	MPEG-2	IMX（D10）、Long GOP、I-only、MPEG-2 TS、MPEG-2 PS
	MPEG-4	プロキシ用
	H.264	AVC-Intra（I-only）、Long GOP
	JPEG2000
	VC-1	Windows Media Video 9
	VC-3	DNxHD
オーディオ	非圧縮	AES3、BWF
	MPEG	MPEG-1 Audio
	A-law	プロキシ用

ビデオデータの場合、1フレーム単位で格納されることが多いが、MPEG-2 TSやMPEG-2 PSなどのようにストリーム単位で格納することもできるようにしている。編集性だけを考えるとフレーム単位で格納すべきだが、MPEG-2 TSのまま扱えるようにしたことで、データ放送や字幕放送のデータをMPEG-2 TSのまま格納することもできるようになった。フレーム単位、ストリーム単位どちらの方式で格納するかは、MXFの用途に合わせて決めれば良いというわけだ。しかし、MPEG-2 TSのまま格納すると、フレーム単位の処理を前提としている機器では読み込めなくなってしまう。このように、機能を優先すると、互換性を犠牲にしなくてはならない。

ここまで述べてきたように、MXFを扱う上でコーデックの違いによる互換性問題は頭の痛い点だが、それでもMXF化することにメリットがある。ラッピング方式がMXFで統一されるため、コーデックに関係ない情報については共通化できるのだ。この情報には、タイムコードやアンシラリデータ、さらにメタデータが該当する。

MXFで扱うメタデータとしては、「構造系メタデータ（Structual Metadata）」と呼ばれるものと、「記述系メタデータ（Descriptive Metadata）」と呼ばれるものに、大きく2種類に分けて定義されている。構造系メタデータは、ビットレート、尺、映像の解像度、フレームレート、音声のサンプリングレート、量子化ビット数など技術的な情報を扱う。これに対し、記述系メタデータでは、タイトル、内容の説明、権利情報など非技術的な情報を記述する。どちらのメタデータもヘッダと呼ばれる領域に格納されており、ヘッダを読み込むだけでメタデータを得ることができる。さらに、メタデータはフッタと呼ばれるファイル末尾の領域にも格納できる。そのため、伝送に利用する場合などでは、エッセンスの送信中にメタデータを更新した場合も、フッタに再度メタデータを記述すればよいということになる。また、ヘッダとフッタの両方にメタデータを格納することで耐障害性を高めることもできる。

さて、記述系メタデータは、編集や伝送など、使用する用途や運用によって必要な項目が異なる。これは、ワークフローにおいて必要となるメタ情報が異なるため仕方がないとも言える。そのため、全てを規格化することは難しいが、MXFでは標準の記述系メタデータとして「DMS-1 (Descriptive Metadata Scheme)」を規定している。DMS-1は、他のメジャーなメタデータ標準である、AAF（Advanced Authoring Format）との連携はもちろん、MPEG-7、TV Anytime、P/Metaとの連携も考慮して策定された。DMS-1は、以下の3つのフレームワークで構成され、各フレームワークはさまざまなメタデータ項目を持つ。

　　1. Production（作品につけるメタデータ）
　　2. Clip（素材につけるメタデータ）
　　3. Scene（特定の場所につけるメタデータ）

DMS-1は、さまざまなメタデータの最大公約数として策定されている。項目名は決まっているが、その項目にどのような内容を書くかについては規定がないという、緩やかな規定である。それは、文字数の規定もないというほどだ。「タイトル」というメタデータ1つをとっても、連続ドラマの場合、番組のシリーズ名称なのか、番組の回の内容を表すものなのかなど、さまざまな解釈ができるだろう。このように、実際の運用では、運用ルールを決めないと曖昧なものになってしまいがちなので注意したい。DMS-1では、権利情報も記述可能だ。例えば、Participants(関係者）、Contact List(連絡先）、Contract(契約情報）といった中項目がある。

ここまでMXFについて説明してきた。MXFには、取り扱い可能なエッセンスにJPEG2000が規定されていることからも分かるように、デジタルシネマ配信フォーマットとしても採用されている。今後は、放送業界にとどまらず、交換・配信用の標準ファイルフォーマットとして広く普及していくことが見込まれる。Material eXchangeという名前のとおり、機器間やシステム間でのやりとりや、アーカイブとして保存しておくフォーマットとして、当面はこれ以上のフォーマットは出てこないとも考えられる。近い将来、さまざまな形式のMXFファイルを一様に読み込み、互換性の壁を超えて処理できる製品が増えてくることを期待したい。

竹松 昇（アイ・ビー・イー・ネット・タイム）