Back in the 1990s, a group of engineers, representing a number of users and manufacturers, got together with a mission: develop an open file format that would facilitate the interchange of video, audio, data and associated metadata within a file-based workflow. This initiative eventually led to the development of the SMPTE-approved MXF in 2004.
When we initially designed MXF, we had a number of fundamental design requirements: We wanted it to enable users to use and work on the files, even as they are being created, before the completion of their transfer to a disk, NLE or playout server. We thought it was important that it should allow for the synchronization of separate components and that it should provide for graceful recovery after interruption by ensuring that enough information should be contained in that file to allow it to easily recover from corruption. And of course, it had to be open, standardized and compression-format independent. But most of all, it had to be simple and flexible.
Together with the fundamental design requirements, we also had one overarching operational goal for MXF: We wanted it to be applicable to a large variety of workflows, to carry faithfully the metadata and essence throughout the life cycle of a program, movie or news clip.
Operational goal
As a piece of content goes through its life cycle, it accumulates more and more bits of essence and more and more metadata until it is eventually ready to be sent out to a playout system or other kind of delivery or publishing network.
MXF is intended to transport material throughout the production chain, gathering metadata and different versions of material as the project progresses, with the goal of finally distributing the content to multiple destinations with different bit rates, resolutions and quality of service requirements. (See Figure 1.)
Because MXF is designed with workflows in mind, all the handling processes are seamless to the user. It just works quietly in the background. The metadata remains attached to video and audio essence throughout the production process, playout and archiving, so there is no need to keep re-entering metadata.
Two views
To help with operational objectives, MXF is designed so that it can be viewed in a couple of different ways.
The metadata view of a file represents what type of movie or TV program the file is trying to represent, whereas the physical view of a file represents how the bytes are arranged on the surface of the hard disk. (See Figure 2.)
Within the metadata view, there are two different sorts of packages: a Material Package, which describes the timeline of an MXF file and what's going to happen when you press the play button, and a File Package, which describes the video and audio that is 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. For instance, in a frame-wrapped OP1a file, everything in that file is interleaved frame by frame. The same asset could be physically arranged as a bundle of component files that are synchronized by an MXF AS-02 version file. Because MXF is able to separate the metadata view from the physical view, it allows seamless interchange of media and the vital metadata that goes with it and allows for the creation of different flavors of MXF optimized for specific workflows.
Multiple flavors
MXF was developed with an enormous amount of input from users to ensure that the format really met 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 deployment of a number of different flavors of MXF, each of them having similar MXF metadata but implementing different physical views that are optimized for different applications.
Let us start with generic OP1a. OP1a is a simple tape-like implementation of the MXF format that stores audio and video data in a single interleaved MXF file. It is flexible and contains no real constraints on file construction rules. This makes its implementation quite simple. On the downside, this high level of vendor flexibility also means that interoperability can suffer when different vendors interact for the first time.
A close relative of OP1a is the XDCAM HD format. Designed by Sony, XDCAM HD is much more constrained than OP1a. It has much better interoperability, and it tends to be mostly used in workflows that require lower bit rates, such as HD at 50Mb/s. On the down side, it is specified to have a maximum of eight channels of mono AES audio and even with these constraints, interoperability issues remain. There is currently a working group within the Advanced Media Workflow Association (AMWA) looking at XDCAM interoperability and defining an even more constrained variant called AS-10.
So let us now have a look at one of the most common componentized versions of MXF, OP-Atom. Avid was one of the major contributors to the MXF standard, and as such, sponsored the creation of a particular variant of MXF called OP-Atom. It is highly constrained; it 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 called “dark metadata” and can lead to interoperability problems when exchanging files between different manufacturers.
Panasonic's P2 system also uses OP-Atom to record the actual video essence and audio essence. The P2 format is constrained, with good interoperability and extensible use of metadata. However, there are certain limits in the P2 file size, which can cause operational problems. Moreover, the P2 design has chosen an XML format and not MXF to synchronize the audio and the video. Although the XML synchronization file references the stored MXF media, the structure of the XML can lose metadata when round-tripping with a generic MXF file.
There is another variety of componentized MXF that is used by digital cinema, which uses yet again a different way to synchronize files called composition play list (CPL). This XML file has a different structure from the P2 XML and from the AVID AAF. While it is an extremely constrained format that is well-suited for all aspects of digital cinema delivery, it is limited to RGB color space and JPEG 2000, which makes it too constrained for a general purpose interchange format and unsuitable for TV workflows.
As we are starting to see, in spite of the best efforts of the MXF standard to ensure seamless interoperability among the various vendors, the various flavors of MXF are still leading to incompatibly issues. And while interoperability is improving as manufacturers are learning how to better implement the standards, users continue to experience some frustrations created by incompatible systems that can't read each other's MXF files.
This problem has led to renewed collaboration between media companies including AmberFin and a dozen other vendors through AMWA to draw up some application specifications (AS) as the basis for simple, easy interoperability.
The application specifications are not particular to any one vendor. They define a set of constraints on how the file is constructed to match the operational and technical requirements at a particular point in the workflow.
If even tighter constraints are required for, say, a specific broadcaster's technical practices or a particular program genre or distribution channel, these can be defined as “shims,” a set of facility-specific restrictions that are defined by the business and are written into a managed and version-controlled document.
MXF AS-02 and AS-03, for instance, have been designed to streamline file-based workflows within and between organizations.
AS-02 is a mastering tool; it is designed to meet the needs of content creators and distributors who face program versioning challenges. With AS-02, video, audio and data are stored in separate media files to enable efficient versioning of programs for distribution. AS-02 is a “componentized” file format — not a single file, but a collection of elements bound together under the concept of a bundle, collected in a folder. A bundle is completely self-contained and holds all the assets and metadata needed to generate several versions of a program for use in a multiversion, multilingual, multidelivery media environment.
Today, we have good read support for this format, but write support is lagging behind. The structure of AS-02 can make multiversion workflow quick and produce light loading on a facility's network infrastructure.
MXF AS-03 is intended for delivery of finished content directly to a playout server. AS-03 constrains the MXF toolkit to efficiently carry final deliverables in a compact, robust and directly playable format. An AS-03 file is always a single file, for a single program. The content of these files is not intended for further processing before delivery to the viewer 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 for describing the file. AS-03 files contain defined metadata sets for content identification and verification versus delivered traffic metadata.
AS-03 works perfectly for delivering MPEG-2 content to playout servers but needs some modifications if you want to use the same format for contribution between broadcasters and post houses. 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 origination facilities. Based on AS-03, AS-11 should allow for codecs, which are MPEG (or non MPEG) with higher bit rates for contribution purposes. A first implementation of AS-11 is being proposed by the UK Digital Production Partnership, based on the AVC-Intra codec.
Conclusion
That was a quick tour of some of the most common MXF formats. When planning your workflow, it is worth considering carefully when you might use each of these. If you are 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 AS-02 makes a lot of sense. But if you want to lock everything together so that when you move from A to B nothing can ever fall off, then a format like AS-03 or as AS-11 might be more appropriate. After all, these application specifications are being defined specifically to help the user community get more interoperability and have an easier job of choosing the right MXF format at the right time, in the right place.
If you are working with MXF and are interested in contributing to its continued development, you can go the SMPTE website and join the standards community. The website contains a list of all the groups you might want to join. 31fs looks after MXF. There is also the MXF book, which will give you a good human-readable resource of what the MXF standard was intended to do. Above all, remember that MXF is just a file format. It is merely a tool for building great file-based workflows. The success of MXF will be dependent on how we use that tool.
Bruce Devlin is chief technology officer at AmberFin and co-author of the MXF specification.
