MXF: What is it, how does it work, and why hasn't it solved the world's problems yet?

MXF is not just a file format, but a tool for building large file-based workflows whose success will depend on how we use it. Bruce Devlin, Chief Technology Officer of AmberFin and co-author of the MXF specification, reviews in this Tribune the current situation of the format and its future projection.

In the 1990s, a group of engineers, representing a number of end-users and manufacturers, came together with a mission: to develop an open file format that facilitates the exchange of video, audio, data, and associated metadata within a file-based workflow. This initiative led to the development of the MXF (Material eXchange Format) approved by SMPTE in 2004.

When we initially designed the MXF, we had a number of fundamental design requirements: we wanted users to be able to use and work with the files, even when they were being created, before they were fully transferred to a disk, NLE, or playout server. We felt it was important to allow the synchronization of the components separately and to be able to provide the successful recovery in the event of an interruption, ensuring that there would be enough information contained in that file, to allow it to recover easily from possible corruption. And, of course, it had to be open, standardized, and independent of the compression format. But above all, it had to be simple and flexible.

Along with the fundamental design requirements, we also had an overriding operational goal for the MXF: we wanted it to be applicable to a wide variety of workflows, to faithfully carry the metadata and essence, throughout the lifecycle of a program, movie, or news clip.

Operational objective

During its life cycle, a piece of content accumulates more and more bits of essence, and more and more metadata, until it is eventually ready to be sent to a playout system, or other type of distribution or publishing network.

The MXF is designed to transport material throughout the production chain, collecting metadata and different versions of the material, as the project progresses, with the aim of finally distributing the content to various destinations with different requirements for bitrates, resolution and quality of service.

Because the MXF is designed with workflows in mind, all handling processes are perfect for the user. Just work quietly, in the background. The metadata is kept tied to the essence of video and audio, through the production, playout and archiving process, so there is no need to re-enter metadata.

The metadata view and the MXF physical view

To aid in operational objectives, the MXF is designed to be viewed in two different ways:

The metadata view of a file represents the type of movie or TV show that the file is trying to represent, while the physical view of a file represents how the bytes are arranged, on the surface of the hard drive.

The diagram shows the metadata view of an MXF file on the left side, and the physical view of how these bytes are placed on the disk, on the right side.

In the metadata view, there are two different types of packages: a Material Package, which describes the timeline of an MXF file and what will happen when the 'play' button is pressed, and a File Package, which describes the video and audio physically stored in the file.

It is possible to have two MXF files that have identical metadata, but are physically arranged in two different ways, to optimize some element of a workflow. In a file with an OP1a frame wrapper, for example, everything in that file is interlaced frame by frame. The same asset could be physically arranged as a set of component files synchronized by an MXF AS-02 version file. Because MXF allows you to separate metadata views and the physical view, it allows for seamless exchange of media and vitally important metadata that go with it, and allows for the creation of different types of MXFs, optimized for specific workflows.

The Different Types of MXF

The MXF was developed with a tremendous amount of input from the user community, to ensure that the format was actually going to meet their needs. The resulting flexibility also allowed vendors to develop their own interpretation of the standard for their codecs as a competitive differentiator. This inherent flexibility has led to the implementation of a number of different types of MXF, each with similar MXF metadata, but applying different physical views, optimized for different applications.

Let's start with the generic OP1a: OP1a is a simple tape-like implementation of the MXF format, which stores audio and video data in a single interlaced MXF file. It is flexible and contains no real restrictions on file construction rules. This makes its application actually very simple. But it has the disadvantage of suffering interoperability problems when different providers interact on it.

A close relative of OP1a, it is the XDCAM HD format. Designed by Sony, the XDCAM HD is much more restricted than the OP1a. It has much better interoperability, and tends to be used primarily in workflows that require low bitrates, such as HD at 50 Mbps. On the downside, it is specified to have a maximum of 8 channels of mono AES audio, and even with these limitations, interoperability issues persist. There is currently a working group within the Advanced Media Workflow Association (AMWA) examining the interoperability of XDCAM, and defining an even more limited variant called AS-10.

So, now let's take a look at one of the most common component versions of MXF, the OP-Atom.

Avid was a major contributor to the MXF standard, and as such, sponsored the creation of a particular variant of MXF, the so-called Op-Atom. It is highly restricted, only allows one component, and all the synchronization of the components is done in the AAF file. However, OP-Atom files generated by Avid's Media Composer often have non-MXF metadata in them. This is known as "dark metadata" and can lead to interoperability issues in file sharing between different manufacturers.

