MXF interchange: A progress report

By
published


Figure 1. MXF file construction. Click here to see an enlarged diagram.

MXF, the Material eXchange Format, is the industry's open file interchange format designed to improve interoperability between servers, NLEs and other devices that create and receive content. Developed under the Pro-MPEG Forum's leadership, the goal of MXF has been to create a professional and ubiquitous file format that optimizes workflows — given the complex mix of standard and proprietary file formats in use today. Because MXF files consist of both essence and metadata, the journey from content to an MXF file is highly complex, as illustrated in Figure 1, and the process must be reversed at the receiving device.

From promise to standard


An operator uses MXF-compliant equipment to transfer stored and live production files to a Leitch NEXIO server for playout. Photo courtesy Touring Video.

More than a year has passed since the official launch of MXF at NAB2004, and more than seven years have passed since actual work began. The scope of work remaining to be done in order to implement this complex standard is now becoming clear. Many manufacturers are just beginning to tackle the inter-vendor issues that will take MXF out of the laboratory, while other manufacturers' products, such as Sony's XDCAM and Panasonic's P2, are embracing the standard in acquisition products. Simultaneously, customers are beginning to understand the metadata and essence handling stages required for their MXF-centric workflows.

At this point, the adage “80 percent done, 80 percent to go” is underscored by the transition from a complete MXF specification to a usable standard in real-world production. Over the next year, one would expect to see islands of MXF interoperability slowly expand — and eventually form the infrastructure of universal file interchange as promised. Table 1 (on page 64) outlines accepted and pending SMPTE standards, and underscores the “80 percent to go” adage.

The implementation challenge

In development, the phrase “doesn't work until tested” truly applies when it comes to ensuring compatibility to a standard versus a device under test. In reality, a complex standard can't be considered complete until implementation work has proven its functionality.

In the real world, this leads from islands of interoperability to a growing web of compatible products. Customers must be careful in assuming that because A works with B and B works with C, then A will work with C.

Customer requirements will drive the standard's development, more so for compatibility between products within a competitive space. Manufacturers tend to develop compatibility with complementary products, and often, inter-vendor compatibility will be placed on the back burner until a specific customer opportunity forces the issue.


Table 1. Accepted and pending SMPTE MXF standard. Click here to see an enlarged diagram.

MXF is a hierarchical or layered standard, designed to support media of varying underlying complexity. Audio and video content (or essence) can be stored in multiple file packages (FP) within a single MXF file. The MXF file's operational pattern (OP) determines how the underlying file packages are put together to form the material package (MP). The MP represents the playback of the file contents. Figure 2 illustrates a variety of MXF OPs and the allocations of FPs and MPs.

Within each file package, audio and video data can be interleaved, partitioned and indexed. Parameters for each of these operations can vary independently and need to be supported.

Further variety is created by the concept of OP Atom, as used in Panasonic's P2 format. OP Atom MXF files contain only separate audio or video essence and need to be associated and synchronized external to the MFX file structure itself.

Achieving MXF interchange that allows the recognition of media is only the first step.

MXF and essence


Figure 2. MXF operational patterns. The hash lines indicate source media within the file package, whereas the unshaded bars show the playback media represented by the material package. In OP1 and OP2 since all source media is included in the material package, there is a 1:1 correspondence. In the more advanced OPs, the material packaged is a subset of the source (file packages). Click here to see an enlarged diagram.

MXF does not ensure compatibility of video and audio essence — specifically, compressed essence types that require supporting codecs. As we move from hardware codecs to more flexible software codecs, the likelihood of essence compatibility increases, but even in situations where compliance has been tested, compatibility is not ensured.

From a customer standpoint, aside from MXF file compatibility, questions requiring answers abound. Is it MPEG? Are the profiles and levels supported? What is the GOP, raster size and frame rate? Is your file compatible with my device, given a particular set of criteria? Compressed audio increases complexity and further complicates timing-related concerns.

Compatibility of traditional vertical blanking data (VBI), as well as horizontal ancillary (Hanc) and vertical ancillary (Vanc) information is still being standardized within MXF — almost as an afterthought. It was envisioned that support requirements for legacy metadata, such as VBI, would fade away as this data moved to the provisioned metadata space within the MXF file structure. Again, reality meets theory — and reality prevails. Vendors are scrambling to address the issue of bundling up the entire VBI space and storing it as datablock within the MXF file.

