By Ulrich du Bosque, DPP Compliance Test Lab Manger, Friday 16th August
The component of IMF which causes the most questions and occasionally confusion is the “Output Profile List” or OPL. I can write this because OPL baffled me for a long time, and I am grateful for the patience of some of our members who coached me to the point where I am confident enough to write about it on our blog, and to run a DPP OPL work group!
This is the first post in a series discussing the OPL, and offers a brief overview of OPLs.
Why do we need OPLs?
At the heart of IMF is the Composition Playlist (CPL). This defines the exact version of a piece of content, what media is played and in what order. Each subsequent version requires another CPL – and possibly some additional media assets.
So the CPL facilitates lightweight versioning of content, but to unlock IMF’s potential for broadcast and online distribution, it also needs to cater for multiple outputs. A typical programme might be made available as a download in 3840p60 4:4:4, transmitted as 1920p30 4:2:2, and streamed to a wide range of devices in a number of resolutions, colour spaces, and delivery formats. Each of these outputs requires a transformation of the media which may require parameters to create the perfect result. The CPL does not address this.
What is an OPL?
An OPL contains the required information to implement these transformations in the optimal way for the output.
The transformations will be performed by an OPL processor, which could be a specialist piece of software, but is more likely to be integrated into a transcode product. We’re working with some of our transcode vendor members on this already.
Importantly, because an OPL is very prescriptive, the outputs should be repeatable and consistent across different products.
So how is an OPL different from a Transcode Profile?
Transforming media is not a new task, and it is likely that your facility converts many media assets every day. OPLs are different to transcode profiles in two ways:
- Transcode Profiles are usually specific to the transcode product used. Changing the product requires the re-authoring of profiles, each of which uses a different syntax. An OPL on the other hand is product-agnostic and can be interpreted by any OPL processor.
- An OPL can accommodate the intent of the creator as well as the specific needs of the distributor. For example, there is more than one way to adapt ultra-wide screen movies to narrower raster size: 1) Centre Cut, discarding the wide elements of the original picture, 2) scaling the image to create black bars top and bottom or 3) a compromise between the two. With OPL, the creator can signal their vision for how the images should be cropped for various resulting outputs.
Who makes the OPL?
An OPL may be created at the mastering stage, but they might also be created – or amended – at any point further down the supply chain. The image below shows three common points of OPL creation or update.
What’s inside an OPL?
An OPL contains a number of macros, each of which describes a specific transformation. These could include:
- Scaling or cropping the picture
- Routing the audio channels
- Controlling graphical overlays
- Mapping of metadata elements
Each OPL macro has defined inputs and outputs. This allows them to be chained together to achieve a specific output. The chain defined in an OPL has to be followed precisely by the OPL processor to ensure consistency across all implementations.
While OPL macros are general building blocks, the actual OPL built from them is not generally reusable. OPLs need to be created for each output of each CPL, and the chain of macros in an OPL should allow the CPL to be transformed into defined outputs, in a fully automated way.
But building OPLs need not be done by hand. DPP member companies are already working on developing tools to allow the authoring of OPLs from templates.
OPLs have been part of IMF standards from the start, and have been tested at SMPTE Plugfests. However, for the purpose of Broadcast & Online distribution we are only just defining the use cases and requirements for OPLs.
The DPP runs a weekly work group to do this, so if you’d like to contribute to our OPL development please get in touch with email@example.com.