DCP
DCP
DCP
What Is DCP?
Background:
Due to the emergence of Digital Cinema, many theatres do not have any 35mm
equipment anymore. All new theatres being built are digital only but from the late 1800s up until
about 2011 if you wanted to show your movie in a theatre you had to make a 35mm film print.
Even if you shot on video tape you’d have to transfer it to 35mm in a process called a “filmout”,
and once you had your film on 35mm you still had to make prints and send them to every the-
atre.
The utility and cheapens of DCP shows when thinking of the following example : A stu-
dio releasing a movie to 4000 screens might spend $6 million just in film prints alone; in contrast,
making a feature DCP typically costs 90-95% less than a “filmout”
What is it made of ?
A DCP contains video, audio and subtitles (if needed) along with instructions
for how to play them. The list you will see contains:
1. MXF File(s) containing the pictures in JPEG 2000 Codec & XYZ Colorspace.
2. MXF File(s) containing the sound channels.
3. A number of XML files identifying the elements of the film and how they should
be played.
Having separate picture and sound files is very practical for films, it means that different
language versions can be produced without having to re-encode all of the pictures.
for in house purpose
DCP - learning guide -
2. A quality Check or 'QC' is where the final product is checked for glitches, dropout,
sync problems, gamma, color, etc. by an experienced technician.
3. Transfer to USB or CRU drive. This is the final step when the mastered files (collec-
tively called the DCP) are transferred to an EXT 2/3 formatted Linux hard drive.
The actual drive can be a standard portable USB available in any computer store, or a
professional "DX115" drive carrier, which is called a CRU. Again, both USB and CRU
have the exact same information on them, so there’s no difference in quality. Some
theatres and film festivals demand a CRU however most are perfectly happy to use the
much less expensive USB drives.
First of all there are file containers, sometimes called wrappers, that wrap
around a number of video and audio tracks. Each of those tracks will have an appropri-
ate video or audio codec. A codec is a concatenation of “coder – decoder”. (Think of a
shipping container. There’s this standard “wrapper” (the container) which tells us noth-
ing. Inside could be a car, computer or a million wrist watches. Like the shipping con-
tainer, file containers can carry many different types of content – the video and audio
tracks. These tracks are encoded with some sort of codec. Most codecs compress the
video to reduce file size and time to download )
So why use a wrapper at all? if you think about a feature film having around 150,000 in-
dividual frames in it, then transporting and playing 150,000 individual files can be a real
pain so putting them in an appropriate wrapper format is really useful.
for in house purpose
DCP - learning guide -
One of the big advantages of the MXF (Material Exchange Format) is that it
isn’t tied to any one manufacturer the way that something like Quicktime is tied Apple.
While there’s lot’s of formats capable of doing the job, MXF is one that’s been developed
by the industry and won’t suddenly leave the industry with licensing problems in a few
years time. It’s also pretty agnostic about about platform and codecs, so it’s very flexible
and it was designed from the beginning to be very good at handling the additional infor-
mation that goes with a lot of content these days – Metadata.
Within the Picture MXF the images are encoded with intra-frame com-
pression in the JPEG 2000 codec. This is very different to the everyday JPEG format
that everyone uses with digital cameras an a vast proportion of the images in the web.
( for this case JPEG uses a type of DCT compression which breaks the image down into blocks
of pixels near each other that can be grouped together and colour values averaged. This works
on the principle that pixels near each other are often similar colours; the bigger the blocks, the
bigger the reduction in the amount of data used. JPEG & DCT are great at getting good looking
images down to file sizes that are a fraction of the original. The mathematics behind the process,
therefore the processing power and time needed to do the job are relatively modest. The down-
side is that when the compression does become visible it is in the form of those blocks. This is
most noticeable in big areas of similar colours light the sky or a white wall, where one block av-
erages one way and the adjacent ones go a different way.)
On the other hand, JPEG 2000 is different. It uses Wavelet compression
which is much more complicated both as a concept and to implement. The upsides are
that the quality is much better and on the rare occasions when it does degrade the im-
age, the effects look much more natural and are therefore much less noticeable to the
audience.
A Color Space is a mathematical model that maps the colors that can be re-
produced by a device to a standard color model.
The eye is as good as any reference when building a color space. Why? Even
though we have displays that claim to show a billion colors, the eye can never see all of
those colors. One of the first mathematically determined color spaces is the CIE XYZ
1931 color space, created by CIE (International Commission on Illumination) in 1931.
A color space is actually a 3D image.The two-dimensional image is only a
cross-section of the entire color space.
Other color spaces are also represented with similar chromacity dia-
grams that make it slightly easier to visualize them in comparison with each other.
There are color spaces ‘smaller’ and ‘larger‘ in volume than CIE XYZ. Therefore, a
two-dimensional diagram shouldn’t be used exclusively to compare various color spa-
ces. It is possible for one color space to have lesser colors than another but still have
colors that the “larger” color space doesn’t have.
XYZ colorspace essentially takes RGB space and then refines it dra-
matically to match the way the various Rod & Cone “pixels” in our eyes actually combine
to perceive colour. So while RGB is a very electronic friendly way of capturing, control-
ling and manipulating colours, XYZ space is a very efficient way of presenting them so
that they best match the human visual system.
for in house purpose
DCP - learning guide -
There is a small difference in how the binary data is organised between InterOp and
SMPTE *.mxf track files and therefore image and audio track are NOT interchangeable between
InterOp and SMPTE DCPs. It is also important to note that if the essence data is encrypted, you
must decrypt and re-encrypt essence (image and audio) data when converting from InterOp to
SMPTE.
Example:
> License:
The License is used to activate the purchased modules on a specific hardware server.
>Server Certificate:
Each DCP render (referred in the industry as an ‘Instance’) using encryption or decryp-
tion has an individual server certificate. This certificate is required to be able to receive
Key Delivery Messages (KDMs), which unlock encrypted DCPs.
8. Set the Subtitles Path. If you have a properly formatted subtitle file, click the
Browse button to link to it.
for in house purpose
DCP - learning guide -
9. If you’re including an audio mix in the DCP, go to the Audio section, turn on the
Render audio checkbox, and choose the number of channels in the “Render channels of
audio” pop- up menu that corresponds to the number of Audio Mixer output channels de-
fined in the Edit page.
10. Click the Browse button under the “Render to” field, and choose a location for
the resulting DCP. Make sure you pick a drive with enough room for the estimated size
of the final DCP.
Select the DCP in the Media page Library. Right-click and select Generate
KDMs. From the pop-up select the location of the Server Certificate file if the KDM
is for one player, or folder for multiple players. Set the start and end dates that the
KDM will be valid for, an output folder to place the KDM, and then select Generate.
You can now send your DCP and the KDMs to the player you authorised. The user
there will import the KDM and the DCP will play between the start and end dates.
To play a DCP you’ve output from Resolve, use the Media page to add it to the
Media Pool and edit it into a timeline like any other clip.
Decoding the JPEG2000 images embedded within the DCP in real time is com-
putationally intensive. If your system is underpowered you can reduce the decoded reso-
lution of the files by selecting Half or Quarter Resolution Decode from the File > easyD-
CP menu. A smaller, less bandwidth-intensive version of the JPEG2000 files will be de-
coded by discarding some levels of the wavelet stage inside the decoder, which will di-
rectly increase the playback performance.
for in house purpose
DCP - learning guide -
When you receive a KDM or a Digest for an encrypted DCP you must first import
the file into your DaVinci Resolve system. Using the File, easyDCP menu select Import
KDM/Digest, and then select the file. Then simply select the encrypted DCP in the Media
Page Library to play.
A DCP key (about 1Kbytes) is used to encrypt or scramble the DCP using magic math.
The security industry believes that if you get an encrypted file you will NOT be able to decrypt it
without the key. But if you do have the DCP key you can easily decrypt the file and recover a
copy of the original DCP. The DCP Key(s) are symmetrical – the SAME key that is used to en-
crypt the DCP is also used to decrypt the DCP at the theatre. Much like your home key, it locks
the front door when you leave and the same key unlocks the front door when you return home.
for in house purpose
DCP - learning guide -
Each screen (or server/ projector) has two special keys - a Screen Public Key
and a Screen Private key. The public keys are just that - public! They can be freely given
out, but are useless without the private keys - which are well protected and safe inside
the server. The screens share their public keys by giving out the “screen CERT” which is
their Public key. Which is why it is necessary for a screen to provide its CERT when it
wants a KDM. So the key distributor uses the target Screen Public Key and the
DCP Key to create a KDM. The screen server takes the KDM using its own Screen Pri-
vate key to decode the DCP Key to enable play of the movie. The server does this inside
very well protected electronics called the IMB - Integrated Media Block - so that no one
can get to the unencrypted DCP Key or the DCP itself or the Screen Private Key.
A screen shares its Screen Public Key to a key distributor. The key distributor
sends the encrypted DCP out to the screen along with a KDM for that screen. The
screen uses the KDM and the Screen Private key to decrypt the KDM to get the DCP
Key and the DCP movie comes magically out for making a wonderful movie on the
screen. For DCP protection it also means each screen/server needs its own private key
so it gives better control of distribution. ANYONE can get the encrypted DCP and ANY-
ONE can get the KDMs, but only those with authorised private keys, i.e. the screen/
server, can play it.
for in house purpose
DCP - learning guide -
We send the DCP encrypted on hard drives and over satellite to anyone that
MIGHT want to play or book the movie and the KDM is customised for each screen
server and sent to that screen server.
A KDM facility (a facility that makes and delivers KDM messages) is a very trust-
ed entity. They hold the unprotected DCP key. Something that should be very, very well
protected. The KDM facility needs to keep a good list of all the possible screens and
locations. They need the CERTs for each screen server, the owner, and the capabil-
ities of each screen (5.1, 7.1, screen brightness, 3D 2D, HFR, etc.) This list is a
Trusted Device List for the KDM facility. They need to have high confidence that these
are valid CERTs that go to a real authorised screens.
Next comes the booking. The studio builds a list of which screens / locations are
authorised to play the movie and for how long. And the KDM facility needs to know all
the screens in a complex since studios send KDMs for all screens in a complex.
Getting the right keys to the right theaters is a bit more difficult. The KDM facility
determines which sites need to play a movie and generates all the keys/KDMs for all the
authorised CPLs//screens in the complex. A twenty-plex could get 20 to 60 keys or more!
The most popular way of sending KDMs is through the email system. The KDM facility
takes all the keys for a particular site and “zips” them into an attachment to send to the
theatre manager. The theatre manager opens the attachment, unzips the keys and puts
them on a USB thumb drive and “sneaker net” the drive to the TMS (Theatre Manager
System). The TMS “ingests” the keys and appropriately distributes them to the appropri-
ate servers. Or the theatre personnel has to walk the USB thumb drive to each screen
(playback server) and ingest the KDM for the specific CPL version (5.1, 7.1, open cap-
tions ….)
The first version of the DCI specification required a Fax Modem line into each
server! This was for KDM delivery - it did provide direct access for delivery of KDMs, but
there were so many problems - getting phone lines into theatre booths, unplugging the
lines, etc. It has a failure rate of over 15%. But today every booth has a network be-
tween all devices and at some place a bridge to the web. A group of very smart (and
nice) folks devised a method of delivery called “Theatre Key Retrieval” (TKR) that
meets a set of very strong criteria for automated key delivery.
The Theatre gets the CPL and finds the address of the hidden website and goes
out to find the hidden website and “gets” the KDMs that it needs for its servers.
1. The KDMs can be automatically generated (they already are automatically generated) and posted to the
hidden website. If you need to “send” a new key, just post a new one and the theatre will look for it.
2. The theatre is well protected against viruses or someone breaking in the security wall - it is a “get” sys-
tem and not a “push” to the theatre solution.
3. It meets all the requirements specified above.
CPLs need to include the hidden website address. Both Interop-DCP and SMPTE-DCP have been tested
and been shown to work (and not cause a problem for software in the field).
Image sizes:
• 2K scope: 2048 x 858
• 2K flat: 1998 x 1080
• 4K scope: 4096 x1716
• 4K flat: 3996 x 2160
DCP Format
The DCP files shall be wrapped using the MXF Interop/ SMPTE for DCI. The DCP shall
consist of the following types of files:
• Assetmap
• Vol Index
• Packing List (PKL)
• Composition Playlist (CPL)s
• MXF Wrapped image track file(s) • MXF Wrapped audio track file(s)
• Channel 1—Left
• Channel 3—Center
• Channel 5—Left Surround
• Channel 2—Right
• Channel 4—LFE
• Channel 6—Right Surround
If two (2) channels of sound (Stereo—LtRt) are required, a separate CPL shall be used
within the same DCP.