We promise it’s not just alphabet soup.
As we’ve discussed in previous posts on this blog, IMF for Broadcast & Online enables a new generation of workflows for dramatically more efficient creation and distribution of multiple versions of content. It allows us to store, manage, QC and distribute only the elements of audio and video which are unique to each version. But while that’s incredibly helpful, it does create a few new complexities when compared to flat files like AMWA AS-11.
If you create a new version of a programme in your MAM and want to send it to another system or a partner, how do you know which bits of media the recipient already has and which it needs? You could keep track of everything in your MAM, but that’s fragile. Wouldn’t it be nice if multiple systems in the supply chain could communicate using a common method, to locate and retrieve the bits of media they need?
API to the rescue
You’ve probably heard of an Application Programming Interface, or API. It’s a way in which two software applications can communicate. You probably also know that IMF applications do not use filenames to identify assets (such as MXF or XML files). IMF applications use IDs, and the IMF standard SMPTE ST 2067 only maps those IDs to filenames when the assets are delivered.
When IMF assets are at rest, the files can be moved, renamed, put into object storage or otherwise processed, and the ID inside the file remains unchanged despite a potential change in file name or file path.
To locate moveable assets in a large system, you really need a Media Asset Management (MAM) system to handle IMF at scale. The imf-mm-api provides a basic way for an App to ask the MAM questions, such as:
- “What Asset IDs are needed to process Title with ID XXX?”
- “What Asset IDs do you know about?”
- “Where can I find the file with Assets ID YYY?”
- “What is the minimum amount of data I need to send you to deliver package ZZZ?”
The imf-mm-api
The DPP technical team have been supporting the imf-mm-api project for some time. It has been developed by Mr MXF, also known as Bruce Devlin, with partners, including a number of MAM vendors. The project has defined a common API for answering questions like those above.
As the initial phase of the project comes to an end, we’re very excited to announce that the DPP will now take over management of the project. The API definition will be public (like any DPP specification or recommendation), and future development work will be done within the DPP’s technical working groups.
Can I try it out?
Yes! A demo and some information about the API is currently hosted at imf-mm-api.cloud. The hosting of the site and the test resources is generously provided by Amazon Elemental, and the contents of the site were created by the partners of the original project. Test content has been provided by Mr MXF.
What next?
Soon, the API documentation will move to the DPP website. The API definition will be available publicly on Swagger Hub, and a reference implementation (in Node.js) will be made available on GitHub.
In order to allow implementers to deploy the API in their products with confidence that there won’t be version management issues, we’ll have a period of stability for the API . However, we’ll consider future development work that will be driven by business requirements we hear from our members.
Get involved
To get involved, or to learn about the benefits of membership, please contact Rowan.