What a DCP Actually Is: JPEG 2000, MXF, and the Tech That Delivers a Film to the Screen

Original address: https://glumes.com/dcp-digital-cinema-technology/

Recently, the animated film Niu Lai has sparked considerable discussion online.

Some discuss the visuals, some discuss the production, and some are curious: how exactly does such a film get into cinemas?

In fact, whether a film's production is refined or not is a different question from whether it can complete the technical delivery for cinemas.

This brings up a very interesting audio-video question:

Regardless of whether a film is exquisitely or simply made, what technical steps must it go through to actually be screened in a cinema?

Is it just copying an MP4 file onto a portable hard drive and handing it to the cinema staff to double-click and play?

Of course not.

In the standard digital cinema distribution chain, the task of film delivery is typically handled by the DCP, which stands for Digital Cinema Package.

Taking advantage of this 'cow' that suddenly barged into the cinema, let's talk about the DCP, MXF, JPEG 2000, PCM, KDM, and the digital cinema projection system behind the silver screen.

How a Film Enters the Cinema

Before we start, let's briefly string together the workflow from production to projection.

Figure: Simplified workflow from creative material to cinema projection

At the front is the relatively familiar production stage:

Obtain raw material through camera shooting or animation rendering;
Complete editing, VFX, color grading, subtitles, and multi-channel audio mixing, outputting the Digital Source Master (DSM);
In the DCI specification model, organize the DSM into a Digital Cinema Distribution Master (DCDM) that meets digital cinema requirements;
Encode the picture using JPEG 2000, then package the picture, sound, subtitles, and metadata into a DCP;
Deliver to the cinema via hard drive or network, where the cinema system handles import, verification, authorization, and playback.

DSM and DCDM describe different stages in the specification. When actually using DCP creation software, these conversions might be completed in a single export process, and a separate DCDM directory may not necessarily be seen.

It's important to note here that film content review, artistic quality, and technical delivery are three different things.

A public screening permit addresses the access issue, while the DCP addresses the technical delivery issue. It concerns itself with:

Whether the picture, sound, and subtitles have been delivered completely;
Whether cinema equipment from different manufacturers can recognize it;
Whether all tracks can synchronize accurately;
Whether encrypted content can be played on designated equipment within the authorized time window.

Why Cinemas Don't Use MP4 Directly

When we usually download a movie, the most common format is MP4.

It might use H.264 or H.265 to encode the picture, AAC to encode the sound, and then place the audio, video, subtitles, and timestamps into a single MP4 container.

This design is very suitable for phones, computers, TVs, and internet transmission, but cinema distribution faces a different set of requirements.

Figure: Comparison of uses between a regular MP4 and a digital cinema DCP

Common video codecs in MP4 like H.264 and H.265 typically use inter-frame compression. Decoding a specific frame might require referencing other frames before or after it. This method is highly efficient for compression and well-suited for online video.

DCP's picture, however, uses JPEG 2000. It takes a single frame as the basic coding unit, does not rely on long GOPs, making it easier to locate by frame and limiting the impact of local data errors to a smaller range. How the film is split into Reels, and which picture and sound assets each Reel uses, is organized jointly by the CPL and MXF Track Files.

It's not about which is 'superior', but that their design goals differ:

MP4 prioritizes universal playback, file size, and transmission efficiency;
DCP prioritizes image quality, stable projection, standardized delivery, interoperability, and content security.

So, a DCP is not a video codec, nor is it some special kind of MP4 container.

It is a complete cinema distribution package.

A DCP is Not a Single File, But a Set of Files

People opening a DCP directory for the first time are usually a bit confused.

Inside isn't a movie.dcp file, but a pile of XML and MXF files:

Figure: A simplified SMPTE DCP file structure

Different creation software, SMPTE DCPs, and older Interop DCPs may differ in file naming and subtitle organization. However, the core content of a common DCP can be roughly divided into the following categories.

ASSETMAP and VOLINDEX: Asset Map and Volume Information

ASSETMAP or ASSETMAP.xml acts as the asset index for the entire delivery package.

The cinema server uses it to find the assets within the package; if the index mentions a file that cannot be found on the actual medium, the verification tool should report an error. VOLINDEX is used to describe the position of the current medium within the complete set of delivery volumes. Although less prominent now, it remains part of the standard packaging structure.

