MXF

SMPTE為其定義的標準包括：SMPTE - 377M、SMPTE - EG41、SMPTE - EG42等，並不斷進行更新和完善。

1996年9月12日的國際廣播大會上，EBU（歐洲廣播聯盟）和SMPTE任命了“EBU/SMPTE比特流節目素材交換一致標準特別委員會”。這個組織（一般被提作EBU/SMPTE特別委員會）開始着手網絡環境中內容互操作性和交換的問題調查研究。在特別委員會的最終報告中指出，文件格式是影響專業影視產業引入健全網絡環境所缺少若干要素中最重要的一個要素。其不僅需要支持不同的音視頻格式，而且需要支持廣泛的元數據。Pro-MPEG論壇對特別委員會的最終報告進行了研究，最終開發出MXF文件格式。與此同時，AAF（先進製作格式）文件格式由AAF協會開發完成。這兩種文件格式正成為基於IT技術製作影視節目的重要基礎設施。AAF主要用於媒體的編輯和製作，與MXF應用的側重點有所不同。在MXF開發完成之前，已存在多種音視頻文件格式，如：GXF、QuickTime、DPX和AVI等，但只有MXF最能夠滿足應用需求，特別是在開放性和元數據擴展性方面，因此MXF文件格式的應用越來越廣泛。

MXF文件通常被視為一種“容器”文件格式，也就是説MXF文件格式與內容數據的格式無關，這得益於MXF底層使用了KLV（鍵-長度-值）三元組編碼方式。MXF文件通常包含文件頭、文件體和文件尾等幾個部分。

MXF 是英文 Material Exchange Format（文件交換格式）的詞頭縮寫， 這個名字本身就道出了它的作用是為數據的發送者和接收者 建立不同數據格式轉換的通用標準。 它可在專業廣播電視環境下 轉換媒體文件， 本質上是一種外殼格式。 為什麼這樣説呢？象PC平台的AVI多媒體格式， 它是一種對音視頻 進行中等壓縮和打包， 介乎於壓縮和無壓縮之間的 文件格式。 但MXF超出了一般AVI的範疇。例如： MXF被設計可用於 包裝MPEG2數據流、 DV數據流、 YUV數據流、 PCM音頻文件 以及幾種格式的數據庫文件（同步或非同步模式）。 MXF可以同時處理打包多條軌道的 音視頻和數據庫文件， 它被設計為既支持流媒體傳輸 又支持文件的傳輸。所以它可以改善網絡環境 因缺乏標準的文件格式 而受阻礙的局面。 實際上， 在MXF出現之前， 有過類似的格式， 例如OMF（Open Media Frame） 開放媒體框架格式， 它就是一個包含多軌媒體信息的 文件格式， 但OMF更象是AVI是為了編輯而設計，缺少MXF的網絡流動性。

目前沒有任何一種文件外殼格式 可以滿足廣播製作的所有需求。 而MXF被設計為可以滿足絕大數當前 和未來的媒體交換的需求。我們期望看到媒體在 不同的載體上交換， 包括：音視頻服務器、 離線和近線存儲系統、 編輯工作站、 錄像設備 （帶有以太網文件傳出能力）、流媒文件格式等。 最重要的是MXF允許不同的公司 （應用程序） 間不需依賴特定的文件格式 就能交換資源。 當然，這只是一個美好的願望， 但是，著名的公司的行動 已經使我們看到了希望， 品尼高公司（Pinnacle） 最早在Liquid後期編輯系列產品中 就支持了這個格式，因為它需要用OMF在它的非編系統和 播出系統 （例如Palladium） 間建立無縫的橋樑， 愛維德（Avid）在最新的Xpress編輯系統中 也表明支持MXF （要知道， 它一直是OMF最強的支持者）， 而蘋果公司著名的非編軟件 Final Cut Pro最新推出的5.0版本中， 已經可以直接導入MXF了。

也許需要等一段時間， 就像物理學家牛頓提出的慣性定律： 除非受到外力， 物體不會改變他們的狀態。 現如今， MPEG、AVI、GXF、QuikeTime和DIF 廣泛應用於硬盤和磁帶存儲。 如果將所有的格式在短時間內 都轉換為MXF，那需要巨大的外界力量。 MXF將首先被新設備使用， 包括對音視頻設備 和非線性設備的升級 （例如PII攝像機）。 MXF也可能被做為存儲格式使用， 但需要與其他文件格式共存， 直到那些格式都轉化為MXF， 所以MXF的普及需要一定的時間。

不， 因為MXF是一個外殼格式 而不是壓縮格式， 所以並不能保證每一款MXF文件 都能被任何一種解碼器識別。例如，將D10格式的MPEG-2文件轉換為 MXF文件， 而接收端的設備只裝配了 DV25 格式的解碼器， 此時，MXF是不兼容的（就象我們家中的Media Player播放器 也經常不能觀看一些特殊編碼的 AVI文件一樣）。 要做到真正的兼容，發送端和接受端設備必須支持相同的 音視頻壓縮或無壓縮格式 以及數據格式。 MXF的操作規範定義了各種 MXF 的特性， 壓縮類型， 數據結構，例如： 一個規範允許支持 D10 MPEG-2 和多軌音頻格式， 另一種規範則支持DV格式 （SMTPE 314M）。當然，SMPTE將不斷增加新的 MXF 支持的格式以滿足行業的需求。 問題的重點是： MXF雖然不能保證100%的兼容，當從長遠講它正在向這方面努力。

