从《牛来》到 DCP：一部电影是怎么走进电影院的？

原文地址：glumes.com/dcp-digital...

最近，动画电影《牛来》在网络上引起了不少讨论。

有人讨论画面，有人讨论制作，也有人好奇：这样的影片究竟是怎么进入电影院的？

其实，电影制作得精不精致，和它能不能完成影院技术交付，是两个不同的问题。

这也带出了一个很有意思的音视频问题：

不管一部电影制作精良还是朴素，它究竟要经过哪些技术环节，才能真正进入电影院播放？

难道是把一个 MP4 文件拷到移动硬盘里，再交给电影院的工作人员双击播放吗？

当然不是。

在标准数字影院发行链路里，真正承担电影交付任务的通常是 DCP ，全称是 Digital Cinema Package，也就是数字电影包。

借着这头突然闯进电影院的"牛"，接下来聊聊银幕背后的 DCP、MXF、JPEG 2000、PCM、KDM，以及数字影院放映系统。

一部电影是怎样进入电影院的

在开始之前，先把电影从制作到放映的流程简单串起来。

图：电影从创作素材到影院放映的简化流程

最前面是大家相对熟悉的制作阶段：

1. 通过摄影机拍摄或者动画渲染得到原始素材；
2. 完成剪辑、特效、调色、字幕和多声道混音，输出数字源母版 DSM；
3. 在 DCI 规范模型中，将 DSM 整理为满足数字影院要求的 DCDM；
4. 对画面进行 JPEG 2000 编码，再把画面、声音、字幕和元数据打包成 DCP；
5. 通过硬盘或网络交付影院，由影院系统完成导入、校验、授权和放映。

DSM 和 DCDM 描述的是规范中的不同阶段。实际使用 DCP 制作软件时，这些转换可能在一次导出过程中完成，并不一定会看到一个单独的 DCDM 目录。

这里需要注意的是，电影内容审核、艺术质量和技术交付是三件不同的事情。

公映许可解决的是准入问题，DCP 解决的是技术交付问题。它关心的是：

• 画面、声音和字幕有没有完整交付；
• 不同厂商的影院设备能不能识别；
• 各条轨道能不能准确同步；
• 加密内容能不能在指定设备和授权时间内播放。

电影院为什么不直接使用 MP4

我们平时下载一部电影，最常见的就是 MP4。

它可能使用 H.264 或 H.265 编码画面，使用 AAC 编码声音，然后把音视频、字幕和时间戳放进同一个 MP4 容器里。

这样的设计非常适合手机、电脑、电视和互联网传输，但影院发行面对的是另一套需求。

图：普通 MP4 与数字电影 DCP 的用途对比

MP4 中常见的 H.264、H.265 视频通常会使用帧间压缩。解码某一帧时，可能需要参考前后的其他帧。这种方式压缩效率很高，很适合网络视频。

DCP 的画面则使用 JPEG 2000。它以单帧为基本编码单位，不依赖很长的 GOP，更方便按帧定位，也能把局部数据错误的影响限制在较小范围内。至于影片怎样被拆成 Reel、每个 Reel 使用哪些画面和声音，则由 CPL 和 MXF Track File 共同组织。

两者并不是谁更"高级"，而是设计目标不同：

• MP4 更重视通用播放、体积和传输效率；
• DCP 更重视画质、稳定放映、标准交付、互操作和内容安全。

所以，DCP 不是一种视频编码，也不是某种特殊的 MP4 容器。

它是一套完整的影院发行包。

DCP 不是一个文件，而是一组文件

第一次打开 DCP 目录的人，通常会有点懵。

里面不是一个 movie.dcp，而是一堆 XML 和 MXF 文件：

图：一份简化后的 SMPTE DCP 文件结构

不同制作软件、SMPTE DCP 和较早的 Interop DCP，在文件命名和字幕组织方式上会有差异。不过，一份常见 DCP 的核心内容大致可以分成下面几类。