PKL: Packing List

The PKL can be understood as a packing list.

It records the assets contained in the package, their file sizes, and hash information. When a cinema imports a DCP, this information can be used to determine if files are missing, corrupted, or have been accidentally modified.

It's important to note that the PKL is not a playback timeline. It focuses on 'what this delivery brought'.

CPL: Composition Playlist

The CPL is one of the most worthwhile XML files to study in the entire DCP.

It describes how a feature should be assembled and played back, including:

Which picture track to use;
Which sound track to use;
Whether subtitles are included;
How many Reels the feature is split into;
Where each Reel starts and its duration;
Information such as the title, version, and language of this Composition.

A single DCP can contain multiple CPLs. For example, if the picture is identical but the Mandarin, English, or subtitle versions differ, existing assets can be reused through different CPLs and supplemental packages.

The core reference relationships within a CPL can be simplified as follows:

<Reel>
  <AssetList>
    <MainPicture>
      <Id>urn:uuid:picture-track-id</Id>
    </MainPicture>
    <MainSound>
      <Id>urn:uuid:sound-track-id</Id>
    </MainSound>
    <MainSubtitle>
      <Id>urn:uuid:subtitle-track-id</Id>
    </MainSubtitle>
  </AssetList>
</Reel>

A real CPL will also include fields like namespaces, duration, Entry Point, Edit Rate, and hashes. The code above is only used to illustrate one thing: the CPL does not store the movie picture itself, but organizes the required Track Files through UUIDs.

Simply put:

The PKL cares about 'what's in the box', while the CPL cares about 'how these things should be played'.

MXF: Truly Carrying Picture and Sound

The large files with the .mxf extension are typically what actually occupies disk space.

MXF stands for Material eXchange Format. It is also a container format, not an encoding format.

In a DCP, picture and sound are generally not interleaved in the same file like a regular MP4, but exist as separate Track Files:

The picture MXF carries the JPEG 2000 bitstream;
The sound MXF carries linear PCM multi-channel audio;
SMPTE DCP Timed Text subtitles can also be placed in a separate MXF Track File.

This track-separated design makes it convenient to replace languages, subtitles, or a segment of material, and also facilitates reusing existing files between different versions.

DCP's Picture: JPEG 2000, 12-bit, and X′Y′Z′

Next, let's look at the core picture technology within a DCP.

Why JPEG 2000 is Used

When mentioning JPEG, many people's first reaction is .jpg images. But JPEG 2000 is not about continuously stuffing regular JPEG pictures into a movie file.

It uses wavelet transformation, and each frame can be encoded independently. Compared to the long GOPs of common H.264 and H.265, JPEG 2000 has several characteristics suitable for cinema:

Each frame is independent, facilitating precise positioning and random access;
No common chroma subsampling is performed; the three color components maintain the same resolution;
Supports 12-bit color component precision;
Can maintain visual quality close to the master at higher bitrates;
Even if a single frame's data has a problem, it won't continuously affect subsequent frames like a long GOP.

A common misconception needs correcting here:

The JPEG 2000 used in DCI digital cinema is typically not mathematically lossless compression, but aims for 'visually lossless' quality under normal cinema viewing conditions.

The DCI specification gives a maximum total bitrate for JPEG 2000 picture of 250 Mbit/s. This number is much larger than typical online video, which also explains why a feature-length DCP can easily exceed 100GB.

What 2K and 4K Actually Are

The common picture containers in digital cinema are not the 1920×1080 and 3840×2160 of everyday video.

Common Flat and Scope dimensions are as follows:

Aspect Ratio	2K	4K
Flat, approx. 1.85:1	1998×1080	3996×2160
Scope, approx. 2.39:1	2048×858	4096×1716

If the input is a 1920×1080 16:9 video being made into a 2K Flat DCP, the common practice is to maintain the aspect ratio and place the picture into the 1998×1080 Flat container, rather than simply stretching the picture horizontally.

Therefore, when creating a DCP, aspect ratio selection, cropping, and letterboxing/pillarboxing all require careful checking.

Why Not Common Y′CbCr and Rec.709

