Editing tools surpassed the capabilities of conventional edit decision lists (EDLs) long ago. Today’s non-linear tools are able to create critical information that just cannot be transported via an EDL. Avid’s Open Media Framework (OMF) promised to overcome the limitations of EDLs, but standardization and implementation difficulties have prevented it from becoming
truly universal. Two new standards, Advanced Authoring Format (AAF) and Media Exchange Format (MXF), hold great promise to help solve today’s interchange dilemmas. They are robust enough to contain all the information that any sequence contains and are extensible, meaning that new features can be added later.

Together, AAF and MXF offer the prospect of complete data interchange between picture, audio and effects systems — the ability to cut a sequence on a picture system, hand it intact to sound, move it to the mixing stage, and finally load it back into the picture system with everything visible and audible everywhere. The editing and mixing communities have been waiting for such a standard for a decade now, and it may finally be within reach.

But to realize this potential, manufacturers must provide applications and tools that make full use of the AAF and MXF technologies. This will happen only if customers demand complete and robust implementations from their suppliers.

What are AAF and MXF?

Advanced Authoring Format (AAF) is a project format. An AAF file contains “edit data” — a numerical description of a composition’s tracks, events, transitions, and effects, together with references to source media. AAF can work with a wide variety of media types, including Windows Media, Quicktime, General eXchange Format, or, most naturally, MXF. This flexibility assures AAF ’s relevance in many environments.

Media Exchange Format (MXF) is a media format — it contains actual video and audio media. It is called a “media wrapper,” because it conceptually “wraps” the raw media inside a well-defined data structure, allowing applications to understand the contents. Unlike many other media wrappers in current use, it was designed from the ground up for professional applications and compatibility with AAF. MXF files may be associated with AAF compositions or they can function on their own. MXF can contain any kind of raw media format, such as WAV, MPEG, AVI, or DPX, making it useful for many purposes.

AAF and MXF are closely related. They share identical internal data structures, and both make use of the Society of Motion Picture and Television Engineers (SMPTE) Metadata Dictionary technology, which standardizes many types of high-level data and workflow information. Both are platform independent — they can be used on and transported between Windows, Macintosh OS, Unix, Linux and other systems.

Together these standards have the potential to revolutionize professional digital production and post production by solving many of the fundamental issues standing in the way of interoperability. But, they don’t solve the interchange problem by themselves. They only provide a standard mechanism for transferring data between systems — the applications themselves must be capable of using this information effectively to deliver solutions to customers.

Shades of OMF

AAF and MXF are descendents of Avid’s Open Media Framework (OMF) technology. They retain many of the features of OMF but have been redesigned and updated. The internal data structures used to record the edit data, the AAF “object model,” is derived from OMF. It retains the power and flexibility of the OMF Object Model while refining the details and adding significant capabilities. Like OMF, AAF and MXF are “extensible,” meaning new features can be added without disrupting earlier versions — they are forward- and reverse-compatible.

They also inherit some of the subtle challenges that plagued OMF. Some important details are not explicitly part of the AAF and MXF standards — yet. For example, many Avid-specific audio and visual effects cannot be transported to other systems. This is because the OMF standard does not define these effects — they are private to the Avid implementations. Like the OMF standard, the AAF standard describes many effects, but not all. This needs improvement before AAF applications can deliver a more complete set of effects..

Prospects for Success — A Matter of Standards


The success of any interchange standard is measured by the degree to which it becomes widely used. Many factors combine to influence this, including the nature of the organization producing the standard, the intentions of that organization, proprietary interests with regard to patents and competition, market forces driving its implementation and, finally, acceptance by the end user. All the while the costs of implementation and licensing hang over the process.

There are many examples of successful standards: Internet protocols such as the URL and HTML, the standardization of physical film dimensions, NTSC and PAL video, timecode, and newer technologies like MPEG and DVD. Indeed a myriad of standards supports the entire civilized world — there are standards for creating nuts and bolts, standards for processing petroleum into gasoline, standards for avionics and aeronautical engineering. Some successful standard is involved in almost everything you touch or use.

There are also many examples of failed and troubled standards. The cell phone industry in the United States is still engaged in a battle over proprietary standards, and this competition has impeded the deployment of cell phones in the U.S. compared to other countries. Standards difficulties are still delaying high-definition television broadcast here.

Likewise, OMF did not fulfill its promise as an interchange format for editing systems. One key reason was that it was not a “public” standard — it was an Avid technology. This led to resistance from other manufacturers. To see how AAF and MXF might avoid this critical failing, it is helpful to review the way standards come about.