ASSETMAP 与 VOLINDEX：资产地图和分卷信息

ASSETMAP 或者 ASSETMAP.xml 相当于整个交付包的资产索引。

影院服务器通过它找到包中的资产；如果索引提到了某个文件，实际介质中却找不到，验证工具就应该报告错误。VOLINDEX 则用来描述当前介质在整套交付卷中的位置，现在虽然不太显眼，但仍属于标准打包结构的一部分。

PKL：Packing List

PKL 可以理解成装箱单。

它记录包中包含的资产、文件大小和摘要信息。影院导入 DCP 时，可以借助这些信息判断文件有没有缺失、损坏或者被意外修改。

需要注意，PKL 不是播放时间线。它关注的是"这次交付带来了什么"。

CPL：Composition Playlist

CPL 是整个 DCP 中最值得研究的 XML 文件之一。

它描述一部影片应该如何被组合和播放，包括：

• 使用哪一条画面轨；
• 使用哪一条声音轨；
• 是否带字幕；
• 影片被拆成几个 Reel；
• 每个 Reel 从哪里开始、持续多长时间；
• 这份 Composition 的标题、版本和语言等信息。

一套 DCP 中可以存在多个 CPL。比如画面完全相同，但普通话、英语或者字幕版本不同，就可以通过不同 CPL 和补充包复用已有资产。

CPL 中的核心引用关系可以简化成下面这样：

<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>

真实 CPL 还会包含命名空间、时长、Entry Point、Edit Rate 和摘要等字段。上面的代码只用来说明一件事：CPL 自己不保存电影画面，而是通过 UUID 把需要的 Track File 组织起来。

简单来说：

PKL 关心"箱子里装了什么"，CPL 关心"这些东西应该怎样播放"。

MXF：真正承载画面和声音

扩展名为 .mxf 的大文件通常是真正占据磁盘空间的部分。

MXF 全称是 Material eXchange Format。它也是一种封装格式，不是编码格式。

在 DCP 中，画面和声音一般不会像普通 MP4 那样交织在同一个文件里，而是分别作为独立的 Track File：

• 画面 MXF 中承载 JPEG 2000 码流；
• 声音 MXF 中承载线性 PCM 多声道音频；
• SMPTE DCP 的 Timed Text 字幕也可以放在独立的 MXF Track File 中。

这种分轨设计方便替换语言、字幕或某一段素材，也方便不同版本之间复用已有文件。

DCP 的画面：JPEG 2000、12-bit 和 X′Y′Z′

接下来看看 DCP 中最核心的画面技术。

为什么使用 JPEG 2000

提到 JPEG，很多人第一反应是 .jpg 图片。但 JPEG 2000 并不是把普通 JPEG 图片连续塞进电影文件。

它使用小波变换，每一帧都可以独立编码。与常见 H.264、H.265 的长 GOP 相比，JPEG 2000 有几个适合影院的特点：

• 每帧独立，方便精确定位和随机访问；
• 不进行常见的色度子采样，三个颜色分量保持相同分辨率；
• 支持 12-bit 的颜色分量精度；
• 可以在较高码率下保持接近母版的视觉质量；
• 即使单帧数据出现问题，也不会像长 GOP 那样持续影响后续多帧。

这里还要纠正一个容易出现的说法：

DCI 数字电影所使用的 JPEG 2000 通常不是数学意义上的无损压缩，而是以正常影院观看条件下"视觉无损"为目标。

DCI 规范给出的 JPEG 2000 画面最大总码率为 250 Mbit/s。这个数字比日常网络视频大得多，也解释了为什么一部长片 DCP 很容易超过 100GB。

2K 和 4K 到底是多少

数字影院常见的画面容器不是日常视频里的 1920×1080 和 3840×2160。

常见的 Flat 和 Scope 尺寸如下：

画幅	2K	4K
Flat，约 1.85:1	1998×1080	3996×2160
Scope，约 2.39:1	2048×858	4096×1716