In IMX, Sony addressed the issue of vertical blanking information by extending the active picture height (SMPTE RP202 MLMP 23f1-262 f2) of the MPEG encoded video to include the VBI in the compressed essence data. While this further violates the philosophy of separation of essence and metadata and introduces yet another variable, it does enable support for legacy VBI.

Metadata creation and data handling

MXF metadata consists of labels (keys) and values. Label sets and value units are defined in metadata dictionaries and registries, such as SMPTE RP210 and RP224; unregistered metadata labels are considered dark and potentially problematic.

The science of data handling is well-developed, and its relationship to computer-driven processes, such as searching and sorting, has been established in database programming languages. By considering all the metadata within an MXF file to be analogous to a database row, each label a column and each value a cell, rules and practices followed by database administrators are equally applicable to MXF metadata. Understanding concepts of data normalization, such as ensuring that each label can mean only one thing and contain only one value, are essential to successful implementation.

From standardized formats for date and time to actual metadata dictionaries, common sense data handling rules apply. Defining minimal and constrained metadata sets works best — too much unstructured data reduces efficiency. By automating metadata creation, efficiency can be improved, and where people are required, applications can provide template-driven interfaces and thus lower error rates.

MXF metadata also lends itself well to XML representation, and SMPTE is in the process of defining a schema for its standardization. A small XML file containing just the metadata from an MXF media file will simplify many automated applications that have no need for essence.

MXF in a facility's workflow

With this background, how should a facility manager begin MXF implementation? Because considerable work remains to be done with the standard, it may be difficult to predict exactly what functionality and features might exist in a final version. Even so, that should not prevent one from taking advantage of its benefits today. The following points highlight steps that can be taken to help ensure success with an MXF installation:

  • Using unique material identifiers (UMIDs) or globally unique identifiers (GUIDs) creates a unique set of naming conventions at your facility, regardless of the data set you wish to track. Often, as is the case with a placeholder in a MOS rundown, the name is created before the media exists. Ensuring uniqueness in asset naming is essential to all subsequent operations.
  • Identify which portions of your workflows an MXF file transfer can replace. Any operation that can be replaced by a file transfer bypasses generational losses and can be faster than real time. Other benefits depend on the task. For example, a file transfer directly from camera to NLE may ease logging and project organization, while MXF transfers to data archives can preserve accessibility.
  • Select the metadata that you wish to track initially, such as time-code, date and time, shooter and acquisition device. As you refine the workflow, add additional (more comprehensive) sets, such as the media status within the workflow (e.g., original, edit, master) and a project linkage. Keep in mind what other non-direct media handling applications need to access metadata items. This could include playout automation, traffic and asset management. Be sure communication mechanisms are in place to handle this task.
  • Identify points at which metadata can be added automatically or via templates. Examples include time and GPS location at the point of acquisition or user name via a media ingest program. Simply automatically adding a metadata item to track the device name (MAC address) that the file came from can provide value in future operations or troubleshooting. Avoid manual data entry wherever possible, as typos or failures to obey a naming convention can introduce errors and burden a search engine. Templates expedite data entry, ensure uniformity and remove error sources.
  • Because the delivered product is not likely to be an MXF file, with knowledge of the capabilities of digital receivers, determine the metadata that you want to preserve through playout or delivery ultimately to the viewer. Metadata from earlier points in a workflow can trigger branding and graphic insertion, facilitate content protection and rights management or enable automatically embedded advertising links.

Conclusion

Given that partial MXF implementation is at hand, and full implementation among manufacturers is realistic towards the end of 2006, valuable decisions can be made at this point regarding workflows, metadata and the desired level of MXF implementation at your facility. Once you decide to implement MXF and the proper manufacturers are identified, your workflow must be modified accordingly to take advantage of vendor capabilities and limitations. With proper diligence, systematic understanding and documented requirements, an optimized workflow between ingest and storage, production and editing, as well as improved search capabilities, rights management and media tracking, can be realized.

Todd Roth is vice president of technology at Leitch Technology.

Additional resources

There are several professional organizations that help to foster an implementation-friendly environment:

Todd Roth