The most common processing chain for regular video is Y′CbCr, Rec.709, and 8-bit or 10-bit. In engineering, Y′CbCr is often loosely referred to as YUV, but strictly speaking, what is stored in digital video files is typically Y′CbCr data.

The DCDM image used in digital cinema employs encoded CIE XYZ tristimulus values, commonly represented as X′Y′Z′, with each component using 12-bit values.

The purpose of this is not for creators to edit directly in XYZ space, but to provide a unified digital cinema interchange standard for different cinema equipment.

In actual production, source material in Rec.709, P3, or other color spaces needs to undergo correct color conversion into the cinema's XYZ representation. The cinema's playback end then converts this data into light on the screen based on the calibrated projection system.

If the source file's color space is filled in incorrectly, even if the DCP can play normally, obvious color and brightness issues may occur.

Is DCP's Color Gamut Definitely Larger Than MP4's?

When talking about XYZ, it's easy to jump to an intuitive conclusion: DCP's color gamut must be larger than MP4's.

But strictly speaking, this question isn't comparing concepts on the same level.

JPEG 2000 is a picture encoding format, and MP4 is a container format; neither is responsible for defining the color gamut. An MP4 file can carry common Rec.709 video, as well as video in other color gamuts like Display P3 or BT.2020; JPEG 2000 similarly does not inherently equal DCI-P3, it's just that in a standard DCP, it is used together with 12-bit X′Y′Z′ color encoding.

If the comparison is limited to 'common online MP4' and 'standard SDR DCP', the two delivery chains can be understood as follows:

Comparison Item	Common Online MP4	Standard SDR DCP
Common Combination	MP4 + H.264/H.265	MXF + JPEG 2000
Color Representation	Typically Y′CbCr	X′Y′Z′
Common Gamut or Display Target	Mostly Rec.709, can also be P3, BT.2020	Aimed at calibrated DCI-P3 cinema projection environment
Common Bit Depth	8-bit or 10-bit	12-bit per component
Chroma Resolution	Common 4:2:0	Three color components maintain full resolution

There are three easily confused points here:

Bit depth does not equal color gamut. 12-bit primarily improves numerical precision, reducing banding and quantization errors in gradients, and does not independently push the boundaries of the color gamut outward;
Chroma subsampling also does not equal color gamut. Not using 4:2:0 can preserve more complete color spatial detail, but it won't magically add new representable colors;
Format conversion does not create colors. A source film containing only Rec.709 gamut content, even when converted to a 12-bit XYZ DCP, will not automatically gain P3 colors that weren't present in the original material.

So a more accurate conclusion is:

The DCP's advantage isn't that 'JPEG 2000 inherently has a larger color gamut', but that it uses a unified 12-bit XYZ interchange format, preserving higher precision for cinema color management. The final number of colors that can be presented still depends on the source material, the color grading process, and the projection equipment.

DCP's Sound: Not Just Changing the Suffix of AAC

The main sound track of a DCP typically uses uncompressed linear PCM:

24-bit bit depth;
48 kHz or 96 kHz sampling rate;
Supports multi-channel cinema sound;
Common versions include 5.1 and 7.1.

A distinction must be made here between 'what the system can support' and 'what the specific delivery specification allows'. DCI systems can support 48kHz or 96kHz audio, but the SMPTE Bv2.1 constraint for mainstream cinema delivery requires the use of 48kHz. In actual production, the specification and technical requirements adopted by the recipient should prevail.

Taking 5.1 channels as an example, they typically need to be correctly mapped to:

L    Left Channel
R    Right Channel
C    Center Channel
LFE  Low Frequency Effects Channel
Ls   Left Surround
Rs   Right Surround

Having the correct number of channels doesn't mean the channel mapping is necessarily correct.

If the center, LFE, or surround channels are placed incorrectly, the file might still be generated successfully, but the result heard in the cinema will be very strange. For cinema DCPs, sound checks are just as important as picture checks.

Furthermore, Dolby Atmos cannot be simply understood as 'stuffing a few more channels into a regular PCM MXF'. Object-based audio involves additional data, production workflows, and certified cinema playback systems, and cannot be conflated with regular 5.1 or 7.1 DCPs.

Why Subtitles Can Also Be a Source of Projection Accidents

