In the last course on DCP creation that we taught in 709 I could see that there were some doubts regarding the types of MXF that exist. The doubt arose when I explained that the image and sound of digital cinema copies (DCP) are encapsulated in MXF and these are different, for example, from those recorded in XDCAM and P2 or those used by editing systems such as AVID. Well, as the best thing is always to clarify the doubts here is an article that I hope you will find useful.
MXF (Material Exchange Format) is a file format for the exchange of audiovisual material with associated metadata between different applications. Its technical characteristics are defined in the SMPTE 377M standard and was developed by the Pro-MPEG Forum, the EBU organization and the AAF association, together with the main companies and manufacturers of the broadcast industry. The ultimate goal is an open file format that facilitates the exchange of video, audio, data and associated metadata within a file-based workflow.
An MXF file functions as a container that can carry video, audio, graphics, etc. and their associated metadata, in addition to the necessary information that makes up the structure of the file. An important factor is that MXF is independent of the compression format used, since it can carry different types of formats such as MPEG, DV or a sequence of TIFFs. The great advantage of MXF is that it allows to store and exchange the associated metadata, which describes the content and the way the file should be read.
Metadata may contain information about:
- The file structure
- the content itself (MPEG, DV, ProRes, DnxHD, JPG, PCM, etc.)
- Time code
- Keywords or titles
- Subtitles
- Editing notes
- Date and version number of a clip -Etc.
MXF is based on the AAF (Advanced Authoring Format) data model and they are complementary to each other. The difference between this format and MXF is that the AAF format is optimized for post-production processes, because it allows a greater wealth of metadata to be stored and makes it possible to use references to external materials. MXF files can be embedded within AAF files, which means that an AAF project can include the audiovisual content and associated metadata, but can also call other externally hosted MXF content.
Achieving interoperability is the primary goal of MXF and three areas are established:
Multi-platform. You will work across different network protocols and operating systems, including Windows, Mac OS, Unix and Linux.
-Independent compression. Do not convert between compression formats, makes it easier to handle more than one native format. Can handle uncompressed video.
-Streaming transfer. MXF interacts seamlessly with streaming media in a bidirectional fashion. SDTI is an example of file-based transmission that works perfectly with this format. Transmission over IP networks is also optimal.
An MXF file has a structure that houses a file header detailing the contents of the file and its synchronization, the metadata associated with the media, the body containing the essence of the original media data and the tail that closes the file.
The data contained in MXF files is stored using a subdivision into a trio of KLV (Key-Length-Value) values. This is a unique 16-byte identification key for each trio, the length value of the data stored in that trio and the data itself (value). This way of organizing the data makes it possible to locate any specific element within the MXF file by simply reading the keys. This structure also allows the file format to grow and add new features with new compression techniques and metadata schemes as they are defined.
We can further enhance this by allowing partitions within a KLV trio. This means that the data of a trio can be fragmented into a succession of KLV trios and gives more robustness to the file structure. This has an advantage, for example, in the transmission of MXF files over networks, where if we lose the connection and the MXF transfer is cut, when recovering it will not be necessary to send the entire file again since we can hook into the trio where the transfer was broken.
So far I guess you all have it pretty clear and you will wonder why an MXF generated by an XDCAM camera is not compatible with the one generated by a P2 if the MXF format was created to ensure compatibility. Well, the great flexibility of MXF allows different interpretations and applications of the standard by different manufacturers, and this is how the MXF generated by the products of each one are not compatible with each other. This has led to the implementation of a series of different physical versions to improve interoperability according to their applications. In this way, the so-called Operational Patterns are established and each one will have its own specifications under its own standard that will define the type of image/sound that contains the essence and structure of the metadata. Of these patterns, OP-1a and OP-Atom are the most frequently encountered.
The generic operational standard is OP-1a and was created as a replacement for videotape, where a single MXF file contains video, several audio channels and timecode. It is very simple and flexible but has many limitations in terms of how it has to be worked with. An example in this case would be the XDCAM format or the JVC cameras that record on cards, where each of their clips has a single file with video and audio.
OP-Atom is a very simple file format that can have only a single element at its core, either a video or audio track. Typically, the metadata linked to the media contained in MXF OP-Atom is in AAF or XML files. A typical example is the P2 format, where the video and audio tracks are wrapped in separate MXF-Atom files and the metadata associating them goes in a separate XML file.
The media files generated by AVID are also OP-Atom and their associated metadata is in AAF. This is the most commonly used in editing environments, where individual access to audiovisual components is required. In the case of AVID, these files have the particularity of incorporating non-standard MXF metadata used by AVID applications to index them and that can create incompatibility problems if they are exchanged with other systems different to AVID.
In the case of digital cinema, the MXFs that carry the image and audio are also OP-Atom. In this case they are restricted to the specific compression and color space for this function (JPEG 2000 and XYZ) in the case of video and to 16 PCM tracks in the case of audio, so their compatibility outside this environment is very limited. Its synchronization and metadata is the information contained in XML files.
We can then establish a group of operation patterns (OP) with various levels of complexity, where the OP-1a pattern is the lowest level. A single continuous track with video, audio and metadata packed in one file is what defines the OP-1a pattern. The most complex level within these patterns is OP-3c, with the combination of several clips (packed files) with several playlists combined. Here is a table with them.
The Advanced Media Workflow Association (AMWA) was created to lead the development and promotion of the use of standards and technologies that enable more efficient workflows for the use of networked media. Its current projects are advancing the use of AAF, BXF, MXF and XML formats in data file-based workflows. The association works closely with SMPTE and other standards bodies.
Among its projects there is one that refers to MXF files and defines a set of rules that limit the MXF specification for the adaptation of this format to different applications and workflows. These specifications can be summarized in the following list:
AS-02 – MXF with mastering versions. It was developed to support the storage and management of the components of a program in MXF, to allow versioning, multi-languages and delivery to different media outlets. It is a file package that has all the necessary video, audio and metadata elements to generate multiple versions of a product. Who should use it? Post-production environments, broadcasters and content distributors.
AS-03 – Program Delivery. This MXF specification is optimized for program distribution and direct broadcast from a video server. It is a single file that incorporates audio, video and metadata from a single program. Who should use it? Networks of broadcasters.
AS-10 – MXF for Production. The AS-10 application specification is aimed at establishing a common MXF file format for the entire production workflow, including in-camera recording, ingest to a server, editing, playout, digital distribution and archiving.
An example is the use of MPEG Long-GOP. The project includes the development of an application to validate files as an aid to quality control processes. Who should use it? Production and post-production, broadcasters and content distributors.
AS-11 – MXF for redistribution. This is an MXF file format for delivery of finished products from broadcast stations to program creators. AS-11 includes the functionality of AS-03 and is extended to include AVC-Intra 100, and includes support for the D-10 standard definition video standard with AES3 audio. AS-11 defines a basic minimum metadata set, and a metadata schema with program segmentation. Who should use it? Broadcasters and content distributors.
AS-12 – Commercial Delivery. AS-12 is a subset of MXF format files for delivery of finished commercials to television stations or broadcast networks. The specification provides a clapperboard and other metadata to associate with the audio and video essence. AS-12 requires that explicit identification of content be computer-assisted and that the playlist be controlled by the computer. Who should use it? Production and post-production, commercial distribution, broadcasters and cable networks.
The main characteristics of these MXFs are shown in the following table, AS-02 does not appear because its development process has not yet been definitively completed.
And speaking of AS-02, AVID in its new version 6.5 of the MediaComposer and Symphony solutions supports this format. A new AMA (Avid Media Access) component called Avid Media Authoring allows users to deliver and archive multiple output formats, including AS-02. A new native JPEG 2000 codec is incorporated so that multi-cast, multi-version, multi-language products can be packaged without content degradation. AS-02 in Avid supports J2K, Uncompressed 10b RGB, DNxHD, AVCI, IMX and Uncompressed 8b for SD.
When we create an AS-02 package we will find the following file structure:
- Asset.mxf is the sequence (version) file.
- Manifest.xml is a file that includes information about the creator, creation date, version information and a list of all the files and folders contained in the AS-02 package.
- Shim.xml is a template or configuration file that limits the rules for a specific use.
- The Media folder contains all the media files included in the package.
- The Extra folder contains a copy of the uncompressed sequence in a file with an AAF layout. This folder may also contain additional files that you want to include in the package, such as scripts, graphics, etc.
Here you can download a document about AS-02 and AVID
We would also like to remind you that these contents are explained in our DCP course. Creation of digital cinema with free software.
Here is also the list of standards that refer to the MXF format (source: wikipedia)
-BASE DOCUMENTS:
SMPTE 377M: The MXF File Format Specification (main general document)
SMPTE EG41: MXF Engineering Guide (guide explaining how to use MXF)
SMPTE EG42: MXF Descriptive Metadata (guide explaining how to use the descriptive metadata in MXF)
-OPERATIONAL PATTERNS:
SMPTE 390M: OP-Atom (a simple layout for MXF files) SMPTE 378M: OP-1a
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
-GENERIC CONTAINERS:
SMPTE 379M: Generic Container (how to store essence 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 i Broadcast audio essence data in MXF using Generic Container)
SMPTE 384M: GC-UP (how to store uncompressed image essence data in MXF using the Generic Container)
SMPTE 388M: GC-AA (how to store A-law encoded 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
-METADATA, DICTIONARIES AND REGISTRIES:
SMPTE 380M: DMS1 (descriptive metadata set for use with MXF files)
SMPTE 436M: MXF Mappings for VBI Lines and Ancillary Data Packets SMPTE RP210: SMPTE Metadata Dictionary
SMPTE RP224: Registry of SMPTE Universal Labels