Panasonic's P2 system also uses OP-Atom to record the real essence of video and audio. The P2 format is very limited, with good interoperability and extensible use of metadata. However, there are certain limits on the size of the P2 file, which can cause operational issues. On the other hand, the P2 design has opted for an XML format and not MXF, to synchronize the audio and video. Even though the XML synchronization file references the MXF stored media, the XML structure may lose metadata on the round-trip, with a generic MXF file.

There is another variety of MXF with components, used by Digital Cinema, which once again uses a different way to synchronize files, called CPL (Composition Play List). This XML file has a different structure from the P2 XML, and the AVID AAF. While it's a very, very limited format, which is very well suited to all aspects of digital cinema delivery, it's limited to RGB and JPEG 2000 color space, which makes it too restricted for a general-purpose interchange format, and not suitable for TV workflows.

As we are beginning to see, despite the MXF standard's efforts to ensure seamless operation between the various vendors, the various 'types' of MXF continue to give rise to incompatibility issues. And, while interoperability is improving, as manufacturers are learning how to better implement standards, users still have some frustrations created by incompatible systems, which can't read outside versions of MXF files.

This problem has led to renewed collaboration between media companies, including AmberFin and a dozen vendors through the AMWA, to develop some Application Specifications (AS) as a basis for simple and easy interoperability.

The Application Specifications are not particular to any supplier. They define a set of constraints on how the file is constructed, so that it matches the technical and operational requirements at a particular point in the workflow.

If even stricter constraints are needed, for example, for the technical practices of a broadcaster, a particular genre of program, or a distribution channel, these can be defined as "wedges," a set of install-specific constraints, which are defined by the company and written in a managed, version-controlled document.

MXF's AS-02 and AS-03, for example, are designed to streamline file-based workflows within and across organizations.

The AS-02 is a mastering tool; It is designed to meet the needs of content creators and distributors, who are facing the challenges of the version control program. With the AS-02, audio, video and data are stored in separate media files to enable efficient program versioning for distribution. AS-02 is a "componentizing" file format, it is not a single file, but a set of elements united under the concept of a package, collected in a folder. A package is completely self-contained, and has all the assets and metadata necessary to generate multiple versions of a program, for use in a multi-version, multi-language, and multi-delivery media environment.

Today we have very good "reading" support for this format, but "writing" is lagging behind. The structure of the AS-02 can make multi-version workflows very fast, and produce a certain load on the network infrastructure of a facility.

MXF's AS-03 is intended for the delivery of finished content, directly to a playout server. The AS-03 forces the MXF toolbox to efficiently deliver final results in a compact, robust and directly reproducible format. An AS-03 file is always a single file, for a single program. The contents of these files are not intended for processing, but for direct playout from any server. The file contains a finished program or program segment, with its associated metadata, and typically includes video, audio, and subtitles, plus technical and AS-03-specific metadata, describing the file. AS-03 files contain defined metadata sets, for the identification and verification of content against the delivered traffic metadata.

The AS-03 works perfectly for the delivery of MPEG2 content to playout servers, but needs some modifications, if you want to use the same format for contribution between broadcasters and post-production companies. To address these application differences, AMWA is developing AS-11, a file format for the delivery of finished programming, from program producers to broadcast stations, or program creation facilities. Based on AS-03, AS-11 should allow codecs that are MPEG (or non-MPEG) with higher bitrates, for contribution purposes. A first implementation of AS11 is being proposed by the UK Digital Production Partnership in the United Kingdom, based on the AVCIntra codec.

This was a very quick tour of some of the most common MXF formats. When planning your workflow, it's worth carefully considering when you can use each of them: whether you're in an environment where you want to do audio versioning workflows, or in an environment where you need to store different components for different bits of workflow, something like the AS-02 makes a lot of sense. But if what you're trying to do is move essences plus metadata together, for example when you move from A to B, then a format like AS-03 or AS-11 may be more appropriate. After all, these Application Specifications have been specifically defined, to help the user community gain greater interoperability, and have an easier job of choosing the right MXF format at the right time and place.

If you are working with MXF and are interested in contributing to its ongoing development, you can go to the SMPTE website, http://smpte.org and join the standards community. The website contains a list of all the groups you can join. There is also the MXF book, which will give you a good reading resource on what the MXF standard is all about. Above all, remember that MXF is not just a file format. It's simply a tool for building large file-based workflows. The success of the MXF will depend on how we use that tool.

Bruce Devlin

Chief Technology Officer AmberFin and co-author of the MXF specification for which the SMPTE (Society of Motion Picture and Television Engineers) recently awarded him the 2011 David Sarnoff Gold Medal