In the language of digital cinema, a Digital Cinema Package, or DCP, is the name given to the collection of files sent to a cinema. It is a “packing crate” for files, which may or may not comprise a complete motion picture. A digital motion picture, on the other hand, is comprised of a structured set of files referred to as a Composition. A Composition is a work product, or title, examples of which include not only motion pictures, but also trailers and advertisements.

A DCP can carry one or more Compositions, or only a partial Composition. When carrying one or more Compositions, the DCP is called a Composition Package. When carrying the partial assets of a single Composition, the DCP is called an Asset Package. A Packing List accompanies each DCP, identifying the DCP’s file assets. These concepts are illustrated below, and explained in further detail in subsequent parts of this chapter.

Importantly, the DCP and Composition concepts are not patented.  For interoperability, multiple SMPTE standards define the structure of the components.  Further, multiple software providers offer DCP creation products, some of which are based on open source software.

Figure DCP-1. A Digital Cinema Package (DCP) as a Composition Package

Figure DCP-2. A Digital Cinema Package (DCP) as an Asset Package

A Composition is a complete version of a work product, or title. The Composition consists of multiple files comprising a playlist and at least two Track Files. For flexibility and extensibility, each Track File carries only one type of essence, such as picture, sound, or subtitles. The manner in which the files are to be played is specified in a playlist, called the Composition Playlist, or CPL.

By definition, a Composition must have at least three files: a Composition Playlist (CPL), a Picture Track File, and a Sound Track File. In addition, Track Files can be divided into multiple files consisting of temporal chunks of essence called Reels. The name “reel” comes from film distribution, where a movie is shipped as temporal chunks of film, or reels of film. Reels makes it easier to physically ship the movie. But it is also easier to deliver a last minute edit when changing only one reel of a movie, which might happen due to a correction in credits, or a product placement change. Similarly, certain efficiencies are possible in digital distribution and production when organizing digital content in temporal chunks, leading to the organization of Compositions in digital Reels.

The illustration below depicts a Composition consisting of a Composition Playlist and four types of essence Track Files (Picture, Sound, Subtitle, and Closed Caption), temporally organized as two Reels.

Figure CPL-1. Composition Structure

In practice, a Composition might contain as many as 100 files, or more. The only limit to the number of track files is that imposed by the rules for encryption.

Multiple versions of a title often exist. Different versions might be necessary to accomodate 3D, subtitles, censorship cuts, or additional language sound tracks. For each version, a different Composition must be created. While this may sound inefficient, the single-essence-per-file rule encourages efficiency by allowing file assets to be shared among versions. As an example, different Compositions, representing versions of a title, intended for distribution in different countries may have different Sound Track Files, but carry the same Picture Track File. This example is illustrated below.

Figure CPL-2. Composition Versions with Shared Picture Essence Asset

Similarly, a 3D Picture Track File could be exchanged for the Picture Track File shown above, along with new CPLs, to define 3D versions of the movie. In this manner, many versions of the movie can be distributed without the need to send duplicate Track Files.

The Composition architecture, when first proposed in late 2001, was a distinct departure from any prior media format used in distribution. Prior distribution media formats characteristically married essence types into a physical form, such as a book, a DVD, a film print, or into a married electronic form, such as a television broadcast signal. Notably, it is a characteristic of the motion picture business to distribute motion pictures in somewhat customized versions, such as a version with a particular sound format, captions, a particular aspect ratio, or in one or more languages. This is driven by community requirements and equipment limitations, which often require cinemas to present more than one version of a movie over the course of an engagement. The Composition architecture was conceived to efficiently address the need to distribute multiple versions of a movie to a cinema by providing a mechanism for sharing essence files among versions.

The concepts behind the DCP and Composition, as described in this and the prior section, are explained in further detail in SMPTE ST 429-2 DCP Operational Constraints, the top-level standard for SMPTE DCP. These concepts were first put to work in the pre-standard Interop DCP, as explained here. Interop DCP remains in use today, although it is recommended that distributions transition to the newer and better documented SMPTE DCP.

(For those interested in the history of the Composition, the first public presentation on the concept was given by Michael Karagosian at NAB 2002, and available here.)

The Composition section discussed how multiple versions of a Composition may be created while sharing essence carried in select Track Files. In the DCP section, the concept of a single Composition Package was presented for the carriage of multiple Compositions. A Composition Package can be used to efficiently carry multiple versions of a title.

It is often desirable, however, to distribute title versions as separate DCPs. In such cases, a parent Composition will carry the complete version of a title, and one or more child Composition versions are created, designed to share select Track Files of the parent. When all of the CPLs and essence Track Files are present in common data storage, the playback system will have everything it needs to play each version of the title. But all of the files needed to play a child Composition will not be present in the DCP that carries it. A mechanism is needed to properly manage the distribution of parent and child Compositions.

