IMF - Interoperability and Content Exchange Made Easy

As the television business has become more global, and evolving consumer devices spawn the need for ever more formats, there has been an explosion of the number of versions that are needed for an item of content. The need to provide tens to hundreds of language versions provides added complications, with localized versions often being created at dispersed dubbing and captioning facilities. The Interoperable Media Format (IMF) has been developed as the solution to the sensible processing of motion pictures and episodic shows. In the linked e-book, Rohde & Schwarz explain IMF and introduce Clipster as a platform for IMF workflows.

In the past content versioning has been fulfilled through a mix of videotapes: HDCAM-SR, HD-D5 and Betacam, along with 8-tracks audio tapes. File-based operations promise a more manageable solution, but it quickly became evident that the complexity of managing a few hundred versions needed some serious standardization. The early days of MXF were remembered as a standard that was too flexible but stands as a good starting point.

The motion picture industry understood how the standards had to be nailed down, yet retaining the flexibility for new codecs, new video formats. They needed a master file that could wrap all the variants of a program to create a single master. The many versions can then be created from that single master.

Broadcasters and vendors also saw the advantages of IMF, and together the three parties have worked with the SMPTE to standardize IMF (SMPTE ST-2067 group).

World-wide distribution not only entails more audio tracks—a lot more—but captions and subtitles in the local languages. This also applies to title and credit sequences.

There are also the many edits that may be needed: TV censor edits to meet local legislation, airline versions, different segmentation for different markets. A single IMF container can wrap all the necessary assets to create any number of versions.

A specific version of content from an IMF file is defined using a Composition PlayList (CPL). This defines the audio and metadata files to use,l and defines any edits or substitutions to the original video track.

A separate Output Profile List (OPL) then defines the formats—codecs, aspect ratio, audio formats—as required for the target consumer device.

In an IMF workflow, a master video track is stored, and any version, like foreign languages titles, can be stored as stubs. Similarly, the different language audio tracks and captions are stored as linked files. A specific CPL draws together all the necessary assets to assemble the required version.

This file-based approach has many advantages. Consider a program released for the US market in English and Spanish. The program is later sold to Brazil. The Portuguese soundtrack, title and credit asset are added to the IMF container, and a new CPL created for the Brazilian version. Everything is synchronized by time code. There is a single global master that adapts to the requirements of international distribution.

The end-result of the long road of standardization is a truly interoperable standard that enables, rather than constrains, versioning. IMF is a master for the any market, any device world.

This e-book, sponsored by Rohde & Schwarz, examines the latest changes to the standards and sheds light on its application in a range of scenarios from cinema to broadcast TV and OTT applications.

Supported by

You might also like...

Designing IP Broadcast Systems - The Book

Designing IP Broadcast Systems is another massive body of research driven work - with over 27,000 words in 18 articles, in a free 84 page eBook. It provides extensive insight into the technology and engineering methodology required to create practical IP based broadcast…

Demands On Production With HDR & WCG

The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.

If It Ain’t Broke Still Fix It: Part 2 - Security

The old broadcasting adage: ‘if it ain’t broke don’t fix it’ is no longer relevant and potentially highly dangerous, especially when we consider the security implications of not updating software and operating systems.

Standards: Part 21 - The MPEG, AES & Other Containers

Here we discuss how raw essence data needs to be serialized so it can be stored in media container files. We also describe the various media container file formats and their evolution.

NDI For Broadcast: Part 3 – Bridging The Gap

This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…