如果输入是一段 1920×1080 的 16:9 视频，制作成 2K Flat DCP 时，常见做法是保持宽高比，把画面放进 1998×1080 的 Flat 容器，而不是简单地把画面横向拉伸。

所以在制作 DCP 时，画幅选择、裁剪和黑边处理都需要认真检查。

为什么不是常见的 Y′CbCr 和 Rec.709

普通视频最常见的处理链路是 Y′CbCr、Rec.709 和 8-bit 或 10-bit。工程中经常把 Y′CbCr 笼统称为 YUV，但严格来说，数字视频文件里存储的通常是 Y′CbCr 数据。

数字影院使用的 DCDM 图像则采用经过编码的 CIE XYZ 三刺激值，也就是常见的 X′Y′Z′ 表示，每个分量使用 12-bit 数值。

这样做的目的不是让创作者直接在 XYZ 空间里剪片，而是为不同影院设备提供统一的数字电影交换标准。

实际制作时，一段 Rec.709、P3 或其他色彩空间的源素材，需要经过正确的色彩转换进入数字影院的 XYZ 表示。影院播放端再根据经过校准的放映系统，把这些数据变成银幕上的光。

如果源文件的色彩空间填错了，即使 DCP 能正常播放，也可能出现明显的颜色和亮度问题。

DCP 的色域一定比 MP4 更大吗

讲到 XYZ，很容易得出一个直觉结论：DCP 的色域一定比 MP4 更大。

但严格来说，这个问题比较的不是同一层概念。

JPEG 2000 是画面编码格式，MP4 是容器格式，它们本身都不负责规定色域。一个 MP4 文件既可以承载常见的 Rec.709 视频，也可以承载 Display P3、BT.2020 等其他色域的视频；JPEG 2000 同样不天然等于 DCI-P3，只是在标准 DCP 中，它与 12-bit X′Y′Z′ 色彩编码一起使用。

如果把比较对象限定为"常见网络 MP4"和"标准 SDR DCP"，两条交付链路可以这样理解：

对比项	常见网络 MP4	标准 SDR DCP
常见组合	MP4 + H.264/H.265	MXF + JPEG 2000
色彩表示	通常为 Y′CbCr	X′Y′Z′
常见色域或显示目标	多数为 Rec.709，也可以是 P3、BT.2020	面向经过校准的 DCI-P3 影院放映环境
常见位深	8-bit 或 10-bit	每个分量 12-bit
色度分辨率	常见 4:2:0	三个颜色分量保持完整分辨率

这里有三个容易混淆的地方：

1. 位深不等于色域。 12-bit 主要提高数值精度，减少渐变中的色带和量化误差，并不会单独把色域边界向外扩张；
2. 色度采样也不等于色域。 不使用 4:2:0 可以保留更完整的色彩空间细节，但不会凭空增加新的可表示颜色；
3. 格式转换不会创造颜色。 一段只包含 Rec.709 色域内容的源片，即使转换成 12-bit XYZ DCP，也不会自动获得原素材中不存在的 P3 颜色。

所以更准确的结论是：

DCP 的优势不在于"JPEG 2000 天生拥有更大色域"，而在于它使用统一的 12-bit XYZ 交换格式，为影院色彩管理保留了更高的精度。最终能够呈现多少颜色，仍然取决于源素材、调色过程和放映设备。

DCP 的声音：不是把 AAC 换一个后缀

DCP 的主声音轨通常使用未压缩的线性 PCM：

• 24-bit 位深；
• 48 kHz 或 96 kHz 采样率；
• 支持多声道影院声音；
• 常见版本包括 5.1 和 7.1。

这里还要区分"系统能够支持"和"具体交付规范允许"。DCI 系统可以支持 48kHz 或 96kHz 音频，但面向主流影院交付的 SMPTE Bv2.1 约束要求使用 48kHz。实际制作时，应以接收方采用的规范和技术要求为准。

