(click thumbnail)Fig. 1: The content model composed of content packages is made up of content items, which contain content elements made up of essence components.The material interchange of moving media can be accomplished by different means. A tape or disc may be used as a physical transport, with its content comprised of essence in the form of a compressed file, a contiguous interleaved video sequence (i.e., a videotape), or a string of individual files (i.e., JPEG images) that when ordered properly for reproduction, make up a video clip.
Just as common in today’s networking environment are file and stream transfers. In terms of workflow, incoming streams are often captured by a recording medium and turned into a set of files, which are then converted back into a stream for transmission or distribution. It is the structure of the files and the streams themselves that lead to the interoperability issues that have instigated, in part, the development of the Material eXchange Format, or MXF.
Understanding why MXF is what it is requires knowing the concepts of wrappers and content packages, items and elements. In the simplest of terms, a wrapper is like an envelope—somewhat closely aligned to a packet in the IT-sense, but that’s where the similarity ends. A wrapper must have organization characteristics. It needs to convey, and link essence and its associated metadata.
Before climbing under the hood of MXF, first recall that essence components may be video, audio or other data. The organization of all these essence components is supported at its highest level by the wrapper. In the content model, content is comprised of content packages, which are a collection of content items.
Content items are made up of content elements, each of which contains a grouping of similar element types of essence. Note that each set of essence components needs some vital metadata—the bits that describe the essence type, as a recordkeeper of what the structure is inside the content element.
MXF employs a generic container, a slightly different twist on the content model that defines frame-interleaved content comprised of system items, picture items, sound items, data items and compound items.
The twist allowed the inclusion of multimedia-related items, mitigating the need to differentiate between moving elements (video), audible sound elements (synthesized audio or MIDI), and generally static elements (still graphics or text) as well as data items (teletext or closed-caption files). So the MXF concept broadened the coverage immensely, taking a step well outside the confines of other content package specifications, most notably, SDTI-CP (SMPTE 326M).
SDTI-CP is the format for the transport of content packages (CP) on the serial digital transport interface (SDTI). It consists of a group of timing and control elements, plus any metadata associated with the picture, audio, and auxiliary data items.
It includes a picture item, assembled as a group of up to 255 picture stream elements; an audio item, assembled as a group of up to 255 audio stream elements; and an auxiliary item assembled as a group of up to 255 auxiliary data elements such as ancillary data lines, teletext, and other data.
The MXF Generic Container is a native essence container capable of being continuously decoded through mechanisms such as interleaving essence components with stream-based metadata. The container allows essence to be wrapped in key-length-value encoding and to optionally associate an index table that permits multiplexing with other essence containers. In turn, this allows the setting of decoder requirements for listening, play-out, display or execution of a command for that content.
Key-length-value, described in SMPTE 336M as “KLV encoding,” is a triplet employed as a data interchange protocol for data items whereby the key field identifies the data, the length field specifies the length of that data, and the value field is the data itself (sometimes called the payload).
KLV provides a common interchange for all compliant applications irrespective of the implementation or transport method. The key in this protocol is a 16-byte SMPTE universal label per SMPTE 298M that identifies the data in the value field.
The length field uses basic encoding rules/length encoding, from a type of ASN.1 coding, but with a variable length. Basic encoding rules comprises a standard language used to code protocols, which furthermore is the transfer syntax for simple network management protocol, and lightweight directory access protocol, an application protocol for querying and modifying directory services running over TCP/IP.
KLV is that methodology by which the data strings in MXF are parsed into their proper buckets. All system elements, essence elements, and the like, are KLV-coded.
While the topic of KLV is well under the hood of MXF, and there are hundreds of additional structures of data inside MXF; it is with these principles that the elements associated with MXF are based.
The point to realize is that MXF uses many established principles and protocols of networking, encoding and the like. It grew as a means to satisfy media exchanges and interoperability at an equalized level—not unlike how nearly everyone can surf the Web without worrying about myriad protocols, interconnections, routing, etc.
We started this column establishing that file transfers and streaming delivery are fundamentally different—yet collecting, storing and retrieval for distribution must move seamlessly between transfer and streaming. It is precisely here that we must recognize the necessity of a common architecture for interchange.
After about 10 years of work on interchange/interoperability, we still find substantial differences in how systems (and products) interpret MXF. While they all may understandably and correctly state “MXF-compliant”—the industry, which seems to gain the most from a proper exchange is still trying to use this boat with a very short rudder.
Most recently, a collection of industry giants (and real users, too) have set out to establish a model for baseline utilization, and in turn, conformance in MXF. This is not, by any means, a new standard or a new version of MXF, it is an implementation, dubbed the “MXF Mastering Format Project.”
For the past several months, this group, in alliance with members of the Advanced Media Workflow Association, has been putting AAF and MXF to work.
At NAB2007, the AMWA sponsored the first public demonstration of this long-term initiative, which is being led by Turner Broadcasting System. The mission of this project is to bring a fresh approach to MXF and to provide proposed, real-world solutions for key workflows, focusing on creating a single MXF master file from which multiple versions of a program may be created.
