Digital Cinema Packages: DCI and DCPs (part II)

In the first part of our tutorial on DCPs we stayed in one of the intermediate stages of the DCP generation process, the DCDM (Digital Cinema Distribution Master). This DCDM is nothing more than a succession of TIFFs at 16-bit color depth and in XYZ color space, already with the 2K and 4K resolutions set by the DCI standard.

So, once we have the material ready we can start with the DCP generation phase itself. The first thing to do is to compress all the frames to JPEG 2000 files with a bitrate of 250 Mbits/sec (which is about 1.3 MB per frame at 24fps).

The audio is compressed in PCM at 48,000 or 96,000 samples per second, with 24-bit sampling, and up to a maximum of 12 independent channels.

Subsequently, these JPEG-2000 image and PCM audio files must be integrated into a container for later distribution. This is achieved by encapsulating them in MXF format files. In this regard, it is important to point out that the DCI standard establishes the obligation to divide the material into reels, with a maximum duration of 20 Mins per reel. In this way, we will have an image MXF file for each reel and as many audio MXF files as audio bands we have; that is to say, for a soundtrack in more than one language, one MXF per language and reel.

All this material is copied in a folder together with a series of XML files that are generated during the process and that index all the material that integrates the DCP. These XML files are the CPL (Composition PlayList), the ASSETMAP, the VOLINDEX and the Packing List.

The ASSETMAP is nothing more than an XML file with a list of all the files that make up the DCP, it is used for the digital cinema server to know all the material that has to be transferred in its internal storage.

The CPL is an XML file that indicates the order in which all the contents should be played, it is a playlist, like the ones used by multimedia players. It identifies each reel with a unique identifier (UUID), to avoid any possibility of error in the playback order.

In this regard, it is interesting to note that these XML files are easily editable text files, with the risk of possible manipulation of the contents or reproduction of the FAD.

To avoid this, another XML file is generated, the Packing List with a hash checksum, a mathematical operation that generates an alphanumeric key obtained by adding the values of the data in the files, using SHA-1 with Base64 encoding base. This file is checked during the ingest of the material in the digital cinema server to verify the integrity of the XML files of the DCP against possible manipulations or accidental corruptions.

Finally, the VOLINDEX allows that when distributing the contents of the DCP among different media (e.g. several hard disks), the order in which the material should be collected from these media is known.

This way we would already have a DCP without encryption, it would be a folder with several audio and video MXF (one per reel) plus the XML files mentioned above (CPL, ASSETMAP, VOLINDEX and Packing List). This way we would obtain a DCP without encryption, with a mainly non-commercial use; for example for advertising, distribution of short films for festivals, etc… In general, any material in which anti-copy security is not a priority.

However, as we mentioned in the first part, DCI has security as one of its priority objectives. Thus, if ours is a commercial project, it must have encryption, as in fact happens with all DCPs of films that are commercially distributed for digital projection. The big studios, the majors, impose very demanding security standards during the whole process of distribution, dubbing, subtitling, etc…, to avoid possible leaks of a material that is a high quality digital master and, therefore, susceptible to be copied and distributed fraudulently on a large scale.

In the next chapter we will explain the encryption process and the generation of decryption keys (KDMs).