以 5.1 声道为例，通常要正确映射到：

L    左声道
R    右声道
C    中置声道
LFE  低频效果声道
Ls   左环绕
Rs   右环绕

声道数量正确，不代表声道映射一定正确。

如果把中置、LFE 或环绕声道放错位置，文件仍然可能成功生成，但在影院里听到的结果会非常奇怪。对于影院 DCP 来说，声音检查和画面检查同样重要。

另外，Dolby Atmos 也不能简单理解成"在普通 PCM MXF 里多塞几个声道"。对象音频会涉及额外的数据、制作流程和经过认证的影院播放系统，不能与普通 5.1、7.1 DCP 混为一谈。

字幕为什么也会成为放映事故来源

DCP 字幕通常有两种思路：

1. 直接烧录到画面中；
2. 作为独立的 Timed Text 或字幕轨交给放映系统渲染。

独立字幕的好处是可以复用画面，方便制作不同语言版本。但它也会带来新的检查项目：

• 字体文件有没有正确嵌入；
• 中文字符能不能被完整显示；
• 字幕位置是否落在安全区域；
• 字幕的入点、出点和 Reel 边界是否正确；
• SMPTE 和 Interop 字幕的组织方式是否匹配。

因此，字幕 DCP 最好在实际影院服务器或者可靠的验证、播放工具中完整检查一遍，不能只在剪辑软件里看着没问题就算结束。

KDM：给电影加一把有时效的数字钥匙

商业院线使用的 DCP 常常会进行内容加密。

影片可以提前送到影院，但只有处于授权时间窗口内、持有对应设备证书的系统才能解密。这时候就需要 KDM，Key Delivery Message。

图：KDM 将内容密钥、目标设备和有效时间绑定在一起

可以把 KDM 理解成一封写给指定影院设备的"数字钥匙信"。

它会涉及下面几项关键内容：

• 对应哪一个 CPL，也就是哪一份 Composition；
• 经过封装的内容密钥；
• 哪一台影院 Media Block 或 IMB 的设备证书可以接收；
• 授权从什么时间开始，到什么时间结束；
• 消息本身的签名和证书链。

因此，一个 KDM 不是笼统地给"整包 DCP"开锁，而是面向一个 CPL、一个目标设备证书和一段有效时间生成。一个 DCP 如果包含多个 CPL，可能需要分别生成对应的 KDM。

因此，即使两家影院拿到了完全相同的加密 DCP，A 影院的 KDM 通常也不能拿到 B 影院使用。

设备不匹配、系统时间不在授权窗口内、证书信息错误，都可能导致影片无法解密。

这也解释了为什么有时候电影文件早就导入影院了，但技术人员仍然需要等待或者更新 KDM。

DCP 在影院里是怎样被播放的

DCP 到达影院后，还不能马上投到银幕上。

一套简化后的放映流程大致如下：

1. 通过专业硬盘、网络或其他分发系统把 DCP 送到影院；
2. 影院管理系统读取 ASSETMAP，将 MXF、CPL 和 PKL 等文件导入存储，并检查完整性；
3. 如果内容已经加密，再导入对应设备和时间段的 KDM；
4. 通过 Show Playlist 把广告、预告片、正片和自动化事件组织起来；
5. Media Block 或 IMB 解密并解码画面，把 PCM 音频送给影院音频处理器；
6. 放映机将画面投到银幕上，SMS 或影院自动化系统则按照 Show Playlist 中的指令控制灯光、遮幅等设备。

所以影院的"播放器"并不是一台普通电脑加 VLC，而是一整套围绕稳定性、互操作、安全和自动化设计的系统。

动手制作一个 30 秒的 DCP

只讲概念还是不够。这次我实际使用 DCP-o-matic 2.19.1，完成了一次从测试视频、DCP 编码到完整验证的最小实践。

