Sustainability of Digital Formats
 Planning for Library of Congress Collections

Object-based file format that wraps video, audio, and other bitstreams ("essences"), optimized for content interchange or archiving by creators and/or distributors, and intended for implementation in devices ranging from cameras and video 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 videotape'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 standard specifies a number of operational patterns ("OPs") intended to accommodate different levels of complexity in a file, e.g., one essence or multiple essences, "ganged" segments or a set of segments from which sub-segment are to be played, and so on. Application Specifications are specific profiles that are constrained to a certain OP, a particular encoding, metadata structure, etc. and other elements; see for example the MXF_AS-PBS under development by the Public Broadcasting System.

There is ever-increasing interest and adoption of MXF. Advocates have included Pro-MPEG Forum (Web site not available in August 2007 and in March 2008), the Advanced Media Workflow Association (AMWA, the former AAF Association), 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 commercial production systems, notably the SONY MSW-2000 series of IMX video recorders. Panasonic P2 digital video cameras can output MXF OP-Atom files with DVC Pro encodings (see DV-DIF). Avid editing equipment supports certain variants of MXF. MXF is also part of the ensemble of specifications associated with the Digital Cinema Initiative; see DCDM, DCP, and MXF_DCI.

In 2006-07, the Public Broadcasting System was standardizing an Application Specification (MXF_AS-PBS), for use in the non-real-time distribution of programs to member stations, and planning to develop another Application Specification for archiving. The SAMMA device used to reformat videotapes can output MXF_SAMMA.

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 (no longer available on the Web in August 2007) stated 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. There appear to be other efforts to connect AAF and XML; in 2006, the AAF Association referred to AAF-X, an XML-schema-based representation of AAF metadata. See also the related document titled XML Based Dictionaries for MXF/AAFApplications.

See also European Broadcasting Union (EBU) Recommendation R121-2007, Material Exchange Format - Basic User Metadata Implementation.

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)

A background paper from Linux Media Arts (no longer available online as of February 2009) stated 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."

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."

Regarding timecode, one implementation has been articulated by the European Broadcasting Union (EBU) as Recommendation R122-2007, Material Exchange Format - Timecode Implementation. This recommendation defines an encoding of source timecode into MXF files. For MXF encoders, the placement of source timecode in the MXF header metadata for all currently defined operational patterns is defined. The placement of source timecode in frame-wrapped and, for EBU recommended essence formats, in clip-wrapped essence containers is also defined.

[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.]

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 (not available in August 2007) reported 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.