DCP subtitles generally follow two approaches:

Burned directly into the picture;
Delivered as an independent Timed Text or subtitle track for the projection system to render.

The advantage of independent subtitles is the ability to reuse the picture, making it convenient to produce different language versions. But it also introduces new items to check:

Whether the font file is correctly embedded;
Whether Chinese characters can be displayed completely;
Whether the subtitle position falls within the safe area;
Whether the subtitle's in-point, out-point, and Reel boundaries are correct;
Whether the subtitle organization method matches SMPTE or Interop.

Therefore, subtitle DCPs are best checked thoroughly on an actual cinema server or a reliable verification/playback tool, not just considered done if they look fine in the editing software.

KDM: Adding a Time-Limited Digital Key to the Movie

DCPs used in commercial cinemas are often content-encrypted.

The film can be delivered to the cinema in advance, but only systems holding the corresponding device certificate and within the authorized time window can decrypt it. This is where the KDM, Key Delivery Message, is needed.

Figure: KDM binds the content key, target device, and validity period together

A KDM can be understood as a 'digital key letter' written to a specific cinema device.

It involves the following key pieces of information:

Which CPL it corresponds to, i.e., which Composition;
The encapsulated content key;
Which cinema Media Block or IMB's device certificate can receive it;
The authorization start and end time;
The message's own signature and certificate chain.

Therefore, a KDM is not a generic key to unlock the 'entire DCP package', but is generated for one CPL, one target device certificate, and one validity period. If a DCP contains multiple CPLs, corresponding KDMs may need to be generated separately.

Consequently, even if two cinemas receive the exact same encrypted DCP, Cinema A's KDM usually cannot be used in Cinema B.

Device mismatch, system time outside the authorization window, or incorrect certificate information can all prevent the film from being decrypted.

This also explains why sometimes a movie file has long been imported into the cinema, but technicians still need to wait for or update the KDM.

How a DCP is Played in the Cinema

Once the DCP arrives at the cinema, it cannot be projected onto the screen immediately.

A simplified projection workflow is roughly as follows:

Deliver the DCP to the cinema via professional hard drives, network, or other distribution systems;
The cinema management system reads the ASSETMAP, imports files like MXF, CPL, and PKL into storage, and checks integrity;
If the content is encrypted, import the KDM for the corresponding device and time period;
Organize advertisements, trailers, the feature, and automation events through a Show Playlist;
The Media Block or IMB decrypts and decodes the picture, sending PCM audio to the cinema audio processor;
The projector casts the picture onto the screen, while the SMS or cinema automation system controls equipment like lighting and masking according to the instructions in the Show Playlist.

So the cinema's 'player' is not a regular computer with VLC, but a whole system designed around stability, interoperability, security, and automation.

Hands-On: Creating a 30-Second DCP

Just talking about concepts isn't enough. This time, I actually used DCP-o-matic 2.19.1 to complete a minimal practice run from test video and DCP encoding to full verification.

A relatively beginner-friendly tool is DCP-o-matic. It can convert materials like MP4, MOV, image sequences, WAV, and subtitles into a DCP, and also provides a player and verification tools.

To make the experiment reproducible, I first used FFmpeg to generate a 30-second test clip: 1920×1080, 24fps, Rec.709, with 48kHz AAC stereo audio.

ffmpeg -hide_banner -y \
  -f lavfi -i "testsrc2=size=1920x1080:rate=24" \
  -f lavfi -i "sine=frequency=1000:sample_rate=48000" \
  -t 30 \
  -vf "setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709" \
  -c:v libx264 -preset veryfast -pix_fmt yuv420p \
  -x264-params "colorprim=bt709:transfer=bt709:colormatrix=bt709" \
  -c:a aac -b:a 192k -ar 48000 -ac 2 \
  -shortest demo.mp4

Here, Rec.709 color primaries, transfer characteristics, and matrix flags were explicitly written. This is because 'the picture looks like Rec.709' and 'the file correctly declares itself as Rec.709' are not the same thing; DCP creation software needs the input color space to perform the XYZ conversion.

You can first check the input file using ffprobe:

