This best practice defines terms used in IMF workflows alongside providing a top-level insight into some of the more common present day IMF use cases.
This Best Practice is published by the IMF User Group. It may be updated, replaced or obsoleted by other documents at any time. Readers are encouraged to consult and contribute to the issue tracker, which lists outstanding issues against the document.
©Hollywood Professional Association. Licensed under the Creative Commons Attribution-NoDerivatives 4.0 International License .
The current nomenclature pertinent to the packaging and delivery requirements of the Interoperable Master Format can lead to misinterpretation, confusion and present a number of challenges for service vendors and content owners who facilitate the mastering and version control of Composition Playlist instances and their respective assets. The recommendations outlined in this document are intended to mitigate such confusion and act as an industry reference for the version control and business-to-business interchange of IMF packages and delivery of their contained and/or newly created Composition Playlist instances.
Below are some of the most commonly used terms and agreed upon definitions currently in use. There may be slight variances for day-to-day usage, but this list is provided to reduce confusion across multiple varying workflow creators and users.
The following are definitions of existing terms in use by the industry that should not be adopted by IMF users e.g., the use of certain Digital Cinema terms, such as Original Version (OV). These terms have multiple interpretations depending upon the context and business entity and, as such, do not necessarily fit well within the IMF ecosystem.
The following sections documents common uses cases surrounding the exchange and/or delivery of IMF Packages. Such exchange is based on human, user driven processes.
IMF can be machine driven through the use of Application Programming Interfaces (APIs) and Media Asset Management Systems (MAMS). Recommendations for such an implementation is out of scope for this document.
Packing List and Asset Map files exist to facilitate asset transfer between systems using store-and-forward methodologies such as filesystems on physical media, and file transfer schemes such as FTP or basic file transfer via HTTP. While effective, this form of inter-system transfer can be very inefficient in cases where the assembled package contains more assets than the receiver needs or when additional resources are engaged to construct the minimal (most efficient) package for a particular use case. The entire subject of supplemental packages is a useful introduction to the many issues that may arise when attempting to package material for efficient distribution.
In the alternative, transfer between systems can be performed using an API to allow the receiver to indicate those assets to be transferred. This approach is more easily made efficient since there are no Packing List or Asset Map files to be created or interpreted. The sender can transmit, e.g., a CPL to the recipient, and the recipient can then compare the CPL Resource identifiers to its local database to create a list of items that are not locally available, and which must be requested from the sender. The recipient can then supplement its inventory with the requested items to complete the composition in the local system.
There are a number of situations that may require a CPL to be revised. This section defines what parameters are allowed to be edited/changed by an operator and those which are dependent on referenced resources and should be populated by the system used to assemble the CPL file.
A CPL has a number of descriptive metadata fields that are not derived from underlying essence files. As such, these fields are prone to human error which can lead to a revision being necessary. In order to avoid editing structural metadata derived from referenced essence, Table 1- "User Editable Metadata Fields" is provided for reference. This table depicts the fields that are permitted to be directly edited by a user after or during the creation of a CPL file.
It is required that for changes made to a CPL, a new document instance is created. It is also required that the new document instance has a new random value for the Id property, and that the IssueDate and Creator properties are also updated.
|Element Name||Attribute||Type||Parent Element||Issue|
|Content Title||No||string||CompositionPlaylist||Unable to properly identify the title of the content.|
|Issuer||No||string||CompositionPlaylist||Unable to properly identify issuing identity.|
|ContentOriginator||No||string||CompositionPlaylist||Unable to properly identify the origin of the content.|
|ContentKind||No||string||CompositionPlaylist||Unable to correctly categorize the content.|
|Annotation||No||string||CompositionPlaylist||Incorrect description of the composition.|
|Id||No||string||ContentVersion||Unable to properly identify the content of the composition.|
|LabelText||No||string||ContentVersion||Inaccurate description of the content.|
|Annotation||No||string||Locale||Incorrect description of the locale.|
|Language*||No||subtag||LanguageList||Incorrect language for the target locale. Could impact rights management.|
|Region||No||M49Code||RegionList||Incorrect locale identifier. Could impact rights management.|
|Agency||No||anyURI||ContentMaturityList||Incorrect value allows access to an unintended audience.|
|Rating||No||string||ContentMaturityList||Incorrect value allows access to an unintended audience.|
|Audience||No||string||ContentMaturityList||Incorrect value allows access to an unintended audience.|
|Audience||No||string||ContentMaturityList||Incorrect value allows access to an unintended audience.|
|Scope||Yes||anyURI||Audience||Incorrect value allows access to an unintended audience.|
|Annotation||No||string||Resource||Incorrect description of the resource.|
|EntryPoint||No||int||Resource||Unintended content representation.|
|SourceDuration||No||int||Resource||Unintended content representation.|
|RepeatCount||No||int||Resource||Unintended content representation.|
*A language tag is embedded in the MXF metadata of sound track files, identifying the spoken dialogue of the underlying sound essence. Given that the language tag is embedded in the MXF metadata, if it set incorrectly then updating/changing the language tag requires re-wrapping of all sound essence included in the associated track file.
There are titles, which due to distribution requirements will need certain playable regions omitted in subsequent versions, whereby their compositions are delivered as a supplemental package. Cases include but are not limited to the following.
This supplemental package only contains a Composition Playlist, a Packing List and an Assetmap. There should be no MXF track files included. Figure 1 - "CPL Timeline Trimming Example" showcases the unchanged state of the referenced MXF track files, but rather the amended duration values of the Sequence resulting in a shorter playable region.
There can be many reasons why MXF references need to be updated or changed. The following subsections cover the common use cases where MXF track file references are changed and the manner in which one should package the updated files.
A language tag is embedded in the MXF metadata of sound track files, identifying the spoken dialogue of the underlying sound essence. Given that the language tag is embedded in the MXF metadata, updating/changing the language tag requires re-wrapping of all sound essence included in the associated track file.
The resulting sound track file(s) can be referenced from new Composition Playlists (CPL). The updated sound track file(s) and CPL(s) can be packaged in a new complete package with the original picture track files, or as a supplemental package that only contains the new Composition Playlist, a Packing List, Assetmap and the newly created sound track files.
Figure 2- "MCA Language Tag" depicts an excerpt of a Composition Playlist’s Audio Essence Descriptor XML structure. The highlighted RFC5646SpokenLangauge value is an XML representation of the metadata contained in the respective MXF track file. To manually change this value will break the Tag relationship between the CPL and the referenced MXF track file.
IMFUG BP 004 MCA Best Practices provides some guidance on how to choose MCA properties.
It is not uncommon for issues to be detected in essence during the Quality Control (QC) process after delivery. Such issues can be a sound track replacement, picture inserts due to poor quality or aesthetic revisions. Such fixes are ideally delivered as a supplemental package that contains a newly created Composition Playlist, a Packing List, Assetmap and a number of picture or sound MXF track files acting as inserts.
Figure 3 - depicts the follow up delivery of newly created Picture and Audio fixes as individual MXF track files. They are packaged in a Supplemental Package also containing a new CPL referencing the previously delivery MXF track files in the Original Language Version (delivered as a complete package) and the newly created MXF track files.
The newly created Composition Playlist can still reference existing track files outside the package that have been delivered previously.
In order to satisfy local versioning requirements, picture sections that depict language-specific narrative items such as on-screen text and narrative titles are localized resulting in alternative picture versions for these sections. These ‘sections’ act as picture inserts and are used to replace the original language version instances.
These picture inserts can be delivered in a supplemental package that contains a newly created Composition Playlist, a Packing List, Assetmap and the newly created picture inserts.
This same practice can be applied to the manufacturing of Textless Compositions.
For dubbed instances of an Original Language Version, it is recommended that supplemental packages are used to deliver said dubbed content versions.
The following list outlines the optional elements permitted by ST 2067-3 which are recommended to be included in all CPL XML documents.
hash Element should be present for all referenced track file resources.
IMF provides a vocabulary to describe time positions in a composition through the use of Markers. The same terminology used to describe Markers as defined in ST 2067-3 should be used when discussing relative positions in a composition timeline in an informal context.