Acronyms are something most industries readily generate, and broadcasting is no exception. The latest addition is one you heard a lot about at this year's NAB: MXF.
The Material eXchange Format, as it's officially known, represents a next-generation standard for transporting video as files through an IT broadcast infrastructure.
For example, MXF allows a video server from one manufacturer to communicate with another's so that broadcasters can transfer digital files back and forth across a common network without having to transcode them. Transcoding can degrade video images and should be avoided when possible.
The MXF format is built upon the Advanced Authoring Format (AAF). MXF uses the same underlying object model that AAF uses to represent time, structural metadata, time code and any other program-descriptor data, as shown in Figure 1. AAF is optimized for the post-production industry, where complex projects are interchanged among editing, coloring and CGI stations. MXF is a flattened version of AAF, designed to move content between different servers for ingest, playout, nonlinear editing and graphics production. This simplified version of AAF was created to ease implementation of features such as streaming (e.g., for VTRs) and partial-restore functions.
 Figure 1. The “played” output and the stored content are related by the edit-decision list (EDL) stored within the file. Click here to see an enlarged diagram. |
The Snell & Wilcox Software Development Kit (SDK) can help vendors (and users) better understand and implement MXF code. MXF Desktop is an application program that installs and integrates itself with Microsoft Windows Explorer. Double-clicking on an MXF file launches Windows Explorer and plays the file. MXF Desktop provides all the needed MXF support, including parsing the header metadata and retrieving the underlying essence. It then finds a codec on the computer for MPEG or DV (depending on what was wrapped in the file) and plays the picture. Right-clicking on an MXF file displays the file's MXF properties, as shown in Figure 2. The software reads the MXF header metadata, parses it and then presents it in a simple “Tabbed Properties” box so that the user can see who made the file, what underlying essence (e.g., MPEG or DV) is in the file, and important properties of the files. Such properties include the number of pixels and lines in the image, the duration of the file and the presence of other rich metadata.
Programmers and equipment vendors will likely want to write their own software to give MXF awareness to their specific products and applications. MXF Express will be available as C++ libraries and also as Microsoft Directshow filters to help them do this. The interfaces to the libraries are straightforward and can be as simple as “Write this essence stream to disk wrapped in MXF” or “Read this MXF file and get the essence stream.” You can create more complex software by diving into the API calls to read and write your own metadata so that the MXF file-creation information has the correct company name and product version.
Operational Pattern (OP) support in the SDK reflects the current practice in MXF implementations. OP1a and OP-Atom are the two most popular constraints on the MXF specification. Essentially, they allow creation of a tape-replacement version of MXF and a mono-essence tape-replacement version of MXF. Such features greatly simplify MXF file creation for environments such as videotape where strict limits on essence alignment and partition sizes exist.
The free SDK will help determine how broadcasters can use metadata in daily production processes and provide some visibility of that metadata. But there are still open questions about the complete interoperability of metadata within the industry. The SDK provides easy visibility into that metadata and a better understanding of how it works. For example, a simple MXF file can have many kilobytes of metadata included in it. With the SDK, the engineer can automatically access that metadata and convert it for other uses.
Common standards benefit everyone. Consider the BNC connector. It's in no one's interest to have an incompatible BNC connector. Users just need to get signals into and out of equipment as quickly and easily as possible. Think of an MXF file as a BNC connector for the IT world — everyone needs to use the same flavor of it.
The goal is to jumpstart the industry's acceptance of MXF and all that it can offer. To that end, Snell & Wilcox hopes that the release of the free MXF Express SDK and MXF Desktop will foster adoption of a single, common MXF specification, and help all stations make a smooth transition to digital. The MXF ExpressDesktop software is available at www.snellwilcox.com.
Bruce Devlin is the principal research and innovations engineer at Snell & Wilcox.
In an effort to help MXF quickly become a standardized protocol throughout the industry, Snell & Wilcox has decided to make its MXF Express Software Development Kit (SDK) and MXF Desktop player, inspector and wrapper — used for creating and storing files wrapped in an MXF bucket — available at no cost to the broadcast and manufacturing communities. This has caused concern among some of the companies involved in helping to develop the format, but Snell & Wilcox's intent is altruistic. The company is not looking to gain from the SDK, although it would be possible for them to charge for it. The idea is to ensure that MXF is universally supported across the full range of broadcast equipment as soon as possible.
When MPEG-2 was first announced, everyone saw its potential and quickly announced their support. Unfortunately, several different implementations of MPEG-2 emerged, and it caused many interoperability problems. An MPEG-2 file created with one manufacturer's device sometimes could not be recognized by another manufacturer's equipment. This incompatibility set the industry back about 18 months. The compression format only became universal after SMPTE, ISOG, ATSC, DVB and other groups got involved to help implement a single version.
There is a danger that the industry could experience the same thing with MXF, and this is the reason the company is releasing the SDK libraries and tools (but not the source code) for free. The sooner everyone begins using a reference implementation of the original spec — as it's been proposed and standardized by SMPTE — the sooner MXF will be adopted and appear in readily available products. Only then will broadcasters achieve true interoperability between two different servers or edit systems, for example. Frustrated with the problems that different file formats cause, many broadcasters have told the company that, as of this NAB, they will not buy equipment that does not support MXF.
MXF Express will also help vendors, especially small ones, get into MXF without having to put hundreds of man-hours of time into understanding the specification (MXF is over 480 pages long). Snell & Wilcox has done that hard research, and it doesn't want others to have to endure the same thing.