ffprobe -v error \
  -show_entries stream=codec_name,width,height,r_frame_rate,color_space,color_transfer,color_primaries,sample_rate,channels \
  -of default=noprint_wrappers=1 \
  demo.mp4

The key results detected this time were: H.264, 1920×1080, 24fps, BT.709, and 48kHz stereo AAC. After confirming the source file, proceed to DCP creation.

Creating Using the Graphical Interface

The basic steps are as follows:

Create a new Film project and add demo.mp4;
Check the source video frame rate, aspect ratio, and input color space;
Select SMPTE, 2K Flat, 24fps; for this test project, turn off encryption;
Check cropping, scaling, and audio channel mapping;
Click Make DCP to start encoding;
Use DCP-o-matic Player to open the generated result;
Execute Verify DCP to check for errors and warnings.

DCP-o-matic's verifier checks many easily overlooked issues, such as:

Whether files referenced by ASSETMAP exist;
Whether the hashes in the MXF and PKL match;
Whether the XML conforms to the corresponding structural definition;
Whether the JPEG 2000 single-frame data and audio bit depth meet requirements;
Whether the subtitle font and time range are correct.

Creating Using the Command Line

If DCP-o-matic is already installed, you can also use the command line to replicate the experiment. The tools in the macOS installation package are located in the application directory by default; actual paths will differ on Windows and Linux.

DCPOMATIC_APP="/Applications/DCP-o-matic 2.app/Contents/MacOS"

"$DCPOMATIC_APP/dcpomatic2_create" \
  -o dcp-demo \
  --twok \
  --container-ratio 185 \
  --dcp-frame-rate 24 \
  --standard SMPTE \
  --video-bit-rate 50 \
  --audio-channels 6 \
  --no-encrypt \
  -c TST \
  -n "DCP Demo" \
  --colorspace rec709 \
  demo.mp4

"$DCPOMATIC_APP/dcpomatic2_cli" dcp-demo

The first command creates an SMPTE, 2K, Flat, 24fps, unencrypted test project, and the second command starts the actual encoding. --colorspace rec709 is placed before the input file because this option describes the material that follows it.

The JPEG 2000 target bitrate was set to 50 Mbit/s here, mainly to control the test file's size; what really prevented the experiment from taking too long was using only 30 seconds of material. This setting does not imply that a formal cinema master can or should only use 50 Mbit/s. The DCI specification allows a maximum total picture bitrate of 250 Mbit/s; actual projects should decide based on source quality, content complexity, and delivery requirements.

What Was Actually Generated

This time, DCP-o-matic encoded a total of 720 frames. The software reported an encoding phase time of about 25 seconds, with the actual wall clock time for the command being about 27 seconds. This time only represents this specific test machine and material, and should not be taken as general performance data.

Figure: Summary of results from this DCP-o-matic conversion and verification

The final directory name was:

DcpDemo_TST-1_F-178_XX-XX_20_2K_20260817_SMPTE_OV

Where TST indicates test content, F-178 indicates a 1.78:1 active picture within a Flat container, and 2K, SMPTE, OV represent resolution, standard, and Original Version, respectively. Actual recipients may have their own naming conventions; the directory name alone cannot replace the CPL and technical checks.

After encoding is complete, you can enter the final DCP directory to view the file structure. You should typically see content similar to the following:

ASSETMAP.xml
VOLINDEX.xml
cpl_bb1ce77d-....xml
pkl_a72d889a-....xml
j2c_55f38dac-....mxf    approx. 178.8 MiB
pcm_dbd24a1b-....mxf    approx. 24.7 MiB

Including the XML files, the logical size of the main assets was about 204 MiB, while the source MP4 was only about 18.8 MiB. Even using a test bitrate of only 50 Mbit/s this time, the DCP volume was already about 10 times that of the source file.

ffprobe read the picture track as JPEG 2000, xyz12le, 1998×1080, 24fps; the sound track was 24-bit, 48kHz, 6-channel linear PCM.

There are two easily overlooked details here.

First, the source video was 1920×1080, but the 2K Flat storage resolution is 1998×1080. The CPL recorded both a Stored Area of 1998×1080 and an Active Area of 1920×1080, indicating the content was placed into the Flat container maintaining its original aspect ratio and was not stretched horizontally.