比较适合入门的工具是 DCP-o-matic。它可以把 MP4、MOV、图片序列、WAV 和字幕等素材转换成 DCP，也提供播放器和验证工具。

为了让实验可以复现，我先用 FFmpeg 生成了一段 30 秒测试片：1920×1080、24fps、Rec.709，音频为 48kHz AAC 双声道。

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

这里显式写入了 Rec.709 的色彩原色、传递特性和矩阵标记。因为"画面看起来像 Rec.709"和"文件正确声明自己是 Rec.709"不是一回事，DCP 制作软件需要根据输入色彩空间完成 XYZ 转换。

可以先用 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

这次探测到的关键结果是：H.264、1920×1080、24fps、BT.709，以及 48kHz 双声道 AAC。确认源文件以后，再进入 DCP 制作。

使用图形界面制作

基本步骤如下：

1. 新建 Film 项目并添加 demo.mp4；
2. 检查源视频帧率、画幅和输入色彩空间；
3. 选择 SMPTE、2K Flat、24fps，测试项目先关闭加密；
4. 检查裁剪、缩放和音频声道映射；
5. 点击 Make DCP 开始编码；
6. 使用 DCP-o-matic Player 打开生成结果；
7. 执行 Verify DCP，检查错误和警告。

DCP-o-matic 的验证器会检查很多容易被忽略的问题，比如：

• ASSETMAP 引用的文件是否存在；
• MXF 与 PKL 中的摘要是否一致；
• XML 是否符合对应的结构定义；
• JPEG 2000 单帧数据和音频位深是否符合要求；
• 字幕字体和时间范围是否正确。

使用命令行制作

如果已经安装 DCP-o-matic，也可以使用命令行复现实验。macOS 安装包中的工具默认位于应用程序目录；Windows、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

第一条命令创建一个 SMPTE、2K、Flat、24fps、未加密的测试项目，第二条命令开始实际编码。--colorspace rec709 放在输入文件之前，是因为这个选项描述的是紧随其后的素材。

这里把 JPEG 2000 目标码率设为 50 Mbit/s，主要是为了控制测试文件的体积；真正让实验不必等待太久的，是只使用了 30 秒素材。这个设置不代表正式影院母版只能或应该使用 50 Mbit/s。DCI 规范允许的画面总码率上限是 250 Mbit/s，实际项目应根据片源质量、内容复杂度和交付要求决定。

实际生成了什么

这次 DCP-o-matic 共编码 720 帧，软件报告编码阶段用时约 25 秒，命令的实际墙钟时间约 27 秒。这个时间只代表本次测试机器和素材，不能当作通用性能数据。

图：本次 DCP-o-matic 转换和验证的结果摘要

最终目录名称为：

DcpDemo_TST-1_F-178_XX-XX_20_2K_20260817_SMPTE_OV

其中 TST 表示测试内容，F-178 表示 Flat 容器中的 1.78:1 有效画面，2K、SMPTE、OV 分别表示分辨率、标准和 Original Version。实际接收方可能有自己的命名约定，不能只凭目录名代替 CPL 和技术检查。

编码完成后，可以进入最终 DCP 目录查看文件结构。通常可以看到类似下面的内容：

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

加上 XML 文件后，主要资产的逻辑大小约为 204 MiB，而源 MP4 只有约 18.8 MiB。即使这次只使用 50 Mbit/s 的测试码率，DCP 体积也已经是源文件的 10 倍左右。

ffprobe 读到的画面轨是 JPEG 2000、xyz12le、1998×1080、24fps；声音轨则是 24-bit、48kHz、6 声道线性 PCM。

这里有两个容易被忽略的细节。

第一，源视频是 1920×1080，但 2K Flat 的存储画幅是 1998×1080。CPL 同时记录了 1998×1080 的 Stored Area 和 1920×1080 的 Active Area，说明内容保持原始宽高比放进了 Flat 容器，并没有被横向拉伸。

