Demystifying MXF

Another great contribution from our very own Paul Turner!

What is MXF?

It’s hard to work in media without coming across the acronym “MXF” when discussing file formats. Once described (by some) as the solution to all file compatibility issues, it initially seemed to cause more problems than it solved. In some cases, these issues were caused by a lack of definitive language in the spec itself, but the main culprit is a lack of understanding of what MXF is and what problem it’s trying to solve. In this discussion, I’ll attempt to strip away the complexity (MXF is described in over 20 SMPTE documents!!!), and give you a basic understanding of the technology.

Fundamentally, MXF (Media Exchange Format) is a method of combining both media -audio, video, captions, timecode – and its associated metadata in a standardized way, often called “wrapping” of data, so that interchange of that media between different systems is simplified (simplified is a relative term here – I don’t think anyone who reads the entire suite of SMPTE specifications would use the term simplified). The term “metadata” means “data about the data”, which can seem confusing. But the label on a DVD is metadata – it tells you the title of the move, its running time, other important information. In MXF, we’re interested in transferring 2 separate types of metadata: Structural Metadata, which is information that the decoder needs in order to be able to play back the file (video format, audio format, picture aspect ratio, audio sample rate etc.), and Descriptive Metadata, which is information that the user/viewer or business system may need to manage the media (Program title, episode number, creation date, producer, etc.). Structural Metadata is generally created and inserted by the software that is encoding the file in the first place and is usually created automatically without direct user input, while Descriptive Metadata usually requires user input of some sort.

This metadata is always included at the very start of the MXF file, so that a file reader can determine very quickly if it can or cannot decode a particular file. For a number of technical reasons, it may also be repeated at regular intervals in the file including potentially being repeated at the end of the file. Most applications use the information at the start or end of the file and ignore the intermediate copies, but that’s up to the individual software app.

Issues with MXF

What MXF itself does NOT do is force the use of specific video/audio formatting. This is the primary reason for the initial problems when customers tried to implement MXF workflows. Basically, any video format can be wrapped in an MXF wrapper. So you could have one manufacturer’s encoder creating completely valid MXF files that another manufacturer’s decoder would fail to read – because the encoder was encoding JPEG 2000 while the decoder could only decode MPEG-2. In many cases, this can be determined by examining the Structural Metadata, but it’s not always the case.

The MXF specification itself is extremely broad – there are many, many possible uses for this format, from packaging a finished movie for digital distribution to cinemas, to identifying the camera used to capture a particular clip and its GPS coordinates at the time of capture. This flexibility is both a benefit and a curse – very few people have the time (or inclination) to wade through all of the specification documents, and the huge number of attributes means that one software engineer may chose to encode metadata one way, while another may look somewhere else in the metadata for some specific information. An example of this is timecode: there are at least 4 places where an encoder may place timecode, each of which makes sense in some specific use case(s). If an encoder puts timecode in location A, while the subsequent decoder is looking for timecode in location B (both of which are valid in the MXF spec), then you end up with timecode getting lost in the transfer.

Solutions?

To get around this, the designers of MXF allowed for something called an “Application Specification” – often shortened to “AS”, which allows users to constrain those pieces of metadata that are important to their specific use case (“Application”), while ignoring or disallowing other items that are not important to them.

So there you have it. MXF is just a way to wrap media and its associated metadata together to make software systems talk more reliably to each other.

We’ll talk more about Application Specifications in the next post.

Want to see if you can playback and inspect MXF files? Check out our newest product Switch, a media player with inspection and correction for professionals.