1.? 新興的多媒體格式
MXF格式已經被推出幾年了, 從當初一個陌生的不為人們 重視的格式 逐漸獲得了業內人士的認知和認可, 現如今正被廣泛應用于廣播電視 與后期制作領域, 且有不斷擴大之勢, 松下公司推出的基于PII卡的 無磁帶式標清攝像機, 它所采用的媒體格式, 正是MXF。
什么是MXF? MXF如何為我們提供便利? MXF與IMX格式的關系? 所有的多媒體文件格式 都會向MXF靠攏嗎? 所有的MXF文件都是兼容的嗎? 我們需要一步步來解釋這些問題。問題1:什么是 MXF?
MXF 是英文 Material Exchange Format(文件交換格式)的詞頭縮寫, 這個名字本身就道出了它的作用 是為數據的發送者和接收者 建立不同數據格式轉換的通用標準。 它可在專業廣播電視環境下 轉換媒體文件, 本質上是一種外殼格式。 為什么這樣說呢? 象PC平臺的AVI多媒體格式, 它是一種對音視頻 進行中等壓縮和打包, 介乎于壓縮和無壓縮之間的 文件格式。 但MXF超出了一般AVI的范疇。 例如: MXF被設計可用于 包裝MPEG2數據流、 DV數據流、 YUV數據流、 PCM音頻文件 以及幾種格式的數據庫文件 (同步或非同步模式)。 MXF可以同時處理打包多條軌道的 音視頻和數據庫文件, 它被設計為既支持流媒體傳輸 又支持文件的傳輸。 所以它可以改善網絡環境 因缺乏標準的文件格式 而受阻礙的局面。 實際上, 在MXF出現之前, 有過類似的格式, 例如OMF(Open Media Frame) 開放媒體框架格式, 它就是一個包含多軌媒體信息的 文件格式, 但OMF更象是AVI是為了編輯而設計, 缺少MXF的網絡流動性。
問題2: MXF 對我們有什么幫助?
目前沒有任何一種文件外殼格式 可以滿足廣播制作的所有需求。 而MXF被設計為可以滿足絕大數當前 和未來的媒體交換的需求。 我們期望看到媒體在 不同的載體上交換, 包括:音視頻服務器、 離線和近線存儲系統、 編輯工作站、 錄像設備 (帶有以太網文件傳出能力)、 流媒文件格式等。 最重要的是MXF允許不同的公司 (應用程序) 間不需依賴特定的文件格式 就能交換資源。 當然,這只是一個美好的愿望, 但是, 著名的公司的行動 已經使我們看到了希望, 品尼高公司(Pinnacle) 最早在Liquid后期編輯系列產品中 就支持了這個格式, 因為它需要用OMF在它的非編系統和 播出系統 (例如Palladium) 間建立無縫的橋梁, 愛維德(Avid) 在最新的Xpress編輯系統中 也表明支持MXF (要知道, 它一直是OMF最強的支持者), 而蘋果公司著名的非編軟件 Final Cut Pro最新推出的5.0版本中, 已經可以直接導入MXF了。
問題3: MXF 會取代現在已廣泛使用的 文件格式嗎?
也許需要等一段時間, 就象物理學家牛頓提出的慣性定律: 除非受到外力, 物體不會改變他們的狀態。 現如今, MPEG、AVI、GXF、QuikeTime和DIF 廣泛應用于硬盤和磁帶存儲。 如果將所有的格式在短時間內 都轉換為MXF, 那需要巨大的外界力量。 MXF將首先被新設備使用, 包括對音視頻設備 和非線性設備的升級 (例如PII攝像機)。 MXF也可能被做為存儲格式使用, 但需要與其他文件格式共存, 直到那些格式都轉化為MXF, 所以MXF的普及需要一定的時間。
問題4: 所有的MXF文件都相互兼容嗎?
不, 因為MXF是一個外殼格式 而不是壓縮格式, 所以并不能保證每一款MXF文件 都能被任何一種解碼器識別。 例如,將D10格式的MPEG-2文件轉換為 MXF文件, 而接收端的設備只裝配了 DV25 格式的解碼器, 此時,MXF是不兼容的 (就象我們家中的Media Player播放器 也經常不能觀看一些特殊編碼的 AVI文件一樣)。 要做到真正的兼容, 發送端和接受端設備必須支持相同的 音視頻壓縮或無壓縮格式 以及數據格式。 MXF的操作規范定義了各種 MXF 的特性, 壓縮類型, 數據結構, 例如: 一個規范允許支持 D10 MPEG-2 和多軌音頻格式, 另一種規范則支持DV格式 (SMTPE 314M)。 當然,SMPTE將不斷增加新的 MXF 支持的格式以滿足行業的需求。 問題的重點是: MXF雖然不能保證100%的兼容, 當從長遠講它正在向這方面努力。
問題5: 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的錄像帶, 也沒有什么新鮮。
問題6: 在MXF中KLV是如何 做為一個尺度的?
KLV代表關鍵幀(key), 長度(length) 和取值(value)。 它起源于最初的程式化概念。 KLV做為一種連續的、 關聯的包含分段信息的數據包 被使用多年了。
所以, KLV打包方式提供了一種 分割用戶數據和確認用戶數據類型 (key)的方式。 長度信息表明了 實際數據的字節長度。 SMPTE 336M定義了 KLV被應用的規范。 關鍵幀是SMPTE一個普遍的標準 (SMPTE 298M)。 所以, 關鍵幀定義了 特定音頻的參數值類型。 MXF是不同類型的連續的 KLV序列的組合, 包括: 音頻、 視頻、 索引標志、 文件頭和所有的索引數據。
問題7: MXF的主要應用方向 是文件存儲嗎?
不, MXF主要是一種交換格式, 雖然它確實做為 一種磁盤格式被使用, 但這個文件標準主要是 為了在流轉中兼容。 下面的事例表明為什么以 MXF本格式儲存不具備優勢。 設想傳輸一個混合音頻 和視頻的MXF文件, 一臺非線性編輯設備 為接受上面的MXF文件, 必須確定MXF文件中的音視頻數據, 并將它們做為 分割的文件重新寫在硬盤中 (例如:分割為音頻的 WAV文件和 MPEG-2的MXF文件)。 選擇數據指針時也需要從 MXF文件中將數據指針 移出到本地的數據庫中, 這樣反復地重復多步操作, 將原來簡單的媒體格式讀取 復雜化了, 所以基于這種原因, 純粹的硬盤上的 MXF文件不具有太大的使用價值。
但另一方面 MXF文件分區的實際字段大小 又使它在磁盤存儲中 具備一定的優勢。 在一些系統中需要4K的字段空間 (或其他數量)去讀寫文件, MXF不必把分區按4K分割, 所以一些版本的 MXF文件在儲存時 可以減少硬盤的讀寫次數。
這就是說, 當把大量的媒體文件和 數據結構按MXF存取時, MXF還是有優勢的, 所以它適合大量的網絡轉移。 實際工作中為確保兼容性, 需要將MXF做為文件 或數據流來交換, 并允許操作規范間的轉換。
問題8: MXF同時支持文件 和數據流傳輸嗎?
是的。 數據流和文件傳輸 意味著同時支持在一個源頭 向一個或不同的終端發送信息。 它們有各自的應用領域, 并可以共存。 文件和數據流又不同的用途:
文件:
(1) 通過不同步式網絡發送 (例如以太網和局域網)
(2) 100%的兼容通訊協議,如FTP
(3) 同步數據傳輸, 包括低于或高于實時的速率
(4) 點到點或一點到多點的傳輸
數據流:
(1) 素材被做為數據流 通過線纜以特定的速率 發送給一個或多個終端工作站, 通常是通過專門的、 不兼容的協議 (如UDP)來實現。 雖然數據流可以通過 兼容性很好的TCP方式傳輸, 但對許多處理數據流的 應用程序來說, 那是不實用的。
(2) 數據流通常帶著 時鐘基準信號被發送, 以便可以立即在 終端工作站上被解碼。
(3) 任何在通道內的錯誤 可以使用附加的ECC 或其他類型的校錯方式被校正。
> 對大多數應用程序來說, 文件傳輸有它的優勢, 因為它可保證傳輸100%的兼容。
> 流傳輸方式則在 需要實時傳輸的領域 被廣泛使用。
問題9: MXF與AAF的關系?
AAF是高級編著格式, 它是被AAF協會的會員設計制定的。 AAF文件是通過MXF的規范被創建的, 可以被支持AAF的程序打開。 此外, MXF文件可嵌入到AAF中, AAF擴展了MXF的用途, 但它沒有實質的進步。 AAF主要用于承載那些 復雜的媒體片斷的合成信息。
問題10: 我們研究MXF的意圖是什么?
我們支持MXF, 是為了獲得它的便利:
(1) 使用FTP或其他方式 在前端設備上導入導出MXF文件。
(2) 通過轉碼工作站 將現有的媒體文件加一個外殼, 使它獲得最大的兼容性, 通過局域網或萬維網 以不同的格式接受他們, 包括MXF本身。 大多數轉換工作比實時還快, 如果轉換過程中 沒有重新編碼的過程, 文件質量就不會有任何損失。
(3) 向近線或離線存儲設備存取文件
當然, 會不斷有更多的廠商將 MXF的特性加入到他們的產品中, 但同時也應看到, MXF并非一個包治百病得萬能格式, 用其所能, 才能體現其真正價值。
2. ? mxf? 簡介
MXF是英文Material eXchange Format(素材交換格式)的縮語。MXF是SMPTE(美國電影與電視工程師學會)組織定義的一種專業音視頻媒體文件格式。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定義:
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是高級編著格式, 它是被AAF協會的會員設計制定的。 AAF文件是通過MXF的規范被創建的, 可以被支持AAF的程序打開。 此外, MXF文件可嵌入到AAF中, AAF擴展了MXF的用途, 但它沒有實質的進步。 AAF主要用于承載那些 復雜的媒體片斷的合成信息。
3.?
The MXF standards? 標準 文檔
Base documents
-
- SMPTE 377M: The MXF File Format Specification (the overall master document)
- SMPTE EG41: MXF Engineering Guide (A guide explaining how to use MXF)
- SMPTE EG42: MXF Descriptive Metadata (A guide explaining how to use descriptive metadata in MXF)
[edit] Operational patterns
-
- SMPTE 390M: OP-Atom (a very simple and highly constrained layout for simple MXF files)
- SMPTE 378M: OP-1a (the layout options for a minimal simple MXF file)
- SMPTE 391M: OP-1b
- SMPTE 392M: OP-2a
- SMPTE 393M: OP-2b
- SMPTE 407M: OP-3a, OP-3b
- SMPTE 408M: OP-1c, OP-2c, OP-3c
[edit] Generic containers
-
- SMPTE 379M: Generic Container (the way that essence is stored in MXF files)
- SMPTE 381M: GC-MPEG (how to store MPEG essence data in MXF using the Generic Container)
- SMPTE 383M: GC-DV (how to store DV essence data in MXF using the Generic Container)
- SMPTE 385M: GC-CP (how to store SDTI-CP essence data in MXF using the Generic Container)
- SMPTE 386M: GC-D10 (how to store SMPTE D10 essence data in MXF using the Generic Container)
- SMPTE 387M: GC-D11 (how to store SMPTE D11 essence data in MXF using the Generic Container)
- SMPTE 382M: GC-AESBWF (how to store AES/EBU and Broadcast Wave audio essence data in MXF using the Generic Container)
- SMPTE 384M: GC-UP (how to store Uncompressed Picture essence data in MXF using the Generic Container)
- SMPTE 388M: GC-AA (how to store A-law coded audio essence data in MXF using the Generic Container)
- SMPTE 389M: Generic Container Reverse Play System Element
- SMPTE 394M: System Item Scheme-1 for Generic Container
- SMPTE 405M: Elements and Individual Data Items for the GC SI Scheme 1
[edit] Metadata, dictionaries and registries
-
- SMPTE 380M: DMS1 (a standard set of descriptive metadata to use with MXF files)
- SMPTE 436M: MXF Mappings for VBI Lines and Ancillary Data Packets
- SMPTE RP210: SMPTE Metadata Dictionary (the latest version is available here: http://www.smpte-ra.org/mdd/index.html )
- SMPTE RP224: Registry of SMPTE Universal Labels
文檔請到我的資源中下載。