An IMF compliant file consists of an image track, multiple audio and data tracks, subtitles and captions in text and dynamic metadata in XML
The SMPTE Interoperable Master Format, also known by its abbreviation IMF, has become a buzz word in the industry today. Netflix, Sony Pictures and others have adopted the media exchange format to ensure the highest level of asset compatibility from one organization to its suppliers, clients and outlets. You should be next.
Behind the scenes, these early adopters of the IMF standard have seen a windfall of additional benefits as a standard for the reliable exchange of content is having unexpected impact in library system design, storage and distribution efficiencies and workflow automation. Applying the underlying methodologies inherent in IMF result in greater efficiencies and real, measurable savings for adopters.
The idea for a media exchange format is nothing new—the original SMPTE attempt was begun in the early 2000’s. The Material eXchange Format (MXF) was initially designed to support better interoperability and was designed as a container format for professional digital video and audio media.
The MXF standard was defined as a "container" or "wrapper" which supports a number of different streams of coded "essence," encoded in any of a variety of image and audio compression formats, together with a metadata wrapper which describes the material inside the package. With timecode and metadata support, the MXF standard was intended as a stable distribution method for professional video and audio applications, regardless of the platform.
The MXF design was encompassing and managed to include support for diverse applications such as Long-GOP MPEG-2 material interchange between servers, and carriage of a subset of the Advanced Authoring Format (AAF) data model, under a policy known as the Zero Divergence Directive (ZDD), which enables MXF/AAF workflows between non-linear editing (NLE) systems using AAF and cameras, servers, and diverse devices employing the MXF wrappers.
While the standard was effective at media interchange, by 2005 there were interoperability issues triggered by two key issues: the specifications were too broad in their design so that MXF compliant files were still not necessarily interoperable with other MXF compliant systems that had adopted a different application of the details of the specifications; and different vendors adopted different sub-format versions of the specification to promote their product’s unique selling features that were technically compliant but not interoperable with similar systems from a different vendor. A famous case of these vendor to vendor interoperability problems was the Sony XDCAM and the Panasonic DVCPRO P2, both of which were MXF compliant, yet their files were mutually unintelligible to the other system.
In addition, many of the vendor applications of MXF resulted in separate split files for audio and image and required a special naming convention to link and re-align the media, which caused further interoperability issues when media was distributed. While most of these incompatibility issues were addressed in the 2009 version of the specification which SMPTE ratified, today MXF is primarily used as a reliable container wrapper.
Hollywood, faced with the need to define a digital media specification for reliable cinema distribution, learned from the MXF experience and took steps to constrain the parameters that would make a compliant file and, reined in the feature “one-ups-man-ship” of the vendors in their space to ensure that interoperability was achieved.
MXF is primarily used as a container wrapper, which helps prevent incompatibilities between manufacturers’ gear.
Like MXF a Digital Cinema Package (DCP) is a collection of digital files used to store and distribute audio, image, and data streams for theaters around the globe. The Digital Cinema Initiative adopted a file structure that organized the media into MXF wrapped files, which are separately used to store audio and video streams, and auxiliary data in XML format.
The MXF track files contain image and audio essence compressed and encoded to reduce storage requirements, with an encryption option for security. The image track was compressed using the JPEG2000 codec and the audio is a wrapped 24-bit linear PCM multichannel WAV file. Newer SMPTE standards conform the recommendations among different tool vendors and producers and even require that the legacy DCP standards continue to be supported by DCP players. This control of the standard and the vendors has resulted in reliable interoperability around the world.
IMF took a cue from the DCP committee’s work and constrained the MXF specifications to control the variances between compliant packages. Like DCP, IMF is best described as a collection of assets where each essence is wrapped into an MXF track file. An IMF compliant file consists of an image track, any number of audio tracks, data tracks (Subtitles and captions in IMSC Times Text) and dynamic metadata in human readable XML, because metadata requirements change for different applications.
IMF was developed, in part, to constrain vendors’ ever-present desire to be different from the competition and to help ensure compatibility between systems.
Key IMF terms include the Composition Play List, the CPL, which is a collection of track files referenced via a unique universal identifier (UUID); the Output Profile List (OPL) which is a list of transformations required for a particular business application; and packaging data in XML, including a packing list describing the contents of the CPL, an asset map and volume index. In use, the CPL can actually act like an edit decision list (EDL) employing IMF markers to indicate locations for media splices during playback. The standard has three applications and the most prevalent in use today is the application 2 extended.
There is an effort underway to harmonize the DPP European interoperability specifications with the SMPTE IMF standards which is on target for ratification as a fourth application. Work on this product should be completed by the end of this calendar year, 2018, and will make the IMF methodology a global standard for distribution of interoperable media. And work on the standard continues in committees as well. Currently there are discussions to add a timeline for IMF Markers within the packaging data, and there are discussions as to how to best apply and use the OPL definitions.
From Recipe to Delivery
A fundamental concept in the IMF methodology is how media is to be stored and then assembled for distribution. A good analogy to describe the idea is to compare it to the steps of preparing a meal versus cooking a meal: We store the “ingredients” and the “recipes,” and when we want to eat, we use a recipe to cook the meal. IMF ingredients are all the components that we store, and the recipes are CPL/OPL combinations. This has fundamental impacts to the way we store media.
Most producers and post-production companies make many versions of a single program for distribution purposes. There are hundreds of versions required to support the US VOD requirements and the old method of supporting these distribution requirements was to make an individual copy for each requirement and store it for additional use or archive it. Now the IMF methodology rethinks this paradigm, and companies can now store all the components and logical versions of the required media, and only create the physical version of the media when required for distribution. In this way they are storing the ingredients and recipes, but they only bake a cake when it is to be served. Consultants have measured the impact to storage systems by analyzing the number of versions held on actual systems and discovered that about 25% of storage space can be freed by adopting the IMF methodologies, storing the components and logical CPL/OPL combination “recipes.”
Taking this idea further we can apply it to MAM technology. An end-to-end IMF compliant MAM will:
- Ingest IMF packages (called IMPs) and read the packaging list for CPL information;
- Create assets (a complete collection of associated assets)
- Ingest Supplemental IMPs with new components to associate with main CPLs;
- Preserve the original CPL without media duplication;
- Create new versions (new CPLS) referencing original assets without media duplication;
- Play proxies of “logical” combinations without media duplication;
- Assemble new versions by adding color bars, slates, pre/mid/post-rolls; and
- Not Limited by the original IMF packages received, deliver new packages with any compatible combination of Video (SDR, HDR, HD), Audio Languages, Subtitles, Artwork.
Measured Benefits to MAM
A MAM system with automated distribution based on these IMF methodologies offers measurable savings for producers and post-production facilities managing typical VOD and OTT distribution workflows. SMPTE member Julian Fernandez-Campon presented a paper at the HPA Hollywood Production Alliance 2018 Technical Conference and highlighted the savings to bandwidth, storage and cycle time and it is quite illustrative.
In order to measure the savings, Julian built a typical scenario based on a client operation. This particular client was a producer of television production and cinematic films, and their chief versioning activity was to create a set of up to 30 different versions for distribution to a post-production facility for further enhancement and distribution. The typical scenario had the assumptions outlined in this chart:
Figure 2 and the graph shown in Figure 2A illustrate the measured benefit to storage with IMF. Click to enlarge.
From these figures it is easy to recognize how an end-to-end IMF solution can increase efficiencies while decreasing storage requirements and providing true cost savings.
Jay Batista, general manager, Tedial North America