第二，源文件只有左右两个声道，输出 MXF 却是 6 声道。进一步检查发现 L、R 有信号，C、LFE、Ls、Rs 均为静音，对应 CPL 中的 51/L,R,-,-,-,-。这份测试 DCP 能通过规范验证，但它同时提醒我们："MXF 是 6 声道"不等于"内容已经完成 5.1 混音"。

如果本机安装了 FFmpeg，也可以使用 ffprobe 看看画面和音频 MXF 的基础信息：

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

不过，ffprobe 只能帮助我们观察媒体轨道，不能代替完整的 DCP 规范验证。CPL、PKL、ASSETMAP、字幕、加密和不同资产之间的引用关系，仍然要交给专门的 DCP 验证工具检查。

使用 Verifier 做完整验证

DCP-o-matic Player 安装包中带有命令行验证工具。在 macOS 上可以这样运行：

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"

这次验证器检查了画面和声音 MXF、CPL、PKL、ASSETMAP、资产摘要、JPEG 2000 帧码率等项目，最终输出：

DCP verified OK.

报告还确认了几个关键事实：CPL 中只有 1 个 Reel，画面和声音时长都是 720 个 Edit Unit，所有资产均未加密，CPL 在 PKL 中的摘要能够匹配，画面 MXF 的摘要也能匹配，而且每帧 JPEG 2000 码率均低于 250 Mbit/s 上限。

需要强调，DCP verified OK 表示这份测试包通过了工具执行的结构和规范检查，不等于它已经完成影院交付验收。字幕观感、响度、声道意图、色彩、画面裁切和目标设备兼容性，仍然需要人工检查和测试放映。

另外，虽然 FFmpeg 能处理 JPEG 2000、PCM 和部分 MXF，但生成一套能够稳定进入不同影院服务器的 DCP，不只是执行一次转码命令那么简单。实际交付时更适合使用专门的 DCP 制作与验证工具。

真正交付影院前还要检查什么

自己在电脑上成功播放，并不等于已经可以放心交付院线。

验证工具主要检查文件结构和规范问题，下面这些涉及创作意图和目标影院的内容，仍然需要人工确认：

• SMPTE 或 Interop、CPL 命名和版本信息是否符合接收方要求；
• Flat 或 Scope 选择是否正确，有没有错误裁剪、拉伸或色彩转换；
• 声道映射、同步、播放电平和字幕位置是否符合预期；
• 加密 DCP 的设备证书与 KDM 时间窗口是否正确；
• 是否在目标影院或兼容设备上完成过测试放映。

最后这一项尤其重要。

数字电影规范解决了不同系统之间的兼容问题，但现实世界里仍然会存在影院服务器版本、字幕渲染、声道配置和放映预设等差异。真正重要的影片，不能省掉测试放映。

再回到《牛来》

聊完这些技术，再回头看《牛来》，事情就变得更有意思了。

观众看到的是银幕上的画面和故事，影院背后看到的却是另一套东西：JPEG 2000 画面轨、PCM 声音轨、CPL 播放列表、PKL 装箱单、字幕文件，以及可能存在的 KDM。

一部电影的预算可以高，也可以低；画面可以精致，也可以朴素；观众可以喜欢，也可以不喜欢。

但只要它进入标准数字影院发行流程，就需要跨过一套相对严谨的技术门槛。

DCP 不负责判断电影是不是艺术，也不负责保证票房。

它只负责一件事：

把正确的画面和声音，在正确的时间，送到正确的影院设备，并且稳定地播放出来。

这大概就是《牛来》这个热点背后，最值得音视频开发者关注的部分。

参考

1. Digital Cinema Initiatives：Digital Cinema System Specification
2. Library of Congress：Digital Cinema Initiative Distribution Package
3. DCP-o-matic Users' Manual
4. DCP-o-matic：Creating a DCP from a video
5. DCP-o-matic：Verifying DCPs
6. DCP-o-matic：Flat 与 Scope 画面尺寸说明