How Standards Are Created

There are three important ways that standards are created. First there is the “de facto standard” — proprietary technologies that become so well known and widely used that they are simply ubiquitous. Such standards are not official. They are created and maintained privately. This means that the company creating them can change the standard at will or charge licensing fees to those companies that use it. In the case of many popular de facto standards, the choice is made to charge no licensing fee. This helps promote the use of the standard, which in turn encourages the purchase of the company’s proprietary applications that make use of it.

Official standards, on the other hand, are created by recognized standards organizations. The defining characteristic of a standards body is they are “due-process” organizations — they follow formal voting and review procedures. Proposals are advanced though technical committees that debate the merits of the design. Discussions are a matter of record. Votes are taken to arrive at a consensus. In some cases the final document enters a comment period. Finally the standard is ratified by the standards organization.

There are two main types of official standards bodies — the “consortium” and the “society.” A consortium is a semi-private organization made up of member companies. A society is a public association of individuals. Consortiums typically have more money and resources than societies and they are often able to reach consensus more quickly because there are fewer participants.

A consortium’s standards are not necessarily “public” and may not carry the full weight of a public standard. Nonetheless, they can be legitimate official standards because they are created by due process. For example, the DVD specification was created by a consortium called the DVD Forum. Its members are large companies (Philips, Matsushita, Time Warner, etc.) and the work was done internally and not subject to public comment or review. Another influential consortium is the World Wide Web Consortium (W3C), which has been responsible for many important Internet standards including the familiar HTML and XML.

In contrast, a society’s membership is made up of individuals. Very often, these people are sponsored by large companies but the person is the member, not the company. This is an important, if subtle, legal distinction because the person’s vote counts, not the organization’s. It also means anyone can be a member, not just company employees.

Societies face an additional requirement — each standard must be made available for public comment and anyone can raise objections. The organization must respond by answering the comment. If the comment raises a legitimate concern, the document may be sent “back down” to the technical committee for revisions and another vote. This public comment procedure adds further legitimacy to the standard.

Societies typically work under the supervision of other organizations, which perform oversight and monitoring of due-process procedures to bestow additional authority on the final standard. The American National Standards Institute (ANSI — www.ansi.org) and the International Organization for Standardization (ISO — www.iso.ch) are two important examples of oversight organizations.

In our industry, the Society of Motion Picture and Television Engineers (SMPTE — www.smpte.org) and the Audio Engineering Society (AES — www.aes.org) are familiar. Both are societies of individuals and both are associated with standards oversight organizations. They have created many of the public standards our industry is based on.

All the procedures for creating finished standards take time and everyone gets frustrated with the pace of development. But it is the due-process procedure that assures the legitimacy of the standard.

The OMF Experience

OMF is a de facto standard because Avid is its custodian, not a recognized standards organization. In addition, it has a history of instability. In particular, when Avid chose to introduce OMF2, there was a significant break from the design of OMF1. This bifurcation of the standard caused many development difficulties. Indeed, OMF2 is different enough from OMF1 to be considered a completely different format from a technical point of view. Another obstacle to OMF acceptance was proprietary jealousy. Not all companies trusted Avid’s intentions — OMF was “not invented here.” All these factors caused many companies to avoid supporting OMF altogether.

This was not Avid’s intention. The company made valiant attempts at moving OMF into the public domain through both SMPTE and the AES. These efforts were expensive and demonstrated Avid’s desire to make OMF work for the industry. Unfortunately the attempt foundered for several reasons.

First, OMF technology is complex and its documentation is dense. It takes a great deal of effort to wade through, understand and comment on any standards document, and the OMF documentation was especially difficult and large. The people at SMPTE and AES most qualified to evaluate it simply could not devote enough time to finish the project.

But a more concrete problem arose because of proprietary licensing issues. OMF uses an underlying technology called Bento — a “container” format for recording object-oriented data on disk. Bento was developed by and is owned by Apple and is freely licensed to OMF developers. However, for SMPTE or AES to standardize something, all proprietary issues, including patents and copyrights, must be formally waived. Significant legal effort was made to convince Apple to release Bento into the public domain, but in the end Apple refused. This finally killed OMF’s chances for broad implementation.

AAF and MXF Appear

From the outset AAF and MXF sought to avoid the difficulties OMF faced. To accelerate the process an organization was created called the AAF Association (www.aafassociation.org). The AAF Association is a consortium — it has companies as members. It was founded by Avid and Microsoft, and many other important companies have joined.

