DCP Testing & KDMs
A DCP that fails in front of a paying audience is a filmmaker's nightmare — and it's entirely preventable. This chapter covers how to test your DCP before it ever reaches a cinema, plus the one bit of DCP jargon left to demystify: KDMs, the encryption keys, and why for festivals you usually don't want them.
Making a DCP is only half the job; the other half is making sure it actually works, because a DCP is delivered blind — you hand it over, and the next time it plays might be in front of an audience. A DCP that won't load, plays with corrupted picture, has no sound, or crashes the cinema server is one of the most stressful things that can happen to a filmmaker, and it's almost always preventable with testing. The problem is that you can't just double-click a DCP to check it, so testing requires a deliberate step. The good news: you can validate and preview a DCP on your own computer with free software before it goes anywhere near a cinema. Two kinds of checking matter — verifying the package is technically valid, and actually watching it play — and doing both catches the overwhelming majority of DCP disasters while you can still fix them.
How to test a DCP
Before any DCP leaves your hands:
- Validate the package. Use a DCP validator (some tools, including DCP-o-matic's ecosystem, can check a DCP against the standard) to confirm the files, hashes, and structure are correct and nothing is corrupt or malformed. This catches technical faults before playback.
- Play it in a DCP player. Free DCP-player software lets you actually watch your DCP on your computer — checking that picture and sound play, are in sync, look right (color), and run start to finish without glitches. This is the single most important test.
- Check color and audio specifically. DCP color conversion is where home-made DCPs go wrong — watch for a washed-out or oddly-tinted image versus your master. Confirm audio is present, in sync, and in the right channels (especially if 5.1).
- Test on real cinema gear if you can. The gold standard is a test screening on an actual cinema server before your real one — many venues will do a technical check, and some festivals let you test in advance. Nothing beats seeing it on the target system.
- Deliver with time to spare. Send or bring the DCP early enough that the venue can ingest and test it before your screening, so any problem surfaces with time to fix, not five minutes before the lights go down.
KDMs and encryption — and why festivals skip them
The last piece of DCP jargon is the KDM — Key Delivery Message. A DCP can be encrypted, meaning the package is locked and won't play without a matching digital key, the KDM. That key is generated for a specific cinema server and a specific time window, so an encrypted film only plays on the authorized projector during the authorized dates. This exists for a good reason at the commercial level: it's anti-piracy protection for wide theatrical releases, ensuring a blockbuster only plays where and when it's licensed. But here's what matters for you as an indie: for festivals and most indie screenings, you almost always want an UNencrypted DCP, and you should not encrypt unless specifically required. Encryption adds a whole layer of complexity and failure — you have to collect the exact server certificate from each venue, generate a correctly-configured KDM for each screening's dates, and deliver the key alongside the DCP, and if the KDM is wrong, expired, made for the wrong server, or the dates are off, your film simply won't play. Festivals hate this because they juggle hundreds of films and don't want to chase keys, so most explicitly request unencrypted DCPs. Unless a distributor or a specific venue tells you they require encryption (which for indie festival play is rare), make your DCP unencrypted — it's simpler, it's what festivals want, and it removes an entire category of "the key didn't work" disasters. If you ever do need an encrypted DCP for a commercial engagement, that's when you'll get each venue's certificate and generate a dated KDM per screening, and the tools support it — but treat it as an advanced case you opt into only when required, not a default. So the rule of thumb: test every DCP by validating and playing it before you send it, deliver early, and keep it unencrypted unless someone specifically demands otherwise. Do that and DCP delivery goes from a source of terror to a routine, reliable step. With picture and sound handled, the next chapter adds a delivery element that's increasingly required and often forgotten: subtitles, captions, and accessibility.
I heard a horror story that made me a testing zealot: a filmmaker's encrypted DCP wouldn't play at their premiere because the KDM was generated for the wrong server, and there was no time to fix it — a packed house, and their film couldn't screen. Two lessons burned in. One: always test the DCP by actually playing it before delivery, and deliver early enough for the venue to test too. Two: never encrypt for a festival — I make every festival DCP unencrypted, so there's no key to be wrong. Since adopting both rules, I've never had a DCP fail. The nightmare is real, and it's completely avoidable.
Run your finished film through Distribution Readiness — check your masters, deliverables, and specs against what festivals and platforms require, so you catch problems before a rejection letter does.
