MXF and AAF

The need for AAF

If MXF contains many different possible layouts, you may be wondering why there is a need for AAF at all. The reason is fairly simple. AAF allows you to wrap up many different tracks of video, audio and data essence, and describe how these different tracks relate to each other. Think about layering or compositing in an edit application. For those not familiar with this idea, layering allows an editor to superimpose one layer of video, say an animated graphic or a window of video, on top of another base layer. Compositing is a common application in editing, but it is not common in the on-air environment, where users generally are playing back finished program material.

An AAF file could contain a base layer consisting of a video and two audio tracks, a compositing layer consisting of another video and two audio tracks, plus some editing metadata that instructs how to manipulate these two pieces of video to produce the finished result. (See Figure 2.)

Another difference between AAF and MXF is a result of what I stated above — that MXF is primarily intended to be used in an on-air environment, while AAF is generally intended to be used for editing. Therefore, it is a common user requirement that MXF files be complete and ready to play at any time. Therefore, many (but not all) MXF files contain video and audio inside the file. By contrast, it is not uncommon to find that an AAF file that contains only references to external essence. In other words, the AAF file is small and only contains metadata, including pointers to the actual essence files and other metadata with instructions regarding what to do with them.

So, why is there this fundamental difference between AAF files and MXF files? Well, imagine you are in an air playout situation. The last thing you want to find out just as you are going to air (or after you have pressed the “play” button) is that an audio or video track cannot be located on a remote storage device. Since MXF files need to play when the “play” button is pressed, it makes a lot of sense to package video and audio inside a file.

By contrast, think about a typical broadcast promo. If your station produces local promos, you might be surprised to find out how many separate video, audio, graphics, subtitle and descriptive video elements go into a simple 15-second promo. Now, imagine a half-hour, multi-camera, pre-produced news program. This edit project could have more than 1000 (several thousand, actually) individual elements associated with it. It is likely to be more efficient to organize separately the different elements going into this program on disk, perhaps using shared storage. An AAF file could then be a lightweight, metadata-only file, with pointers to the actual content stored on shared storage. This is a common way to build a professional video editor.

So, AAF and MXF may be used differently, depending on the application. For finished programming, use MXF. For an edit environment, or an environment where you need to describe the relationship between a number of separate elements, use AAF.

Lastly, AAF and MXF are interchange formats and meant to be the lowest-common-denominator to get content from one system to another. It is common or likely that inside a system, you will not find AAF or MXF (with some exceptions). Also, since these are baseline formats, it is common to find capability-adding extensions. But, these extensions could hamper interoperability.

---

—Brad Gilmer is president of Gilmer & Associates, a consulting technology firm. He is also executive director of the Advanced Media Workflow Association and executive director of the Video Services Forum.