Digital Cinema Package (DCP)

A DCP is not a single file. It is a directory, and the contents are deliberately boring and deliberately standardised so that a package cut in Los Angeles plays on a server in Bergen without anyone phoning anyone.

The picture and sound live in MXF track files. Picture is JPEG 2000 — every frame compressed on its own, which is why you can scrub a DCP and why the bitrate is so high compared with a delivery master. Sound is uncompressed PCM, normally 24-bit at 48 kHz, in a matching MXF. Nothing in a DCP is in a consumer codec; there is no H.264 anywhere in a compliant package.

Everything else is XML. The CPL (Composition Playlist) is the edit: it names the track files and the order and duration they play in. The PKL (Packing List) is the manifest with a hash for every asset, which is how the server knows the ingest was clean. The ASSETMAP maps each asset's UUID to its path on the disk. If a DCP will not ingest, the fault is almost always in these three files rather than in the picture.

Historically a DCP arrived on a CRU DX115 hard drive carrier — a bare SATA drive in a plastic shell that slots into a dock on the server. That is still the fallback, and it is still what turns up for repertory titles, festival prints and anything from a distributor without a delivery contract.

For wide releases the package is delivered electronically instead, by satellite or fibre, and lands in the library before anyone in the building has thought about it. Either way the DCP has to be ingested: copied off the carrier into the server's own storage and hash-checked against the PKL. Ingest is not instant — a feature is typically 100–300 GB and a USB 2.0 dock will take hours you do not have on a Thursday.

An encrypted DCP is inert until the matching KDM arrives, and that KDM is cut for one specific playback device and one specific date range. A package can be ingested, verified, on the playlist and still refuse to play because the key is for the screen next door.