Material Exchange Format—MXF

The MXF file format is the fruit of a joint effort of users and manufactur- ers grouped in several international associations such as the EBU, the AAF Association, and the ProMPEG Forum. It is a response to the need, defined as urgent by the EBU/SMPTE Task Force, to develop and standardize a file format that would be used throughout the industry for content exchange over different transfer media.

In order to respond to these expectations, the MXF format has to fulfill a num- ber of requirements. Some of them are related to the basics of the format itself, or stem from the need to accommodate the differences of streaming and file trans- fer, while others are related to the specifics of different areas of the wide field of content production and distribution. For example, a file format designed for streaming must have the essence arranged in the body in a directly playable order or must carry a sufficient amount of metadata information to facilitate full recog- nition of the transported payload. On the other hand, different parts of the content production and distribution process have different requirements. In acquisition it is necessary to generate different categories of metadata information depending of the type of program (the “who, what, when, where, and why” of the news opera- tions or the “shot, take, and location” information for the documentaries, drama, children or music programs). That phase of content production may require rec- onciling the recommendation to keep the original recorded format unchanged with the need to use circuits that do not offer an adequate bandwidth for the transfer of the shots in their native form to the base. The postproduction part of the process is distinguished by a huge amount of metadata information that has to be generated, handled, and stored—from the edit decision lists, edit history, and ownership to all other postproduction-related information. In addition, at the end of that phase it is important to store a copy of a finished program as “work in progress” in order to facilitate later refinements and the production of derived works. The storage, distribution, and subsequent archiving of finished works demands considerably less additional information, but it must contain informa- tion on program ownership, content usage, and all cross-referencing data needed for an easy retrieval. At the same time the content has to be stored in an easily streamable form.

The design of MXF files is based on a set of guidelines derived from a number of user requirements, with the result that MXF files are

• easy to understand and apply by adequately trained technical staff

• compression agnostic (i.e. they accept all signals regardless of the compres- sion method used to generate them)

• an open system (i.e. a system that can be easily interconnected with other systems)

8.3 Material Exchange Format—MXF 123

• capable of providing an adequate identification of the payload

• extensible and scaleable (i.e. a system that can be extended in the future and that can be used in configurations of different complexity)

• usable on all major platforms • adapted to a partial file transfer

• independent from a transport and storage mechanism • easily convertible between stream and storage versions

It should be added that the participants in the development process took note of the results achieved in the domain of AAF system definition, and of the role that this file format could play in complex postproduction processes, and concluded that not only must a very high degree of interoperability be ensured between the two file formats, but also that MXF must be developed as a subset of the AAF system.

An MXF file is a very complex file format. That complexity is undoubtedly the result of the need to respond to the numerous demands of the content-creation environment and of the intricacies of a mixed conventional and IT-based technical production systems. Consequently, the description of an MXF file in this book must suffer from oversimplification as it will be unavoidably limited to a sketchy exposition of its most prominent features.

The basic definition of an MXF file is that it is a physical implementation of a data or logical model. As symbolically represented in Figure 8.2, an MXF file is composed of a header that starts the file, carries the metadata necessary for the identification of the content, and timing and synchronization information. The header partition also contains labels used to determine the compliance of the decoders. The MXF system is designed in such a way that every MXF decoder must be capable of reading the header and reporting the file content regardless of whether or not it is capable of decoding that particular content.

The next part of the file is its body where the essence container stores picture, sound, and data essence that can be considered to be the basic material of the file content. The essence container also indicates that the basic material has been packed in a file in an interoperable way. Picture and sound information may be stored in the essence container in different ways depending on the intended use of the file. In addition, several essence containers can be placed inside a single file. These essence containers are then separated by partitions, (not visible on

File Header File body File footer Header

Partition

Header

Metadata Essence Container

Footer Partition pack

Figure 8.2) which facilitates the use of MXF files for playlists (i.e. electronically generated lists of program items that automatically controls their playout in a predetermined order at predetermined times).

Additional data are included in the header to make the file as versatile and flexible as possible. For example the index tables and the random index pack define the position of all partitions inside a file making random access to the material placed inside a file easy and unambiguous. Other housekeeping information, like the data that define the position of the file footer, completes the file content.

All elements enclosed inside an MXF file are coded in a special way by KLV coding (key, length, value). Because of that code, all MXF decoders and processing units can simply ignore items they do not recognize and continue processing the recognized ones. Simultaneously the KLV code offers an opportunity to develop further the file format by adding new features (for example, compression methods unknown today or innovative metadata schemes), knowing that such additions will not disturb the functioning of the existing equipment (which will just ignore these additions and process the recognized elements).

Metadata content defines the logical construction of the file. It also defines and describes different essence types that exist inside the file. The logical meta- data representation is very compact, and its size does not depend on the size of the essence it represents. It is possible to identify two main types of metadata: structural and descriptive metadata.

Structural metadata are defined and standardized by appropriate SMPTE docu-

ments and are used to define first the number of basic essence parameters such as picture size, rate, aspect ratio, audio-sampling frequency, audio quantization, and so on. Structural metadata will carry information about the compression scheme used in the video and in the audio essence and consequently will offer informa- tion on the type of decoder needed for decompression. Structural metadata also describe the mutual relationships of different essence types.

Descriptive metadata offer additional information to those defining the structure

of the file and its components and can be read by either humans or machines. Such metadata existed before files and file transfer. They were simply present as pieces of paper accompanying videotapes or cassettes. Obviously the amount of information on those papers (or sometimes even diskettes) varied from one organization or production process to another. Sometimes the information was implicit, as when operators recognized the recording format simply by looking at the physical appearance of the cassette. However, in the file domain everything has to be documented, and the list of items that might have to be documented could be endless. For that reason a descriptive metadata scheme 1 (DMS-1) was defined by selecting the number of descriptions usually accompanying magnetic tapes and cassettes and adopting that list as a standard that should cover most of the requirements of content production, distribution, and archiving. Descriptive