In practice, the parent Composition is given the label “Original Version,” or “OV” package, and carried in its own DCP. Each child Composition is given the label “Version File” or “VF” package, and also carried in its own DCP. When the parent OV package and associated child VF packages are loaded onto a digital cinema server, all of the files needed to play the various Composition versions are present and ready to play.

The illustrations below depict the two methods available for distributing multiple Compositions that share Track Files.

Using a single Composition Package:

Figure TV1. Composition Versions carried in a single Composition Package

Using multiple DCPs:

Figure TV2. Composition Versions carried in OV and VF DCPs

Both distribution packaging methods, when fully loaded into the digital cinema server, lead to the same result, allowing both Composition versions to be played, as illustrated below.

Figure TV2. Composition Versions having shared Assets

Every Composition is defined by a Composition Playlist, or CPL.  As the name suggests, the CPL defines and orchestrates the playback of all Track Files that comprise the Composition.  It does so temporally, in a reel-by-reel fashion.  Each version of a title will have a unique CPL  This could be a version having a certain picture type (a particular aspect ratio, or 2D vs 3D), a different sound mix (say, 5.1 or 7.1), a sound track in a particular language, subtitles in a particular language, and so on.

While title versions require a unique CPL, the Track Files associated with each CPL do not have to be unique. A set of Picture Track Files, for example, can be shared by many CPLs, each CPL defining a different version of the work based on the same Picture Track File, but having other Track Files of different essence types that are unique to that version.

Figure CPL-1.  The Composition Playlist (CPL)

The CPL is an XML data file whose metadata defines the Composition that it represents.  A description of the CPL’s data elements is presented below:

Table CPL-1.  Composition Playlist (CPL) Data Elements

For a complete description of the SMPTE CPL, please refer to SMPTE S429-7 Composition Playlist. The top-level document that defines the DCP and Composition is SMPTE ST 429-2 DCP Operational Constraints.

The CPL carries metadata that describes the Composition, but in practice, more data is needed to benefit cinema operators. An ad-hoc nomenclature is often used for this purpose called the Digital Cinema Naming Convention.  The Naming Convention prescribes a human-readable text field carried by the CPL Annotation Text element.  It was devised as a stop-gap measure until a means to include additional metadata in the Composition was devised.  A standard that accomplishes this is now available, titled ST 429-16 Additional Composition Metadata and Guidelines.

SMPTE defines content as metadata plus essence. Essence, in the digital cinema application, is the term applied to a single form of expression, such as picture, or sound, or subtitles. Essence types are singular in nature, i.e., only a 24 fps picture file, only a 48 fps picture file, only a 3D picture file, only a 5.1 sound track, only a 7.1 sound track, and so on. Using these definitions, a Track File carries a single essence type plus the necessary metadata to facilitate its use.

The independence of essence types in the Composition provides a high degree of extensibility, allowing new types of essence to be introduced in the future without breaking the structure of the Composition. For example, when the concepts of the Composition and the Digital Cinema Package were first introduced in digital cinema, stereoscopic 3D was not on the roadmap. But the extensibility of the Composition allowed the Stereoscopic Picture Track File to be quickly incorporated as digital 3D emerged.

MXF Picture & Sound

Track Files are wrapped per a constrained version of the Material Exchange Format, or MXF, specification. MXF provides a structured method for carrying a variety of essence types with metadata. While MXF is capable of carrying more than one essence type in a single file, it must be emphasized that the digital cinema application requires only one essence type per file. More can be learned about MXF on Wikipedia. The constraints applied to MXF for wrapping digital cinema Picture and Sound are defined in SMPTE ST429-3 Sound and Picture Track File.

MXF track files consist of a header, an essence container, and a footer. The header carries metadata that describes the track file. The essence container carries, of course, the essence. The footer carries an index table of the essence.

Picture and Sound essence is frame wrapped using KLV (Key-Length-Value). The KLV Key identifies the nature of the essence present. Length refers to the length of the Value field. The Value field itself contains a frame of essence. More can be learned about KLV on Wikipedia.

MXF Track File Showing KLV Packet

XML & Timed-Text

Timed Text Track Files, such as open or closed Subtitles and Captions, are defined in XML and then wrapped in MXF. The wrapping of Timed Text XML is similar to that for Picture and Sound, in a reel-by-reel manner, with the exception that font resources may also be included in the wrap. The constraints applied to MXF for wrapping digital cinema Timed Text are defined in SMPTE ST429-5 Timed Text Track File.

A Composition may be encrypted for secure distribution. When encryption is performed, only the Track Files are encrypted, in a file-by-file manner. The Composition Playlist (CPL) is not encrypted. Track Files may be selectively encrypted, where some Track Files are encrypted, and others are not. In practice, decisions concerning encryption are left to the content owner. A content owner, for example, may choose to encrypt picture but not sound or timed text files. When a Track File is encrypted, all essence in the file is encrypted. Essence in a Track File cannot be partially encrypted.

