Sustainability of Digital Formats
Planning for Library of Congress Collections
Sustainability of Digital Formats
|
|
|
|
| Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact | |
| Full name | Material Exchange Format (MXF) |
| Description | Object-based file format that wraps video, audio, and other bitstreams
("essences"), optimized for the interchange or archiving by the content
creation industries, and intended for implementation in devices ranging
from cameras and videotape recorders to computer systems. In effect, the
format bundles the essences and what amounts to an "edit decision list"
(data used by audio-visual content editing systems) in an unambiguous
way that is essence-agnostic and metadata-aware. Although the specification allows for complex, multipart objects, most commentators say "MXF should be seen as the 'digital equivalent of videotape,'" an allusion to tape's simple, linear structure. See Notes for a comparison to MXF's supertype, AAF_1_1, which most commentators describe as "allowing for the expression of complex relationships between parts" and "wrapping all elements of a project for continued production or archiving." Essences are wrapped in containers, implementations of the MXF_GC (MXF Format Generic Container) for specific encodings. Essences are generally internal (within the MXF file); they may be external (and identified by reference), although this is discouraged. [Must external essences be in the same types of containers? Comments welcome.] Tracks represent the passage of time. Timeline tracks (aka standard tracks) describe segments that butt against one another to form continuous sequences, event tracks may have overlapping events that refer to the point at which descriptive metadata is valid, while static tracks have no timeline--all of their descriptive metadata applies the entire duration of the linked essence track. Tracks are synchronized by putting them in a package (container for tracks). The documentation specifies a number of operational patterns, conformance points for decoders that may be compared to profiles in the MPEG environment. Profiles for specific uses may be documented as Application Specifications, e.g., the AS-PBS developed in 2005 by the Public Broadcasting System for non-real-time distribution of programs to member stations. |
| Production phase | Typically a middle-state format for material exchange or archiving; also serves as a final state format for use in a delivery context, e.g., broadcasting. |
| Relationship to other formats | |
| Subtype of | AAF_1_1, Advanced Authoring Format (AAF), Version 1.1 |
| Has subtype | MXF_UNC, MXF with Uncompressed Images in Generic Container |
| Has subtype | MXF_MPEG-2, MXF with MPEG-2 in Generic Container |
| Has subtype | MXF_DV-DIF, MXF with DV-DIF Packets in Generic Container |
| Has subtype | MXF_SDTI-CP, MXF with SDTI-CP in Generic Container |
| Has subtype | MXF_JP2, MXF with JPEG 2000 in Generic Container |
| Has subtype | MXF_AES3, MXF with AES3 Audio in Generic Container |
| Has subtype | MXF with several other encodings in the Generic Container, not documented at this time |
| LC experience or existing holdings | None |
| LC preference | As of early 2006, plans for the Library of Congress National Audio-Visual Conservation Center at Culpeper, Virginia, call for reformatted video to be encoded as lossless JPEG 2000 frames wrapped in MXF, i.e., MXF_JP2. As reformatting practices are tested and as born-digital acquisitions come into play, the Library will refine its preferences regarding types of encoding (see subtypes above) and the operational patterns or application specifications that constrain MXF instances. |
| Disclosure | Open standard. Developed by the Society of Motion Picture and Television Engineers (SMPTE), a member of the American National Standards Institute (ANSI). |
| Documentation | The central specification is SMPTE 377M-2004, Material Exchange Format (MXF) -- File Format Specification (Standard); related key documents include the engineering guidelines SMPTE EG 41-2004, Material Exchange Format (MXF) -- Engineering Guideline and SMPTE EG 42-2004, Material Exchange Format (MXF) -- MXF Descriptive Metadata, and a number of subsidiary specifications. For a full list of citations, see Format specifications below. |
| Adoption | There is ever-increasing interest and adoption of MXF. Advocates include the Pro-MPEG Forum and others in the industry, who also lobby in favor of wider adoption of MXF's supertype, AAF_1_1. MXF is used by several production systems, notably the SONY MSW-2000 series of IMX video recorders, see MXF_SDTI-CP. In 2006, the Public Broadcasting System established an Application Specification for MXF ("AS-PBS"), for use in the non-real-time distribution of programs to member stations. |
| Licensing and patent claims | None. |
| Transparency | Wrapper is transparent; overall transparency depends upon the essence encoding. All video codecs depend upon algorithms and tools to read and will require sophistication to build tools. |
| Self-documentation | Extensive metadata is required by or may optionally be placed in MXF files. System or structural metadata is about the structure of the file, e.g., the relationship of parts, whether the essence is stored as little or big endian, index tables that provide information on the essence (display size, compression algorithm, the time line of a media clip, etc.), size of a sector, where a new partition starts, etc. User or descriptive metadata provides details on production, such as the title and responsible organization, location of the shot or shots, participants, and other annotating information. A "framework" of descriptive metadata schemes is defined in SMPTE 380M, Material Exchange Format (MXF) — Descriptive Metadata Scheme-1 (Standard, Dynamic), commonly called DMS-1 and sometimes referred to as a "dialect" for descriptive metadata. SMPTE committee leader Mike Cox reports that DMS-1 is "intended for archive use as an interchange layer between archives" (private communication). A SONY technical paper states that "MXF follows the AAF concept by distinguishing between `material', i.e. metadata from the production stage and `file' data, i.e. metadata on the final product. Within these material and file packages, all data are stored in `tracks'. The system metadata are kept in tracks of the timeline picture and sound tracks, whereas the user metadata are retained in shot, scene or production tracks. Not all of the metadata, however, need to be included. Most of them are optional, and producers can choose to create `simple' MXF files first, and add additional information later." MXF metadata is encoded using KLV (Key-Length-Value), as specified by SMPTE 336M-2001, and employs other data elements also specified by SMPTE, e.g., SMPTE Universal Labels (ANSI/SMPTE 298M-1997) and the SMPTE Metadata Dictionary (RP 210). Applications may be developed to input and output metadata from and to XML; SMPTE EG 42 includes a sample XML schema as Annex C. In addition, there is an effort under way to define AAF-X, an XML-schema-based representation of AAF metadata; the AAF Association documents on this topic are restricted to participants (as of April 2006); related documents may be found at the International Broadcasters Convention (IBC) Web site. |
| External dependencies | None |
| Technical protection considerations | In a passage concerning D-Cinema (digital cinema for theatrical distribution), SMPTE engineering guideline EG 41-2004 states that protection "can be achieved with a metadata plug-in to describe the encryption/protection scheme and an essence container type to contain the encrypted/protected essence(s)." (p. 39) |
| Video elements | |
| Normal rendering for video | Depending upon encoding and essence structure, MXF files may or may not be designed to play in the customary sense. Most applications in which MXF files may be played ("streamed" in a broadcaster's sense) will be professional; this is not a format intended for desktop PC applications. |
| Clarity (support for high image resolution) | Potentially excellent; depends upon encoding; see the descriptions of the various encodings listed as subtypes above. The genesis of the format is related to the use of file-based encapsulations of broadcast encodings like MPEG-2_422 (promoted by the Pro-MPEG Forum) and DV-DIF video. |
| Functionality beyond normal video rendering | Not investigated at this time. |
| Sound elements | |
| Normal rendering for sound | MXF files are not intended to play in the customary sense. Applications in which MXF files appear will be for professional, multimedia editorial work. |
| Fidelity (support for high audio resolution) | Potentially excellent; depends upon encoding. The specification set includes a mapping of WAVE_LCPM_BWF (a "storage" format; the same encoding is also referred to as the "interface format" AES3) into the MXF Generic Container; see the subtype MXF_AES3. |
| Support for multiple sound channels | There appears to be no limit to the number of tracks; thus multiple sound tracks may be included. |
| Functionality beyond normal sound rendering | Supports various features not documented here. |
| Tag type | Value | Note |
| Filename Extension | mxf | From an IETF Media Type Registration draft (March 2006) |
| Internet Media Type | application/mxf | From an IETF Media Type Registration draft (March 2006) |
| Magic numbers | none found | Comments welcome |
| Header partition pack key | Hex: 06 0E 2B 34 02 05 01 01 0D 01 02 | "MXF files start with an optional run-in followed by the SMPTE header partition pack key. The run-in is less than 64k bytes and the condition for finding the start of the file is to identify the first 11 bytes of the partition pack key . . . scan the initial 64 k bytes for these 11 bytes" to identify an MXF file. (From SMPTE EG 41, p. 45) The 11 bytes listed are from SMPTE 377M, p.20. |
| General | MXF and AAF_1_1 (Advanced Authoring Format, version 1.1) are presented here in a "subtype/supertype" relationship, but comments from specialists are welcome. The two formats share a common data model. They use identical approaches to describe and organize clips of essence into tracks (AAF term is slots) which are in turn collected into different packages (AAF term is Mobs or Metadata objects) to be sequenced. The way in which data is physically written onto a disk, tape or other storage medium is different; AAF uses Microsoft's Structured Storage specification while MXF wraps essences in the Generic Container, which is system-independent. The underlying MXF and AAF data model is the same to ensure interoperability, although SMPTE EG42-2004 (cited below) states that "MXF has extended the AAF object model to introduce descriptive metadata tracks that can be used to describe the content of the essence container," (p. 5) and "Note that not all AAF implementations will support the encoding and decoding of MXF descriptive metadata." (p. 9) Linux Media Arts states that "MXF is an object subset of AAF . . . . MXF was designed for less complex (less vertically rich) metadata applications, such as news editing and video streaming from servers. Because of its flatter metadata structure, it is better suited to be used as a metadata wrapper within a video signal or a TCP/IP stream. . . . For post-production, one of the most important points about MXF video and metadata is that MXF will seamlessly interoperate with AAF-based post-production environments. The less extensive MXF metadata can be accepted in full by AAF-based workstations, and AAF metadata can be flattened out to become the sleeker MXF metadata. Thanks to the zero-divergence policy of the AAF and MXF proponents, the formats are fully interoperable with one another. All MXF metadata is understood by AAF, but if some AAF-specific metadata is not defined within the MXF standard, the non-MXF compliant metadata will be filtered and flattened out when being encoded as MXF." An AVID corporation press release dated 2003 announced that the next version of the open source AAF Software Developers Toolkit (SDK) would permit users to read and write Material Exchange Format (MXF) files. MXF's use of the generic container appears to provide one more layer of independence from underlying software than is provided by AAF's use of Microsoft's Component Object Model (COM) interface and Structured Storage for the persistent object. When responding to a question about this, one expert commented, "It may also be easier to maintain source code for MXF over the long term." The AAF Association reports that they are beginning the development of an archiving protocol during 2005. In the words of AAF Executive Director Brad Gilmer, a protocol says, "use the AAF specifications 'this' way for 'this' application." [Placeholder note, pending completion of MXF_JP2, MXF with JPEG 2000 in Generic Container: Comments from specialists indicate that image data may take the form of codestreams (sometimes called .j2c files) or fully realized JPEG 2000 (Part 1) files (.j2p). In the former instance, additional metadata pertaining to things like color space may have to be added to the file; comments welcome.] |
| History | MXF and AAF_1_1 seem to have developed during the same period, i.e., approximately 1998-2004, with many of the same players participating. The MXF page at the Pro-MPEG Forum Web site reports this about MXF: "The Professional-MPEG Forum formed in 1998 to support open standards for emerging new professional television applications. For new workflows and improved material sharing, both the SMPTE and the EBU in Europe recognised the need for an open and standardized file format. Although there were several file formats in use, until recently none offered the advanced functionality required by sophisticated material management systems. The Professional-MPEG Forum accepted the challenge and assembled a team of specialists not only from the manufacturing industry but also consisting of end-users. The work started in 1999, first by establishing the user requirements and then setting about implementation in the Material eXchange Format (MXF). After 5 years of Pro-MPEG Forum celebrated the successful standardization through SMPTE of the MXF at NAB2004." Both MXF and AAF continue to be the subjects of standards-development work through SMPTE. KLV metadata encoding (see Self-documentation, above) is employed in a number of video streams used by broadcasters and specified by SMPTE, which has strong connections to the broadcast industry. In part, MXF and AAF may be seen as the outcome of that industry's quest for a wrapper for their typical content formats. |
URLs
Print
Listed at the SMPTE store, as of April 4, 2006. (http://www.smpte.org/smpte_store/standards/)
• SMPTE 377M-2004. Television Material Exchange Format (MXF) File Format Specification
• SMPTE 378M-2004. Television Material Exchange Format (MXF) Operational Pattern 1a (Single Item, Single Package)
• SMPTE 379M-2004. Television Material Exchange Format (MXF) MXF Generic Container
• SMPTE 380M-2004. Television Material Exchange Format (MXF) Descriptive Metadata Scheme-1 (Standard, Dynamic)
• SMPTE 381M-2005. Television Material Exchange Format (MXF) Mapping MPEG Streams into the MXF Generic Container (Dynamic)
• SMPTE 382M. Television Material Exchange Format (MXF) Mapping AES3 Streams and Broadcast Wave Audio to the MXF Generic Container
• SMPTE 383M-2004. Television Material Exchange Format (MXF) Mapping DV-DIF Data to the MXF Generic Container
• SMPTE 384M. Television Material Exchange Format (MXF) Mapping of Uncompressed Pictures into the MXF Generic Container (Dynamic)
• SMPTE 385M-2004. Television Material Exchange Format (MXF) Mapping SDTI-CP Essence and Metadata into the MXF Generic Container
• SMPTE 386M-2004. Television Material Exchange Format (MXF) Mapping Type D-10 Essence Data to the MXF Generic Container
• SMPTE 387M-2004. Television Material Exchange Format (MXF) Mapping Type D-11 Essence Data to the MXF Generic Container
• SMPTE 388M-2004. Television Material Exchange Format (MXF) Mapping A-law Coded Audio into the MXF Generic Container
• SMPTE 389M-2005. Television Material Exchange Format (MXF) MXF Generic Container Reverse Play System Element
• SMPTE 390M-2004. Television Material Exchange Format (MXF) Specialized Operational Pattern "Atom" (Simplified Representation of a Single Item)
• SMPTE 391M-2004. Television Material Exchange Format (MXF) Operational Pattern 1b (Single Item, Ganged Packages)
• SMPTE 392M-2004. Television Material Exchange Format (MXF) Operational Pattern 2a (Play-List Items, Single Package)
• SMPTE 393M-2004. Television Material Exchange Format (MXF) Operational Pattern 2b (Play-List Items, Ganged Packages)
• SMPTE 394M. Television Material Exchange Format (MXF) System Scheme 1 for the MXF Generic Container
• SMPTE 405M. Television Material Exchange Format (MXF) Elements and Individual Data Items for the MXF Generic Container System Scheme 1
• SMPTE EG 41-2004. Material Exchange Format (MXF) Engineering Guideline
• SMPTE EG 42-2004. Material Exchange Format (MXF) MXF Descriptive Metadata
• SMPTE RDD 3-2005. e-VTR MXF Interoperability Specification
URLs
• Pro-MPEG Forum, advocates for MXF and AAF (http://www.pro-mpeg.org/)
• IETF Media Type Registration draft, March 2006 (http://www.ietf.org/internet-drafts/draft-edwards-mime-mxf-03.txt)
• SONY MSW-2000 series of IMX video recorders. (http://bssc.sel.sony.com/Professional/docs/brochures/msw2000%20v2176.pdf)
• SONY technical paper (http://www.sony-bplabs.com/research/frm_mxf.htm)
• Linux Media Arts background paper (http://www.lmahd.com/mxf.html)
• MOG Solutions, vendor for MXF tools (http://www.mog-solutions.com/)
• About XML for AAF and MXF at the International Broadcasters Convention (IBC) Web site (http://www.broadcastpapers.com/asset/IBCSonyXMLDictionary01.htm).
• MXF--the Material Exchange Format by Bruce Devlin of Snell & Wilcox for the EBU Technical Review, July 2002. (http://www.ebu.ch/en/technical/trev/trev_291-devlin.pdf)
Print
• Motion Imaging, July/August 2004. This double issue of the monthly journal of the Society of Motion Picture, and Television Engineers (SMPTE) is devoted to the Advanced Authoring Format (AAF) and the Material Exchange Format (MXF).
|
|