Second, the source file only had two channels (left and right), but the output MXF had 6 channels. Further inspection revealed that L and R had signals, while C, LFE, Ls, and Rs were all silent, corresponding to 51/L,R,-,-,-,- in the CPL. This test DCP can pass specification verification, but it simultaneously reminds us: 'The MXF has 6 channels' does not equal 'the content has completed a 5.1 mix'.

If FFmpeg is installed on the local machine, you can also use ffprobe to see basic information about the picture and audio MXFs:

ffprobe -hide_banner j2c_*.mxf
ffprobe -hide_banner pcm_*.mxf

However, ffprobe can only help us observe the media tracks and cannot replace a complete DCP specification verification. Checks on the CPL, PKL, ASSETMAP, subtitles, encryption, and the reference relationships between different assets must still be handed over to specialized DCP verification tools.

Performing a Full Verification Using Verifier

The DCP-o-matic Player installation package comes with a command-line verification tool. On macOS, it can be run like this:

PLAYER_APP="/Applications/DCP-o-matic 2 Player.app/Contents/MacOS"
DCP_DIR="dcp-demo/DcpDemo_TST-1_F-178_XX-XX_20_2K_20260817_SMPTE_OV"

"$PLAYER_APP/dcpomatic2_verify_cli" \
  -o verify.txt \
  "$DCP_DIR"

This time, the verifier checked items including the picture and sound MXFs, CPL, PKL, ASSETMAP, asset hashes, and JPEG 2000 frame bitrate, ultimately outputting:

DCP verified OK.

The report also confirmed several key facts: the CPL had only 1 Reel, the picture and sound durations were both 720 Edit Units, all assets were unencrypted, the CPL's hash in the PKL matched, the picture MXF's hash also matched, and the bitrate of each JPEG 2000 frame was below the 250 Mbit/s upper limit.

It must be emphasized that DCP verified OK means this test package passed the structural and specification checks performed by the tool; it does not mean it has completed cinema delivery acceptance. Subtitle appearance, loudness, channel intent, color, picture cropping, and target device compatibility still require manual checks and test screenings.

Additionally, although FFmpeg can handle JPEG 2000, PCM, and some MXF, generating a DCP that can stably enter various cinema servers is not just a matter of executing a single transcoding command. For actual delivery, it is more appropriate to use specialized DCP creation and verification tools.

What Else to Check Before Actual Cinema Delivery

Successfully playing it on your own computer does not equal being ready to confidently deliver it to cinema chains.

Verification tools mainly check file structure and specification issues. The following items, which involve creative intent and the target cinema, still require manual confirmation:

Whether the SMPTE or Interop standard, CPL naming, and version information meet the recipient's requirements;
Whether the Flat or Scope selection is correct, and if there is any incorrect cropping, stretching, or color conversion;
Whether the channel mapping, synchronization, playback level, and subtitle position meet expectations;
Whether the device certificate and KDM time window for an encrypted DCP are correct;
Whether a test screening has been completed at the target cinema or on compatible equipment.

This last item is particularly important.

Digital cinema specifications solve the compatibility problem between different systems, but in the real world, differences in cinema server versions, subtitle rendering, channel configuration, and projection presets still exist. For truly important films, the test screening cannot be skipped.

Back to Niu Lai

After discussing all this technology, looking back at Niu Lai makes things more interesting.

What the audience sees is the picture and story on the screen, but behind the scenes, the cinema sees a different set of things: JPEG 2000 picture tracks, PCM sound tracks, CPL playlists, PKL packing lists, subtitle files, and possibly KDMs.

A film's budget can be high or low; the picture can be refined or simple; the audience can like it or not.

But as long as it enters the standard digital cinema distribution process, it needs to cross a relatively rigorous technical threshold.

The DCP is not responsible for judging whether a film is art, nor is it responsible for guaranteeing box office success.

It is only responsible for one thing:

Delivering the correct picture and sound, at the correct time, to the correct cinema equipment, and playing it back stably.

This is probably the part most worth the attention of audio-video developers behind the Niu Lai buzz.

References

Comments

Top 1 from juejin.cn, machine-translated. The original thread is authoritative.

星河微尘

In-depth technical article, but the problems outside of technology are even harder to solve.