Shown here is OpenCube’s MXF toolkit and file reader.
Final tweaks
During NAB2005, one of my colleagues spent an afternoon walking the floor with a USB stick on which several MXF files were stored. He went from exhibit to exhibit, trying out the files on gear from various manufacturers in a rather informal test of interoperability. With stops including MOG Solutions, Open Cube, Sony and several others, the news that came back was encouraging. The MXF files (which were created using the Snell & Wilcox MXF Desktop tools) interoperated more or less perfectly, delivering synchronized audio and video with seamless interchange of descriptive metadata. Only a few bits here and there needed changing.
While it might be premature to hoist a “mission accomplished” banner for MXF interoperability, in the past several months, we've come much closer to making this a reality. The greater part of the work has been done, and the issues facing us now are more on the level of details — important details to be sure, but ones that we can be confident of solving relatively quickly.
For example, the SMPTE MXF working group has identified some issues with several noninteroperable broadcast WAV file formats. This created problems with maintaining metadata through various file-based workflows. For example, consider a workflow that starts with a broadcast WAV created in Japan and ends with a broadcast WAV created in the U.S. In the middle of the process, the material exists as an MXF file. Although the audio essence isn't affected, the issue becomes maintaining metadata integrity written in Kanji characters for the original file not being lost by the time the MXF file was unwrapped in the U.S.
The resolution to this issue came in several parts. One part was to recognize that it's the job of MXF to carry metadata but not to translate it from one language to another. Having agreed on this point, we could now define the goal: to ensure that metadata applied to a WAV file in Japanese would still be readable in Japanese when the file was unwrapped to a broadcast WAV file in the United States and vice versa.
Figure 1. Basic structure of an MXF file. Click here to see an enlarged diagram.
The solution was to ensure that any metadata that is expressed in a character set (such as Kanji) is mapped to Unicode as part of the MXF wrapping process (as shown in Figure 1), and then mapped back again when the file is unwrapped. A roundtrip mechanism has thus been defined, and this means that no information is lost at any stage in the process. Of course, if you want to read metadata that was originally written in Kanji, there's no substitute for some reading knowledge of Japanese. Fortunately, however, much metadata can be expressed solely with numbers. No text is required to express peak audio level, for example. When working with metadata, some things are language-oriented, and some things aren't.
Another sign of MXF's maturity is the growing activity in the development of application specifications. If you think of MXF as a large tool box, then it's possible to define certain standard operational patterns to simplify what MXF applications should do.
Writing MXF applications
For example, a facility might want to standardize on DV-based essence or a certain metadata vocabulary that is key for the types of content it is working with. Application specifications are a way of codifying these preferences, which then will promote efficiency within the facility by restricting the number of day-to-day choices that are presented to operators. At the edges of a facility, a station might want to be to be able to ingest almost any format. However, when passing media files around within a facility, it's more efficient to rely on a standard working practice, such as making all files SD or MPEG-2.
Therefore, many facilities are creating MXF application specifications that set internal working practices for things like timecode. Once these choices have been documented, engineers are better able to determine the kind of equipment that will be needed to ensure that files remain consistent.
New training tools
Writing MXF specifications is relatively simple. Because MXF itself is a specification, users can simply write down what is wanted with the timecode or the essence. The hard and soft parameters within the specification make this easy task. Application specifications are obliged to include all the normative parts of MXF, but users have flexibility in defining how optional parameters are used and how essence choices are made.
MXFixer from Metaglue is a tool that allows users to connect MXF-based media systems with AAF-based post-production systems and XML-based business and media systems.
Of course, some broadcasters are still wondering why this step is needed at all. In a perfect world, where every vendor implemented every type of essence, you wouldn't need application specifications at all. However, our world is somewhat less than perfect, so the end user community needs to make some educated decisions that are constrained by the realities of the equipment you can buy today.
Another trend was evident at this year's NAB. It was the desire on the part of the broadcasting and facilities community for training. Facilities want their staffs to have the education and training that will help them make the best choices they'll face in the future.
NAB MXF panels
Snell & Wilcox has developed a training tool in the form of a new DVD, called MXF Explained. The DVD is available free through the company's Web site. The goal of MXF Explained is to improve the level of education and knowledge regarding MXF and to help broadcasters get a fuller understanding of why this open-standards file solution is such an important part of the transition to tapeless, IT-based, open-standards environments. In a product-neutral way, the DVD delves into the details of how MXF works, what comprises an application specification and how to use MXF in a system. Also covered are the down-loadable toolsets and a preview of other MXF development tools: MXF Express and MXF Desktop. These too are available free from Snell & Wilcox.
Since their release last year, these tools have become a benchmark against which others can test the interoperability of their code. We've seen evidence that people are testing their interoperability against this toolkit whether they are already using our tools, have bought an MXF solution from another company, or are writing their own implementations. By providing a common code base to test against, we believe that Snell & Wilcox has helped to significantly reduce the time it would have otherwise taken for the standard to be adopted.
Another kind of MXF education took place at NAB in the form of panel discussions over the NAB-HD model HDTV station that broadcast during the convention. Panelists for “Achieving Interoperability in an IT-Based Broadcast Facility” included Brad Gilmer of the AAF Association, Paul Cheesbrough of the BBC, Adolfo Rodriguez of Omneon Video Networks, Michael Day of Premier Media Group, Clyde Smith of Turner Broadcasting and myself.
Turner is well-known as an early adopter of the open-standards, IT-based facility concept. During the NAB-HD panel, Smith reported that MXF is becoming an increasing presence in Turner's workflows. As Turner purchases new gear, he said, the objective is to look for open standards as much as possible and thus be able to put together best-of-breed solutions.
The news from other panelists regarding interoperability issues was also encouraging. Michael Day reported that Fox Sports Australia is up and running using MXF, and the main issues have been with bits of the specification, such as VBI and closed captioning, that are still in the process of being finalized by SMPTE.
The Fox Sports Australia installation is also an example of the bilateral interoperability being seeing this year and which promises to expand into multilateral interoperability as more MXF-enabled products become available.
Another proactive approach to implementation is being taken by the EBU, which has organized a series of MXF tests between different vendors to check the level of interoperability between vendors. The EBU will then develop a matrix showing who works with whom and identify problem areas that need to be addressed. The tests are scheduled to take place at the end of July in Munich at the Institut für Rundfunktechnik (IRT). The IRT has developed its own online MXF test center (www.irt.de/mxf), which provides tools to help users with MXF implementation and verification, a a portal for securely submitting files to IRT for compliance testing, a repository of “golden” and “pathological” MXF files to test MXF decoders, and forms to ask for more information and to arrange tests.
Another important development is the establishment by SMPTE of an MXF Working Group, which has its own Web site at (www.smpte-mxf.org). The working group is a forum where users and vendors can discuss MXF system and equipment issues. To join in this particular working group, you have to be a SMPTE member. Even if you're not a SMPTE member, you can pose a question to the working group and have them work on an answer.
The Advanced Authoring Format (AAF) Association provides another opportunity for users to get involved in the evolution of MXF. It has a working group that's actively implementing the zero divergence doctrine (ZDD), which ensures no divergence between AAF and MXF systems and thus full system interoperability regardless of image resolution or compression type.
The Snell & Wilcox MXF Web site forum (www.snellwilcox.com/mxf), has more than 1300 users of the free MXF Express and MXF Desktop tools. A new version that improves the usability and visualization of MXF files will be released this month.
Last year, MXF was integrated into the Windows desktop. But, we've found that users sometimes want to look closer at the files to see exactly what's inside. MXF Desktop, which will be updated to version 1.4 later this year, will have added visualization tools so users can look inside to see how files were assembled.
The needed software tools to permit these features also will be added to the MXF Express toolkit. This will allow developers to implement the same visualization tools into their own applications. This functionality will be provided as DLL or ActiveX components. If developers want to include that same visualization in their code, they will not have to rewrite any code. Simply rely on the provided DLLs and ActiveX controls. In addition, the new version of MXF Express will also include many updates for equipment interoperability between vendors.
It's striking to look at the participants on the MXF forum and see that they include all the big names you might expect — broadcasters, motion picture studios, cable and satellite operators, telecom, equipment manufacturers, and active developers. These professionals realize the crucial role that MXF is going to play in developing cost-effective, open-standards IT solutions that will help users avoid going down a proprietary technology cul-de-sac. Just as important, these forum members are from all around the globe, which means that MXF has penetrated throughout the whole of the industry. That is good for all of us.
Bruce Devlin is vice president technology for Snell & Wilcox.
