How the IMF Delivery Schema could transform your workflows

On 26th February the IMF User Group launched v1.0 of the IMF Delivery Schema. We’ve supported the development of this project, along with DPP members, and we believe it will become an important building block in future IMF workflows. Here’s an overview of the Delivery Schema, and what it could mean for your workflows.

What does it do?

IMF Packages come in a large variety of flavours - even in the DPP’s TSP 2121-1 there are 8 permitted frame rates, and 3 types of dynamic range, for example. Application 2e (SMPTE ST 2067-21) meanwhile provides for more than 12 million different pixel rasters! With similar flexibility in audio and metadata arrangements, a challenge awaits any content provider who receives an IMF package:

How can we tell whether a package is right for us?

This is not a question of conformance to standards - a package can be completely compliant with standards and still be wildly different from what we expected to receive. In order to accept a delivery, we would like to have confirmation of not just technical compliance, but also whether the delivery conforms to our expectations.

We could write a document describing our expectations, and pay someone to tick off each parameter when receiving an incoming package. Or… we could hand this task to our AQC tool! But how does the AQC tool know what package we’re expecting? In essence, this is the purpose of the IMF Delivery Schema.

Two DPP member companies have already produced prototypes demonstrating the capability of their AQC tools to load an instance of the IMF Delivery Schema and validate incoming packages against it. If an organisation receiving IMF content places this check as the first step in their processing chain, then no further resources need be wasted on a package that does not conform to their requirements.

But the schema is not constrained to the end of the supply chain. A commissioning organisation can define their delivery requirements using the Delivery Schema, and attach it to the commissioning paperwork. The producer can then load this into their mastering systems, to automatically set many of the parameters for when the package is created.

How does it work?

Let’s take a very brief look at the actual mechanics of the IMF Delivery Schema.

The schema is formatted as a hierarchical XML structure which describes an IMF delivery precisely and unambiguously. Groups of options are available so, for example, a delivery could be required to come in “either 25 or 50 fps” or as “HDR only please, but PQ and HLG are both fine”.

Of course, most humans should never need to look at the XML, let alone write it themselves! After all, a Composition Play List (CPL) is an XML document and, even though I personally have written a few in the DPP Test Lab, most users should never have to do that! There are great tools for mastering IMF CPLs, and in the same way, tools are being developed to create your Delivery Schema.

Crucially, this XML document becomes the starting point not just for machine-readable instructions, but also for any human-readable output. With a simple transform template, your instance of the IMF Delivery Schema can be turned into a website. With a little more development, you can automatically fill in the relevant information from the Delivery Schema instance into a document that you share with your suppliers.

DPP member companies are working right now on tools to create delivery schemas, and to turn them into human readable outputs. We’ll share more when such tools become available.

What’s next?

The IMF Delivery Schema is currently at version 1.0. It describes a CPL in some detail, but there is room for extending its remit. One exciting possibility is to include checks for certain metadata, which may be critical for the downstream processing of the IMF delivery in your workflow.

But most importantly, this is a community project that exists to serve your needs.