Skip to content

DCP: The Digital Cinema Package

A DCP is the theatrical deliverable muxed from the DCDM. Festival delivery requires decisions about format, resolution, audio, encryption, accessibility, transport, and QC. See Generalized Production Workflow for the mastering path.

What a DCP is

A DCP stores essence in MXF track files, assembles it with a CPL (Composition Playlist), inventories it with a PKL (Packing List), and locates it with an ASSETMAP. IMF later reused this architecture for mastering and distribution.1 DCP essence targets cinema playback:

Component Encoding
Picture JPEG 2000, intra-frame, 12-bit, in DCI X′Y′Z′: gamma 2.6, 48 cd/m² reference white (see Color Spaces). X′Y′Z′ is itself gamut-unbounded. The practical P3 limit is the projector's, not the container's
Audio 24-bit linear PCM, up to 16 channels at 48 or 96 kHz
Subtitles / captions SMPTE Timed Text (ST 428-7) or Interop XML, with PNG or font-rendered glyphs

What is actually in the folder

A DCP is a folder. Almost all of its size is a small number of very large MXF track files: the picture, the sound, and any subtitle or caption essence. The rest is three small XML files, together a few tens of kilobytes describing a few hundred gigabytes.

Those three are what people find confusing, because all three describe the same assets, for three different purposes:

File The question it answers What it records for each asset
ASSETMAP Where is it? The asset's UUID and its path on the delivered medium
PKL (Packing List) What is in this delivery, and did it arrive intact? UUID, file size, hash, and asset type
CPL (Composition Playlist) What plays, in what order? Which reel and role (picture, sound, or subtitle), plus the entry point and duration used from that file

Two distinctions matter:

  • The CPL is the version. The same track files with a different CPL is a different cut. That is how a version file (VF) reuses an original version's picture and sound without copying a byte of them, and it is the same idea IMF later built its supplemental packages on.
  • The PKL is an inventory, not a playlist. It can perfectly well list files that no CPL references, which is exactly why it exists as a separate document.

The ASSETMAP is neither. It is a lookup table that turns a UUID into a file path, so that a server handed a folder can find the assets the other two documents refer to.

Two package flavors exist:

  • Interop (IOP) is the older format. It supports fewer features but plays on legacy servers.
  • SMPTE DCP is the modern standardized format. High frame rates, immersive audio, and properly signalled closed captions require it.2

Default to SMPTE DCP using the Bv2.1 profile (SMPTE RDD 52:2020). Major festivals still accept Interop, but Venice prefers SMPTE and Berlinale recommends it. Use Interop only for a venue known to require legacy compatibility. Confirm the festival specification before authoring.

Resolution: 2K, 4K, and the bit-rate cap

DCPs come in two resolution classes, 2K and 4K, each with three containers. The rasters are fixed, and Flat is not the full width of the container:

Container 2K 4K
Flat (1.85:1) 1998 × 1080 3996 × 2160
Scope (2.39:1) 2048 × 858 4096 × 1716
Full (1.90:1) 2048 × 1080 4096 × 2160

DCI caps JPEG 2000 image essence at 250 Mbit/s for both 2K and 4K.7 A 4K DCP therefore spends the same data budget on four times the pixels.

A 4K DCP plays on a 2K projector. Do not author a separate 2K package for 2K screens. A 2K DCP likewise plays on 4K systems.

JPEG 2000 is resolution-scalable: a 4K codestream contains a complete 2K resolution level. A 2K server decodes that level without scaling or transcoding. This is single inventory: one package for both resolutions.

If the show finished in 4K, deliver 4K. The fixed bit-rate cap means the gain is smaller than the pixel count suggests and is most visible in detailed, high-contrast material. Deliver 2K when smaller transfers matter more. Either package remains broadly compatible.

Frame rates and the general-release envelope

For broad compatibility, follow SMPTE DCP Bv2.1: 2D 4K at 24 fps. SMPTE ST 429-2 permits 4K at 24, 25, or 30 fps, and DCI's 2024 HDR addendum permits 2D 4K at 48 or 60 fps with a 450 Mbit/s ceiling, but those modes fall outside the general-release profile. Stereoscopic DCP remains 2K.

Bv2.1 is an interoperability profile, not a physical limit. Dolby Cinema, IMAX, and other premium formats use private specifications that may exceed it. Get those specifications from the vendor.

Audio: channels and how it was mixed

DCP audio is discrete, uncompressed multichannel PCM, but how many channels, and how it was mixed, matter more than the container.

