Inside the DCP folder: ASSETMAP, PKL, CPL and MXF.
Updated: 1 day ago
Open a finished DCP and it looks like a mistake. No movie file. A couple of enormous files with names made of random letters and numbers, and a few small text files beside them. Double-click anything and nothing useful happens.
Every one of those files has a job, and knowing the jobs is the difference between understanding a failed ingest and panicking about one. Last week you made a DCP with DCP-o-matic. This week we open it up.
The shipping container analogy.
Think of a DCP as a shipping container.
The big MXF files are the cargo: your picture, your sound, your subtitles. The small XML files are the paperwork taped to the door. One says what’s inside and where it sits. One is a signed inventory with a fingerprint for every crate. One is the instructions for unloading it in the right order.
A port will reject a container whose paperwork doesn’t match its cargo. A cinema server does the same thing, for the same reason.
The cargo: MXF track files.
MXF (Material Exchange Format) is a wrapper, a standard box for media. A DCP has one MXF file for each kind of content:
Picture. Every frame as a JPEG 2000 image, one after another. This is the huge one, often more than 100 GB for a feature.
Sound. Uncompressed PCM audio, 24-bit, every channel interleaved in one file.
Subtitles and captions, in SMPTE DCPs, as their own MXF track files.
These are called track files, or assets. Long films are sometimes split into reels, with a set of track files per reel, the way a 35mm print came in cans. A DCP-o-matic feature is usually one reel.
Each asset gets a UUID, a universally unique identifier: a long string of letters and numbers that no other file anywhere will ever share. That’s why the file names look like noise. The server tracks your picture by that ID, whatever the file is named.
The paperwork, one file at a time.
CPL, the Composition Playlist. This is the instructions. It lists the reels in order and, for each reel, which picture, sound and subtitle assets play together, referenced by UUID. It records the title, the frame rate, the runtime and the content kind (feature, short, trailer). When a projectionist builds a show, they’re building it from CPLs. One DCP folder can carry more than one CPL. The same picture can have one CPL with English subtitles and another without.
PKL, the Packing List. This is the signed inventory. It lists every asset in the package with its UUID, its size, its type and a hash. The hash is a fingerprint calculated from every byte in the file. At ingest the server recalculates each fingerprint and compares it to the PKL. If a single byte changed on the way to the theater, the fingerprints don’t match and the server knows.
ASSETMAP. This is the map. It tells the server which file on the drive corresponds to which UUID. In a SMPTE DCP it’s called ASSETMAP.xml. In the older Interop format it’s just ASSETMAP, with no extension. That tiny difference is one of the quickest ways to tell which standard you’re looking at.
VOLINDEX. A leftover from the days when one package could span several drives. It says which volume this is. Usually “1 of 1.”
All of these are plain XML. Open a CPL in a text editor and you can read it. Try it once. It makes the whole thing less mysterious.
Why it’s built this way.
This structure solves problems theaters had with film and early digital:
Verification. The hashes mean a server can prove a DCP arrived intact before anyone sells a ticket.
Versioning. Because CPLs point to assets by ID, a distributor can ship a French-subtitled version as a small package that reuses the big picture file already in the server. That small package is called a VF, a version file. The complete package with all its own assets is the OV, the original version.
Security. Track files can be encrypted separately, and the keys delivered later. Week twelve covers that.
Scheduling. A projectionist can drag CPLs into a playlist with trailers and ads, in any order, and every one behaves the same way.
How people break a finished DCP.
The structure is strict, which means it’s easy to damage after the fact:
Renaming files. The ASSETMAP points to exact file names. Rename one and the server can’t find it.
Renaming the folder is usually fine. Renaming what’s inside it isn’t.
Editing the XML by hand. Change one character in a CPL and its signature or hash no longer matches.
Copying with a tool that alters files, or a copy that silently fails partway. The PKL catches it at ingest, which is the worst possible time to find out.
Leaving extra junk on the drive. Operating systems like to write hidden files to external drives. Some servers don’t mind. Some do. Using DCP-o-matic’s Disk Writer avoids the question.
Mixing standards. A package with some SMPTE parts and some Interop parts will fail. DCP-o-matic’s verifier flags it.
What to do with this.
Two habits. First, never touch the inside of a DCP folder once it’s made. Copy the whole folder, as-is, every time. Second, run the verifier after every copy as well as after encoding. It rechecks every hash, which is exactly what the theater will do.
Next week: SMPTE versus Interop, and how to read the long name on the outside of the folder. If you want someone to build and check the package for you, our DCP service validates every DCP before it goes on a drive.
Comments