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, Director of Technology at 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 stream of file-based work. This initiative led to the development of the MXF (Material eXchange Format) approved by the SMPTE, in 2004.

When we initially designed MXF, we had a number of fundamental design requirements: we wanted users to be able to use and work with files, even as they were being created, before they were fully transferred to a disk, NLE, or playout server. We felt it was important to allow synchronization of separate components and to be able to provide graceful recovery from an interruption, ensuring that there would be enough information contained in that file, to allow it to easily recover from eventual 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 a primary operational goal for MXF: we wanted it to be applicable to a wide variety of workflows, to faithfully carry the metadata and essence, throughout the life cycle of a program, movie, or news clip.

Operational objective

During its lifecycle, 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 goal of eventually distributing the content to various destinations with different bitrate, resolution and quality of service.

Because the MXF is designed with workflows in mind, all handling processes are seamless for the user. It just works silently, in the background. Metadata stays tied to the core video and audio, through the production, playout and archiving process, so there is no need to re-enter metadata.

The MXF Metadata View and Physical View

To assist 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 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 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 Package 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 a frame wrapper of type OP1a 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 the MXF allows you to separate the metadata views and the physical view, it allows a seamless exchange of media and the vital metadata that goes with it, and allows the creation of different types of MXF, optimized for specific workflows.

The different types of MXF

The MXF was developed with a huge amount of input from the user community, to ensure that the format would truly 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 MXFs, 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 interleaved MXF file. It is flexible and contains no real restrictions on file construction rules. This makes your application actually very simple. But it has the disadvantage of suffering interoperability problems when different providers interact on it.

A close relative of the OP1a, 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 mainly in workflows that require low bit rates, such as HD at 50 Mbps. The downside is that, it is specified to have a maximum of 8 mono AES audio channels, and Even with these limitations, interoperability problems 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 allowing one component, and all component synchronization is done in the AAF file. However, OP-Atom files generated by Avid Media Composer often have non-MXF metadata in them. This is known as “dark metadata” and can lead to interoperability problems, in the exchange of files between different manufacturers.

The Panasonic 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 P2 file size, which may cause operational problems. On the other hand, the P2 design has opted for an XML format and not MXF, to synchronize audio and video. Even though the XML sync file references the stored MXF media, the XML structure may lose metadata in the round trip with a generic MXF file.

There is another variety of Component MXF, 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 than the P2 XML, and the AVID AAF. While it is a very, very limited format, which is very well suited to all aspects of digital cinema delivery, it is limited to RGB and JPEG 2000 color space, which makes it too restricted for a purpose interchange format. general, and not suitable for television workflows.

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

This issue 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 provider. They define a set of constraints on how the file is constructed, to match the technical and operational requirements at a particular point in the workflow.

If even stricter restrictions 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 facility-specific restrictions, that are defined by the company and written in a managed and 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; is designed to meet the needs of content creators and distributors who face the challenges of version control software. With the AS-02, audio, video and data are stored in separate media files, to enable efficient version control of programs for distribution. AS-02 is a “componentizer” file format; it is not a single file, but rather 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, multi-delivery media environment.

Today we have very good “reading” support for this format, but “writing” support is lagging behind. The AS-02 framework can make multi-version workflows very fast, and place some load on a facility's network infrastructure.

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

The AS-03 works perfectly for delivering 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. Building on AS-03, AS-11 should allow codecs that are MPEG (or non-MPEG) with higher bit rates, 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 version control 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 are 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 choosing the right MXF format at the right time and place.

If you are working with MXF and are interested in contributing to its continued 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 intended for. Above all, remember that MXF is not just a file format. It is simply a tool for building large file-based workflows. The success of the MXF will depend on how we use that tool.

Bruce Devlin

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

Other articles on AmberFin