Prefer 5.1 over 2.0. Its center channel anchors dialogue to the screen for every seat. A 2.0 mix creates a phantom center that pulls toward the nearer speaker away from the room's centerline. Many festivals expect 5.1.

2.0 is not Dolby Stereo. LoRo is discrete left/right with no center or surround information. Lt/Rt is matrix-encoded and decodes to L, C, R, and surround. Identify a two-channel delivery explicitly. Treating one as the other misroutes dialogue and surround.

Mix for the theater, not the nearfield. Use a calibrated dubbing stage at reference level with the cinema X-curve (SMPTE ST 202 / ISO 2969).8 A nearfield mix usually plays too loud and bright in a theater. If theatrical exhibition is possible, budget a theatrical mix rather than a nearfield bounce.

Encrypted or unencrypted

An encrypted DCP uses AES-128. Playback requires a KDM (Key Delivery Message) encrypted to one server certificate and valid for a specified time window. An unencrypted DCP plays on any compliant server.

Choose encryption before authoring. Changing it later requires new MXF track files, CPL, PKL, hashes, and keys. The JPEG 2000 codestream need not be recompressed, but the package must still be rebuilt.

For festivals, default to unencrypted unless a right-holder requires encryption. Venice recommends unencrypted DCPs, Sundance strongly prefers them, and Berlinale accepts either.6 Encryption requires a certificate and time-limited KDM for every playback server. A wrong certificate, expired window, or last-minute room change prevents playback.

If encryption is required, confirm every server and screening window with the festival and arrange 24-hour key-management support.6

The KDM exchange. Keys are cut per server and per window, so a late room change means going back to the author for another one.

Accessibility: captions and described audio

Accessibility requirements vary sharply by festival:3

  • Sundance: English-language projects deliver both CCAP and OCAP DCPs. Non-English projects deliver standard subtitles plus English SDH.
  • SXSW: closed captions for every project. English subtitles for non-English content.
  • Hot Docs: closed captions for English-language features.
  • IFFR: SDH and audio description strongly encouraged.
  • Berlinale, Cannes, Venice, and Locarno: no published mandate.

Captions, for Deaf and hard-of-hearing viewers, come in two forms, and the DCP naming convention makes you declare which:4

  • OCAP (open captions) are always visible and require no venue hardware. They are the most reliable accessible screening format.
  • CCAP (closed captions) feed personal devices such as CaptiView readers or caption glasses. They work only when the venue has functioning caption hardware.

SDH differs from ordinary translation subtitles: beyond the dialogue, it carries speaker IDs and non-dialogue sound cues (music, effects).

Described audio (VI-N) narrates key visual action for blind and low-vision viewers. A separate Hearing Impaired (HI) track carries a dialogue-boosted mix. Map HI to channel 7 and VI-N to channel 8.2 Channel 15 carries sign-language video. Channels 9, 10, and 16 remain blank. Validate the channel map: a misplaced track can pass structural QC but never reach the assistive device.

Provide the tracks named in the festival specification. When venue capability is unknown, an OCAP version is the safest accessible deliverable because it requires no caption hardware.

Delivering to a festival

For physical delivery, use the medium and file system named by the festival. CRU DX115 drives remain common. USB 3.0 SSDs are increasingly accepted.6 For maximum server compatibility, format Linux ext2/ext3 with 128-byte inodes under ISDCF Doc 3. Some festivals also accept exFAT or NTFS.5

Electronic delivery is rising: Venice takes files by Aspera, Berlinale through its own Digital Cinema Portal, and services such as CineSend and Massive move DCPs over managed transfers.6 A feature DCP may be hundreds of gigabytes, so budget enough upload time and bandwidth to meet the deadline.

Name the package under the ISDCF Digital Cinema Naming Convention (DCNC).4 Write that name into ContentTitleText and, where used, AnnotationText inside the CPL and PKL. Renaming the folder alone does not change the title shown by a cinema server.

QC on a real cinema server

Before delivery, play the DCP from a cinema server through a cinema projector. Desktop playback does not prove that the package will ingest or screen correctly.

Run Video Village's DCP Inspector before the theater QC. It performs deep validation of the CPL, PKL, ASSETMAP, hashes, reel structure, frame rate, audio layout, and timed-text references. Validation catches structural faults but does not replace cinema-server playback.

Authoring through to delivery. A validator and a theater QC pass catch different classes of fault, and either can send the package back to authoring.

Common DCP authoring failures

Check these before delivery:

Validate before returning to the authoring vendor