Figure TFE-1. An Encrypted Composition

The encryption algorithm used in digital cinema is the well-known Advanced Encryption Algorithm (AES). AES is a symmetric encryption algorithm, a term explained in the Encryption section. In the digital cinema application, a 128-bit key is used. When encrypted, the essence within each Track File is encrypted with a unique key. No two Track Files utilize the same key. The Key Delivery Message (KDM), also discussed in the Encryption and Key Delivery Message sections, carries an encrypted version of each key used to encrypt the Track Files within the associated Composition. A KDM is required to unlock and play the Composition.

Only the essence, or the “Value” portion of the KLV packet, is encrypted. The metadata associated with the essence is exposed so it can be read when searching the file. This also allows an operator to play a Track File from any frame, regardless of encryption. The KLV packet with the encrypted essence is wrapped within another “special” KLV packet, along with associated cryptographic metadata. The “special” KLV packet simply carries encrypted content, without knowing the nature of its contents. The “special” KLV packet, carrying the encrypted KLV packet, is then wrapped in an MXF Track File as it would were it not encrypted. This arrangement is illustrated below.

Figure TFE-2. Encrypted KLV Packet is Carried Within a Special KLV Packet
in the MXF Track File

More information about Track File encryption is available in SMPTE ST429-6 MXF Track File Essence Encryption.

Cinema has a history of innovation among filmmakers, resulting in a variety of film formats that require special setups per release. Business transactions also need assistance, as the provider of the DCP is often not the entity with whom box office is shared. One of the hopes when introducing digital distribution to cinema was that of automating projection system and back-office processes. However, the metadata included in the Composition Playlist (CPL) has proven to be inadequate for this purpose.

To provide users with a richer set of metadata, SMPTE DCP allows the optional inclusion of an Additional Composition Metadata file, as described in SMPTE ST 429-16:2014 Additional Composition Metadata and Guidelines. The information that can be carried in this file is listed below.

Table ACM-1. Additional Composition Metadata Data Elements

A discussion of the DCP would not be complete without mention of the two types of distribution package used in production: Interop DCP and SMPTE DCP. They are functionally similar in that the DCP definitions provided earlier in this chapter apply to both types of packaging formats. But they are substantially different in that they are not interoperable.

Interop DCP is based on an early draft proposal for SMPTE DCP.  It was put into practice in 2004, in preparation for the rollout of digital cinema.  SMPTE DCP was not finalized until 2009, four years after the rollout began. Interop DCP was intended as a temporary format until the standardized version came into existence. However, the lack of backwards compatibility, as well as the requirement for functionality not available in legacy equipment, has hampered the transition to SMPTE DCP.

Digital cinema owes its success to Interop DCP, which continues to be the primary distribution format at the time of this writing. Despite its success, Interop DCP was not formally standardized, but the documentation is available through Cinepedia at Interop DCP. In contrast, SMPTE DCP is well-defined, and published as a suite of SMPTE standards. Maintenance on Interop DCP continued up until 2012, when it was decided to limit new development to only SMPTE DCP.

There are several differences in SMPTE DCP that prevent backwards compatibility and interoperability. Both formats utilize a Composition Playlist (CPL), but with different, non-interoperable XML structures.  There are also structural differences in Subtitle and Audio track files.  SMPTE DCP Subtitle track files are encrypted, a valued feature to distributors.  But the structure of the subtitle track file is significantly different from its Interop counterpart, as there was an intellectual property issue with the Interop version at the time the standard was created.  The result is that DLP Series 1 projectors,  the largest concentration of which are in the United States, are incapable of rendering the SMPTE DCP subtitle track file.  This incompatibility can be overcome by rendering SMPTE subtitles in the server, a feature which is now commonplace in newer servers and media blocks. Another difference is a reliance on audio channel routing in the server, which also is not supported in many older systems. As a result, practical SMPTE DCP distributions are constrained to bypass the new audio features, falling back to Interop-style audio packaging.  This workaround requires the use of “Channel Configuration 4” described in Annex A of SMPTE ST 429-2 DCP Operational Constraints, which was originally included for test purposes. More explanation of digital cinema audio is available in the chapter on Sound.

The DCP type can be most easily recognized by the namespace root called out in the XML-based Composition Playlist (CPL). SMPTE DCP uses the SMPTE-RA.ORG namespace root, while Interop DCP uses DIGICINE.COM. The top-level document that defines SMPTE DCP is SMPTE ST 429-2 DCP Operational Constraints. Interop DCP documentation is available here.

There is also an excellent presentation by Jim Whittlesey on the differences between Interop DCP and SMPTE DCP.