IMX是索尼公司為一種帶寬的 磁帶格式起的名字， 這種磁帶被用於索尼公司那些支持MPEG D10格式 或D10數據流的產品 （SMPTE 365M和SMPTE 356M）， 它們以50M/秒的速率傳輸數據 （在有些產品上達到 30M或40M的速率）。例如：索尼MSW-2000系列就是支持MPEG D10格式的 IMX錄像機。 D10數據流是一種只包含一系列MPEG-2 I幀的格式，這些I幀具備相同的數據量， 這種格式非常適合錄像設備。 這種MPEG格式同樣也是SDTI-CP傳輸協議 （SMPTE 331M）中一種標準的壓縮格式。 IMX本身不是指文件格式或壓縮格式， 它僅僅是一個帶寬的類型， 這一點和MXF很相象。 所以，如果有一天推出MXF的錄像帶， 也沒有什麼新鮮。

KLV代表關鍵幀（key）， 長度（length） 和取值（value）。 它起源於最初的程式化概念。 KLV做為一種連續的、 關聯的包含分段信息的數據包 被使用多年了。

所以， KLV打包方式提供了一種 分割用户數據和確認用户數據類型 （key）的方式。 長度信息表明了 實際數據的字節長度。 SMPTE 336M定義了 KLV被應用的規範。 關鍵幀是SMPTE一個普遍的標準 （SMPTE 298M）。 所以， 關鍵幀定義了特定音頻的參數值類型。 MXF是不同類型的連續的 KLV序列的組合， 包括： 音頻、 視頻、 索引標誌、 文件頭和所有的索引數據。

不， MXF主要是一種交換格式， 雖然它確實做為 一種磁盤格式被使用， 但這個文件標準主要是 為了在流轉中兼容。 下面的事例表明為什麼以 MXF本格式儲存不具備優勢。 設想傳輸一個混合音頻 和視頻的MXF文件， 一台非線性編輯設備 為接受上面的MXF文件，必須確定MXF文件中的音視頻數據， 並將它們做為 分割的文件重新寫在硬盤中 （例如：分割為音頻的 WAV文件和 MPEG-2的MXF文件）。選擇數據指針時也需要從 MXF文件中將數據指針 移出到本地的數據庫中， 這樣反覆地重複多步操作， 將原來簡單的媒體格式讀取 複雜化了，所以基於這種原因， 純粹的硬盤上的 MXF文件不具有太大的使用價值。

但另一方面 MXF文件分區的實際字段大小 又使它在磁盤存儲中 具備一定的優勢。 在一些系統中需要4K的字段空間 （或其他數量）去讀寫文件， MXF不必把分區按4K分割， 所以一些版本的 MXF文件在儲存時 可以減少硬盤的讀寫次數。

這就是説， 當把大量的媒體文件和 數據結構按MXF存取時， MXF還是有優勢的， 所以它適合大量的網絡轉移。 實際工作中為確保兼容性， 需要將MXF做為文件 或數據流來交換， 並允許操作規範間的轉換。

是的。 數據流和文件傳輸 意味着同時支持在一個源頭 向一個或不同的終端發送信息。 它們有各自的應用領域， 並可以共存。 文件和數據流又不同的用途：

文件：

（1） 通過不同步式網絡發送 （例如以太網和局域網）

（2） 100%的兼容通訊協議，如FTP

（3） 同步數據傳輸， 包括低於或高於實時的速率

（4） 點到點或一點到多點的傳輸

數據流：

（1） 素材被做為數據流 通過線纜以特定的速率 發送給一個或多個終端工作站， 通常是通過專門的、 不兼容的協議 （如UDP）來實現。 雖然數據流可以通過 兼容性很好的TCP方式傳輸， 但對許多處理數據流的 應用程序來説， 那是不實用的。

（2） 數據流通常帶着 時鐘基準信號被髮送， 以便可以立即在 終端工作站上被解碼。

（3） 任何在通道內的錯誤 可以使用附加的ECC 或其他類型的校錯方式被校正。

＞ 對大多數應用程序來説， 文件傳輸有它的優勢， 因為它可保證傳輸100%的兼容。

＞ 流傳輸方式則在 需要實時傳輸的領域 被廣泛使用。

AAF and MXF

The capabilities of AAF come at the price of complexity within the AAF SDK reference implementation.

Whilst this may be of little consequence within a software application running on a PC-class device, it can

have a significant impact within embedded systems such as VTRs or cameras where processing and memory

resources may be scarce. The chosen solution to this is a second related format – known as the Material

eXchange Format (MXF) [3] – which is being developed jointly by the Professional MPEG Forum [4] and the

AAF Association [1].

MXF reuses a subset of the AAF object model. The parts dealing with material (rushes or rendered finishedprogrammes) are carried over into MXF while the parts dealing with compositions, effects and the in-file dictionary

are removed.

MXF is streamable. By using SMPTE 336M KLV coding, instead of Structured Storage, and applying other

rules on placement of data within the stream, MXF provides capabilities such as playing while recording, and

operation with isolated sections of streams. By replacing Structured Storage however, the AAF feature of inplace

editing of existing files is lost.