DCP Inspector can repair many common CPL errors directly. Use it to validate and fix the package before sending it back to the authoring vendor or platform.

  • Naming: follow the ISDCF convention. Match the aspect-ratio token to the raster so the server selects the correct masking preset.

  • Content kind: match the CPL's ContentKind (feature, trailer, test, psa, and so on) to the composition name.

  • Leaders and markers: omit bars, tone, slates, countdowns, 2-pops, and tail pops. If used, keep FFOC and LFOC paired, ordered, and inside the correct reel.

  • Audio: use DCI channel order (L, R, C, LFE, Ls, Rs, HI, VI-N), confirm every track contains the intended mix, and check true peak for inter-sample clipping.

  • Timed text: start tracks at EntryPoint=0 and preserve the track structure across every reel. Interop OV and VF packages each need their own subtitle files and UUIDs.

  • Integrity and packaging: regenerate PKL hashes after any re-wrap, include every CPL-referenced asset, remove stray files, and apply encryption consistently.

  • Bit rate: check peak instantaneous rate, not only the average. Detailed frames can exceed the cap and stutter even when the package average is compliant.

Validation catches structural errors. Theater QC confirms presentation.

A theater QC pass on a DCI media block (Dolby, GDC, Sony, Barco Alchemy, Qube) and projector is the only place to catch:

  • Ingest and validation errors, and Interop/SMPTE incompatibilities with a particular server generation.
  • Audio channel mapping. Verify that center, surrounds, LFE, HI, and VI-N land where they should, not rotated or swapped.
  • Subtitle and caption rendering. Check timing, position, glyphs, and, for CCAP, that the captions reach the seat device in sync.
  • Framing and masking: the right aspect, no cropping, correct Flat/Scope container.
  • Frame-rate support, dropped frames, and audio-video sync across the whole runtime.
  • KDM validity. For encrypted packages, confirm that the key opens on that server within the window.

Play the film start to finish. Listen to the full mix and verify captions on the actual assistive device.

Delivery checklist

  • Decide encryption early, and default to unencrypted for festivals unless a rights-holder demands otherwise.
  • Plan accessibility early. Author OCAP/SDH and described-audio assets at the correct frame rate before festival deadlines.
  • Get each festival's exact spec first. "A DCP" is not a specification: Interop vs SMPTE, media and delivery method, naming, and which accessibility tracks all need to be settled before mastering.
  • QC on real hardware. A desktop player proves the package parses. Only a cinema server proves it screens.

  1. DCP packaging is defined by ST 429-7 (CPL), ST 429-8 (PKL), and ST 429-9 (ASSETMAP). IMF later reused the model. See SMPTE OV 2067-0 and the Library of Congress format description. ↩

  2. DTDC, Recommended Guidelines for Digital Cinema Source and DCP Content Delivery v4.08 (2019). DCP is defined by SMPTE ST 428, ST 429, and the DCI Digital Cinema System Specification. ↩↩

  3. Festival accessibility requirements, verified July 2026: Sundance · Hot Docs · IFFR. The SXSW figures come from the specification it sends accepted projects rather than a public document. SXSW publishes only that a DCP is required. TIFF publishes nothing at all and issues requirements privately, so treat any second-hand statement of its caption policy with caution. ↩

  4. ISDCF, Open and Closed Captions and the Digital Cinema Naming Convention. ↩↩

  5. ISDCF Doc 3 recommends ext2/ext3 with 128-byte inodes. Modern Linux defaults to 256-byte inodes, which some older servers reject. DCI does not specify a delivery-drive file system. ↩

  6. Published festival specifications, verified July 2026: Venice · Berlinale · Marché du Film · Locarno · Sundance. Specifications change yearly: confirm the current edition before mastering. Note that Sundance's detailed technical PDF has not been refreshed since 2023. TIFF, Tribeca, Cannes Official Selection and SXSW publish no DCP specification at all. requirements are issued privately after invitation. Anything attributed to those festivals here comes from a specification supplied to an accepted project, not from a public document. ↩↩↩↩

  7. The DCI specification caps 2K and 4K JPEG 2000 at 250 Mbit/s. DCSS §4.3.1 and ST 429-2 §8.3 define the rasters. DCI's HDR D-Cinema Addendum v1.2.1 (2024) raises the ceiling to 450 Mbit/s for 2D 4K at 48/60 fps. ↩

  8. Reference monitoring level (85 dB SPL per channel) and the cinema X-curve are standardized in SMPTE ST 202 / ISO 2969. DCP audio channel layouts (5.1, 7.1, and the HI/VI assignments) are covered in the DTDC delivery guidelines. Dolby Stereo Lt/Rt is the historical matrix-encoded two-channel theatrical format. ↩