The first effort was to redesign the OMF object model and to provide a new container format to replace Bento. Avid contributed the intellectual property of the OMF Object Model as a starting point and Microsoft contributed something it calls Structured Storage as the new container format. The resulting AAF Object Model is derived from OMF and retains the power and flexibility of the OMF Object Model while refining its details and adding significant capabilities.

In addition, programming tools were required to provide manufacturers with a starting point for implementation. These are called “software development kits” or SDKs. Both Avid and Microsoft have made very significant efforts in creating and testing the AAF SDK, and the AAF Association has made the SDK software “open source,” meaning that it can be freely copied. It is available at Source Forge (http://sourceforge.net/projects/aaf/). Along the way, elaborate documentation was written to formalize the AAF standard and to promote its use.

Meanwhile, another effort was underway at the Pro-MPEG Forum (www.pro-mpeg.org), the European Broadcast Union (EBU — www.ebu.ch) and SMPTE to develop a standardized media wrapper. Industries beyond the professional production business such as the telcoms, Internet companies and the computer industry required an interoperable way to transport video and audio media. The Pro-MPEG Forum (a consortium) was formed to take up this challenge, and, in coordination with the EBU and SMPTE, helped create MXF.

Even though the standardization process is not completed, many companies are already implementing AAF and MXF or have plans to do so, because they believe they have reached the point of inevitability. The coordinated efforts of the AAF Association, Pro-MPEG, the EBU, and SMPTE have accumulated a huge body of agreed-upon details. Avid and Microsoft’s continued leadership builds faith that the format ’s future is good.

Success Depends on the User

AAF and MXF promise to fulfill the dream of transparent project interchange — and there is no other option on the horizon. But the proof is in the pudding, and technical and business challenges remain.

Both AAF and MXF are complex, abstract software technologies and this means there will be teething pains as they mature. Each company must develop in-house expertise to build robust implementations. Each is faced with the technical challenge of mapping their particular system architecture into and out of AAF and MXF. The cost of this effort will be higher than some would like, but the challenge of digital project and media interchange demands it.

Standards and technology are not created in a vacuum — they are designed to solve real world problems. Yet the standards organizations and manufacturers cannot anticipate all the user’s requirements nor can they provide all the expertise and financial resources required. This is especially true in the professional production industry where there are so many diverse requirements and workflows. AAF and MXF must accommodate all of them. This sounds like a tall order, but the underlying technology is capable of it. This is where your input can be invaluable — the production community, facilities and major studios can help accelerate development and acceptance.

In previous OMF implementations, too many systems failed to divulge critical editing information in their exported OMFs. Some systems offered good OMF import but sub-par OMF export, which had the effect of driving editing projects into that system’s world and reducing competition. This situation must be avoided if AAF and MXF are to become universal. Manufacturers must be persuaded to create robust and honest implementations, not just skeletal, obligatory applications to satisfy the skin-deep marketing demand for “AAF/MXF Compatibility.” Truly useful applications must read and write all important aspects of a composition. This must include the details of visual effects, audio information, film information, etc. A partial implementation is not enough.

Manufacturers are persuaded by profit motive, not by good intentions. AAF and MXF will be expensive to develop and test. Software developers will only allocate resources if there is a good economic justification. With AAF and MXF that justification comes from the user’s demands — if the market insists on it, the manufacturers will respond.

Interoperability is not usually a manufacturer’s first priority. In fact, some are of the opinion that interoperability has a negative impact on the bottom line. This must be seen as unacceptable to everyone in the production community. AAF and MXF will become widely successful only if all manufacturers develop and maintain honest, compliant and robust implementations. Simply saying “we want it to work better than OMF” is not good enough — specific requirements must be identified and communicated to the manufacturers. To do this, users must inform themselves about AAF and MXF and actively engage in the development process.

The community has a large stake in the successful development of a comprehensive interchange format and can help move the standards to completion. The time is right to encourage system manufacturers to build effective implementations, to influence their decisions about features and to provide support for the completion and maintenance of the AAF and MXF standards.

As AAF and MXF become available, they will help creative people work together, employing the best tools for any particular job. They will also provide the means for streamlining the entire production and post production workflow, managing materials from principle photography through editing and mixing to archiving. These issues will become ever more critical as production and post production continue to move ever deeper into digital territory.

Brooks Harris is the author of EDLMax, an OMF and
EDL management utility (www.edlmax.com).
A member of many standards groups, he was the primary
author of AES31-3, the Audio Decision List protocol and is co-chairman
of the SMPTE working group on timecode.
He can be reached at brooks@edlmax.com