MXF (Material Exchange Format) is
a file format intended for the
exchange of audiovisual material with associated metadata between
different applications. Its technical characteristics are defined in
the SMPTE 377M standard, and it was developed by the Pro-MPEG Forum,
the EBU organization and the AAF association, together with major
companies and manufacturers from the broadcast industry. The final goal is
an open file format that makes it easier to exchange video,
audio, data and associated metadata within a file-based workflow.
An MXF file works as a container that can carry video,
audio, graphics and more, together with their associated metadata and
the information required to define the structure of the file. One important
factor is that MXF is independent from the compression format
being used, since it can transport different formats such as
MPEG, DV or a TIFF sequence. The great advantage of MXF is that it
can store and exchange associated metadata, describing
the content and the way the file should be read.
Metadata can contain information about:
File structure
The content itself (MPEG, DV, ProRes, DNx, JPG, PCM, etc.)
Timecode
Keywords or titles
Subtitles
Edit notes
Date and version number of a clip, etc.
MXF is based on the AAF (Advanced Authoring Format) data model, and
both formats are complementary. The difference between AAF and MXF is
that AAF is optimized for post-production processes,
because it can store richer metadata and can
reference external media. MXF files
can be embedded inside AAF files, which means that an
AAF project may include audiovisual content and associated metadata,
while also referencing other externally stored MXF content.
Interoperability is the primary goal of MXF, and it is
defined around three areas:
cross-platform operation, working through different network protocols
and operating systems including Windows, Mac OS, Unix and Linux;
compression independence, avoiding unnecessary conversion between compression formats
and making it easier to handle more than one native format, including
uncompressed video; and streaming transfer, where MXF interacts very well with
bidirectional streaming media. SDTI is one example of a file-based
transmission system that works very well with this
format, and transmission over IP networks is also optimal.
An MXF file has a structure containing a file header
where file content and synchronization are described, the
metadata associated with the media, the body containing the essence
of the original multimedia data and the footer that closes the file.
Data contained in MXF files is stored using
a subdivision into KLV triplets (Key-Length-Value). This means
a unique 16-byte identification key for each triplet, the
length value of the data stored in that triplet and
the data itself. This way of organizing data makes it possible to
locate any specific element inside the MXF file simply
by reading the keys. This structure also allows the file format
to grow and add new features as new compression techniques
and metadata schemes are defined.
We can go one step further: partitions are allowed
inside a KLV triplet. This means that the data in a triplet
can be fragmented into a sequence of KLV triplets, making
the file structure more robust. One advantage appears, for
example, when transmitting MXF files over networks: if the
connection is lost and the MXF transfer is interrupted, once
it is restored there is no need to resend the entire file, because
the transfer can resume from the triplet where it broke.
At this point, the basics are clear, but it is natural to wonder
why an MXF generated by an XDCAM camera is not
compatible with one generated by a P2 camera if MXF was created to
guarantee compatibility. The reason is that MXF's great flexibility
allows different interpretations and applications of the standard by
different manufacturers. As a result, the MXF files generated by each
product are not always compatible with one another. This led to the
implementation of several physical versions to improve interoperability
according to each application. These are known as Operational Patterns,
and each one has specifications under its own standard, defining the
image or sound type carried by the essence and the structure of the metadata.
Of these patterns, OP-1a and OP-Atom are the ones we encounter most
often.
The generic operational pattern is OP-1a, created as a replacement for
videotape, where a single MXF file contains video, several
audio channels and timecodes. It is very simple and flexible, but
has many limitations when working directly with it.
Examples include XDCAM format or JVC cameras that
record to cards, where each clip has a single file
containing both video and audio.
OP-Atom is a very simple file format that can only have
one single element in its essence, either a video or audio track. In
general, the metadata linked to the media contained in OP-Atom MXF files
is stored in AAF or XML files. A typical example is P2, where
video and audio tracks are wrapped in separate MXF-Atom files
and the metadata linking them is stored in a separate XML file.
The media files generated by AVID are also OP-Atom, with associated
metadata stored in AAF. This is the most widely used format in editing
environments, where individual access to audiovisual components is required.
In the case of AVID, these files include non-standard MXF metadata
used by the manufacturer's applications to index them, which
can create incompatibility issues if they are exchanged with non-AVID
systems.
In digital cinema, the MXF files carrying image and audio
are also OP-Atom. In this case they are restricted to the compression and
color space required for that purpose (JPEG 2000 and XYZ) for
video, and to 16 PCM tracks for audio, so their compatibility
outside that environment is very limited. Synchronization and metadata
are carried by XML files.
We can define a group of operational patterns (OP) with
several levels of complexity, where OP-1a is the lowest level.
A single continuous track with video, audio and metadata
packaged in one file defines the OP-1a pattern. The most complex
level within these patterns is OP-3c, combining
several clips (packaged files) with several combined playlists.
Here is a table with those patterns.
The AMWA (Advanced Media Workflow Association) was
created to lead the development and promotion of standards and technologies
that enable more efficient workflows for networked media. Its current projects
advance the use of AAF, BXF, MXF and XML formats in file-based
data workflows. This association works closely with SMPTE and other
standards bodies. One of its projects refers to MXF files and
defines a set of rules that constrain the MXF specification in order
to adapt the format to different applications and workflows.
AMWA specifications can be summarized as follows:
AS-02 - MXF with mastering versions. This was
developed to support storage and management of program components
in MXF, allowing versions, multiple languages and deliveries to
different distribution media. It is a file package containing
all the video, audio and metadata elements required to generate
several 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 playout from a video server.
It is a single file containing audio, video and metadata
for one program. Who should use it? Broadcast networks.
AS-10 - MXF for production. The AS-10 application specification
is intended to establish a common MXF file format for the full
workflow of a production, including camera recording, server ingest,
editing, playback, digital distribution and archiving.
One example is the use of MPEG Long-GOP. The project includes
development of an application to validate files as an aid
for 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 delivering finished products from program creators to broadcast
stations. AS-11 includes AS-03 functionality and extends it to include
AVC-Intra 100, plus support for the D-10 standard-definition video
standard with AES3 audio. AS-11 defines a minimum core metadata set
and a metadata scheme with program segmentation. Who should use it?
Broadcasters and content distributors.
AS-12 - Commercial delivery. AS-12 is a subset of MXF files
for delivery of finished commercials to television stations or broadcast
networks. The specification provides a slate and other metadata to associate
with the sound and video essence. AS-12 establishes that explicit
content identification is computer-assisted and that the system controls
the playlist. Who should use it? Production and post-production,
commercial distribution, broadcasters and cable networks.
The main characteristics of these MXF files are shown in the following
table. AS-02 does not appear because its development process was not yet
definitively closed.
Speaking of these formats, AVID has supported them since
Media Composer version 7. A new AMA (Avid Media Access)
component called Avid Media Authoring allows users to
deliver and archive multiple output formats, including AS-02 and AS-11.
These formats are commonly used to deliver our work to
broadcast and content distribution centers. SMPTE has also approved
IMF (Interoperable Master Format) as a standard, with a structure
very similar to DCP (Digital Cinema Package) but designed for the
broadcast world, and used by NETFLIX for the deliveries it receives.