11 YOUR TAKE Adopting IMF
workflow is immense. But you need to be bold to blaze that trail right now, because there are challenges in getting all the right components into one package. PARTS IS PARTS The hardest part of adopting IMF is working out how to break down a single piece of content into all its relevant parts. This can have far-reaching business implications. For example, rather than building one complete edited master, you end up with multiple segments of masters. There might be different opening or closing credits for different language regions. Or there could be different graphical elements for different versions. Normally, these would be added to an edit master for each regional deliverable. But with IMF, as daunting as it may seem, these elements are just added to the inventory for the master bundle. One of the biggest challenges is IMF versioning. Take multi-language delivery, 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, while the others are still works in progress. When the French and Spanish audio tracks and graphics inserts are ready, do you create another IMF package for each one? That would defeat the object of IMF in the first place. In fact, the IMF standard supports the update process for the XML files that describe a bundle, and there is also work going on across the
WHEN YOU LOOK AT AN IMF PACKAGE IN FINDER OR EXPLORER, NOT A SINGLE FILE NAME IS HUMAN-READABLE, WHICH FORMANYMAKES IT ALMOST INCOMPREHENSIBLE
industry to make this kind of problem much easier to solve. REDUCING COMPLEXITY Perhaps the biggest problem is keeping track of all these bits within a bundle. The next evolution of tools needs 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 the content started out on a timeline (albeit in an NLE) and there is metadata within an IMF bundle that describes that same timeline or timeline(s) for multiple versions of the 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 the J2K codec, which makes adoption considerably easier for many. This type of ‘tweaking’ to fine tune the broader specification for certain applications is likely to become much more commonplace. IMF is still evolving, and evolving into areas of the industry that have a real business need. As it does, new technology and easier tools will come along.
feedzine feed.zine feedmagazine.tv
Powered by FlippingBook