Has MXF been a bust?
Mar 22, 2010 10:31 AM, By Michael Grotticelli
The goal of truly seamless interoperability among the various vendors was a noble one, but to this day remains somewhat elusive.
There was a time when broadcast and production equipment developed by the various manufacturers in the industry operated completely autonomously from each other’s products, frustrating users who might have to create several versions just to move content from, say, a camera to an edit system, or an edit system to a server.
Recognizing that, with the emergence of IT equipment in broadcast or production facilities something had to be done to efficiently deal with video (and audio) as data files, a group of engineers from several of these same equipment manufacturers got together in the late 1990s within the Pro-MPEG forum to develop what would become the SMPTE-approved Material eXchange Format (MXF) in 2004.
The founding MXF task force was led by Bruce Devlin, then from Snell & Wilcox, and included Oliver Morgan (from MetaGlue), Jim Wilkinson (from Sony) and Bob Edge (Thomson/Grass Valley), who were all faced with similar customer complaints: How to get a Panasonic or Sony camera to talk to a Snell standards converter, or a Grass Valley server to talk to an Avid edit workstation, and so on.
The goal of truly seamless interoperability among the various vendors was a noble one, but to this day remains somewhat elusive. Users continue to be frustrated by incompatible systems that can't read the same files between them. Some professionals take issue with the more than 30 ways that the official spec “allows” users to wrap an audio and video file (and associated metadata), including pages and pages describing 10 different ways to do the same thing.
Editors working on nonlinear systems like those from Avid will get error messages when files stored in MXF wrappers are incompatible, requiring extra transcoding steps and time.
Currently, users often have to transcode the file at each export of a device and at each import using a very low compressed format. That, according to professionals like Dan Grimes, manager of instructional production and engineering at UNLV-TV (the television production department housed within the Hank Greenspun School of Journalism and Media Studies at the University of Nevada Las Vegas), means a whole lot of time, processing cycles and wasted storage.
“When we designed our media production facility just last year, many of the manufacturers used MXF and supported common codecs within them,” Grimes said. “However, after putting the pieces together, we still ran into lots of problems when shifting the media from one program to another. We got some of the manufacturers to sit down together to come up with solutions, but not all issues could be worked out. So even if all entities say they support MXF and common codecs within them, that doesn't mean everything is going to go smoothly. We are still working to get an efficient exchange but at this time we must rely on different wrappers and codecs to exchange the essence between applications, sometimes even between programs provided by the same company.”
So, is it possible that trying to create a universal way of exchanging files is a bit too optimistic for one organization or industry to achieve?
“I don't think so,” said Devlin. “Other, much bigger, industries such as the telecommunications industry achieve better levels of standardization than the broadcast industry does. As a result, the cost of interchange is much lower in that industry, and in return operating costs can be much less. Within the broadcast industry we see a large number of chief engineers in facilities being overworked, not having enough time to follow standards and having to design solutions on the fly. These solutions don't make best use of the standards and as a result continue the ‘special cases’ syndrome that is so prevalent within the industry.”
Devlin, who now works for a Snell spin-off company called AmberFin, said even the best intentions can go awry when so many different applications are being taken into account under a single technical document.
“I have no doubt that [users’ frustrations] aren’t an issue with the technical aspects of the specifications but is an issue with how each software code writer interprets the specification,” Devlin said. “If the specification is not clear and concise enough to convey the specifications and tolerance, it becomes inept.
| Want to use this article? Click here for options! |  |
