IMF Adoption

The Interoperable Master Format isn't new. It's been around for more than six years. Despite this longevity, the broad adoption since the publication of SMPTE 2067 has been pretty slow. This is perhaps more because of the age old mantra "if it ain’t broke don’t fix it", than the ease with which many could interpret the standard. However, it is safe to say that movie producers blazed a trail in using IMF for original content delivery. Perhaps the key is that those early adopters didn’t have any significant tape based infrastructure that had been modified for file-based working when receiving content. So, many longer established content distributors have the immense resources to create the vast array of versions required to address the 'version issue'. This being how do you get the same content to look good on the back of an aeroplane seat headrest or an iPhone in the back of car as well as a good old TV set. Over time these resources have been diminishing and many organisations recognise that they have to adopt workflow automation to survive.

The potential for IMF to facilitate automation at the same time as addressing the versioning problem within almost any workflow is immense. However, it would appear that you need to be bold in blazing that trail right now. This is because of the challenges of getting all the right components into one package. The hardest part in adopting IMF is working out how to break down a single program into its relevant parts. This can have far reaching business implications. For example, rather than building a complete edited master you end up with multiple segments of masters. There could be different opening or closing credits for different language regions. There could be different graphical elements. Normally these would just be added to the edit master for each regional deliverable. However with IMF, as daunting as it may seem, these elements are added to the inventory for the master bundle. Perhaps one of the biggest challenges is that of IMF versioning. Take multi language deliverer for example. You may start with the English version but have a contract to deliver Spanish and French versions as well. The deadline for the English version is sooner than the others. So you deliver an IMF bundle with just the English components needed, the others being work in progress. When the French and Spanish audio tracks and graphics inserts are ready what do you do create another IMF package for each? Does that defeat the object of IMF in the first place? Yes it does, but help is at hand. Not only does the IMF standard support the update process for the XML files that describe a bundle but there is work going on across the industry to make this kind of problem much easier to solve.

Perhaps the biggest problem is keeping track of all these bits within a bundle. The next evolution of tools has to present this information to the user in an easy way. This abstraction is vital to the overall broader adoption of IMF. When you look at an IMF package in Finder or Explorer, not a single file name is human readable which for many makes it almost incomprehensible. It's safe to say that the content started out on a timeline (albeit in and NLE) and there is even metadata within an IMF bundle that describes that same timeline or timeline(s) for different versions of the same content. So there is plenty of information that software tools can use just to represent the timeline(s) of a package in a user friendly way. The lack of cost effective tools that facilitate this simple level of understanding is an obstacle to the broader adoption of IMF. We as vendors have a duty to make solutions that are robust and easy to use as workflows and content get more complex.

No vendor should be working in a vacuum though and, with organisations like the Digital Production Partnership (DPP) and the North American Broadcasters Association (NABA) putting their weight behind specific implementations of the IMF standard, things are becoming clearer. Like many industry standards, the original IMF specification is open to interpretation and offers a vast array of implementations. Now there is a slightly more constrained IMF delivery format aimed specifically at broadcast and online content. With this Application of SMPTE 2067 the codec is ProRes as opposed to J2k which makes adoption considerably easier for many. This type of ‘tweaking’ to fine tune the broader specification for certain applications is likely to become more commonplace.

As can be seen, IMF is still evolving and it is evolving into areas of the industry that have a real business need and as it does, new technology and easier tools will come along.

By Howard Twine, Director of Software Strategy at EditShare