詳細介紹
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被設計為可以滿足絕大數當前 和未來的媒體交換的需求。我們期望看到媒體在 不同的載體上交換， 包括：音視頻伺服器、 離線和近線存儲系統、 編輯工作站、 錄像設備 （帶有乙太網檔案傳出能力）、流媒檔案格式等。 最重要的是MXF允許不同的公司 （應用程式） 間不需依賴特定的檔案格式 就能交換資源。 當然，這只是一個美好的願望， 但是，著名的公司的行動 已經使我們看到了希望， 品尼高公司（Pinnacle） 最早在Liquid後期編輯系列產品中 就支持了這個格式，因為它需要用OMF在它的非編系統和 播出系統 （例如Palladium） 間建立無縫的橋樑， 愛維德（Avid）在最新的Xpress編輯系統中 也表明支持MXF （要知道， 它一直是OMF最強的支持者）， 而蘋果公司著名的非編軟體 Final Cut Pro最新推出的5.0版本中， 已經可以直接導入MXF了。
MXF 會取代現在已廣泛使用的 檔案格式嗎？
也許需要等一段時間， 就象物理學家牛頓提出的慣性定律： 除非受到外力， 物體不會改變他們的狀態。 現如今， MPEG、AVI、GXF、QuikeTime和DIF 廣泛套用於硬碟和磁帶存儲。 如果將所有的格式在短時間內 都轉換為MXF，那需要巨大的外界力量。 MXF將首先被新設備使用， 包括對音視頻設備 和非線性設備的升級 （例如PII攝像機）。 MXF也可能被做為存儲格式使用， 但需要與其他檔案格式共存， 直到那些格式都轉化為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%的兼容，當從長遠講它正在向這方面努力。
MXF與IMX的關係
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的錄像帶， 也沒有什麼新鮮。
在MXF中KLV是如何 做為一個尺度的？
KLV代表關鍵幀（key）， 長度（length） 和取值（value）。 它起源於最初的程式化概念。 KLV做為一種連續的、 關聯的包含分段信息的數據包 被使用多年了。
所以， KLV打包方式提供了一種 分割用戶數據和確認用戶數據類型 （key）的方式。 長度信息表明了 實際數據的位元組長度。 SMPTE 336M定義了 KLV被套用的規範。 關鍵幀是SMPTE一個普遍的標準 （SMPTE 298M）。 所以， 關鍵幀定義了特定音頻的參數值類型。 MXF是不同類型的連續的 KLV序列的組合， 包括： 音頻、 視頻、 索引標誌、 檔案頭和所有的索引數據。
MXF的主要套用方向 是檔案存儲嗎？
不， MXF主要是一種交換格式， 雖然它確實做為 一種磁碟格式被使用， 但這個檔案標準主要是 為了在流轉中兼容。 下面的事例表明為什麼以 MXF本格式儲存不具備優勢。 構想傳輸一個混合音頻 和視頻的MXF檔案， 一台非線性編輯設備 為接受上面的MXF檔案，必須確定MXF檔案中的音視頻數據， 並將它們做為 分割的檔案重新寫在硬碟中 （例如：分割為音頻的 WAV檔案和 MPEG-2的MXF檔案）。選擇數據指針時也需要從 MXF檔案中將數據指針 移出到本地的資料庫中， 這樣反覆地重複多步操作， 將原來簡單的媒體格式讀取 複雜化了，所以基於這種原因， 純粹的硬碟上的 MXF檔案不具有太大的使用價值。
但另一方面 MXF檔案分區的實際欄位大小 又使它在磁碟存儲中 具備一定的優勢。 在一些系統中需要4K的欄位空間 （或其他數量）去讀寫檔案， MXF不必把分區按4K分割， 所以一些版本的 MXF檔案在儲存時 可以減少硬碟的讀寫次數。
這就是說， 當把大量的媒體檔案和 數據結構按MXF存取時， MXF還是有優勢的， 所以它適合大量的網路轉移。 實際工作中為確保兼容性， 需要將MXF做為檔案 或數據流來交換， 並允許操作規範間的轉換。
MXF同時支持檔案 和數據流傳輸嗎？
是的。 數據流和檔案傳輸 意味著同時支持在一個源頭 向一個或不同的終端傳送信息。 它們有各自的套用領域， 並可以共存。 檔案和數據流又不同的用途：
檔案：
（1） 通過不同步式網路傳送 （例如乙太網和區域網路）
（2） 100%的兼容通訊協定，如FTP
（3） 同步數據傳輸， 包括低於或高於實時的速率
（4） 點到點或一點到多點的傳輸
數據流：
（1） 素材被做為數據流 通過線纜以特定的速率 傳送給一個或多個終端工作站， 通常是通過專門的、 不兼容的協定 （如UDP）來實現。 雖然數據流可以通過 兼容性很好的TCP方式傳輸， 但對許多處理數據流的 應用程式來說， 那是不實用的。
（2） 數據流通常帶著 時鐘基準信號被傳送， 以便可以立即在 終端工作站上被解碼。
（3） 任何在通道內的錯誤 可以使用附加的ECC 或其他類型的校錯方式被校正。
> 對大多數應用程式來說， 檔案傳輸有它的優勢， 因為它可保證傳輸100%的兼容。
> 流傳輸方式則在 需要實時傳輸的領域 被廣泛使用。
MXF與AAF的關係？
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) – which is being developed jointly by the Professional MPEG Forum and the
AAF Association .
MXF reuses a subset of the AAF object model. The parts dealing with material (rushes or rendered finished
programmes) 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.
