]>
<book xmlns="http://docbook.org/ns/docbook" xmlns:mml="http://www.w3.org/1998/Math/MathML" version="5.0" xml:lang="en">
-<!-- By good luck or good management, the scale parameter to imagedata
- appears only to affect PDF output. HTML scaling is done in the
- Makefile.
--->
-
<bookinfo>
<title>DCP-o-matic users' manual</title>
<author><firstname>Carl</firstname><surname>Hetherington</surname></author>
</section>
+
<section>
<title>Decrypting encrypted DCPs</title>
</section>
+<section>
+<title>Making a DCP from a DCP</title>
+
+<para>
+In many ways, using DCPs as <emphasis>content</emphasis> in
+DCP-o-matic is the same as using any other content. There are a few
+things to note, though.
+</para>
+
+
+<section>
+<title>Re-use of existing data</title>
+
+<para>
+Where possible DCP-o-matic will re-use existing JPEG2000-compressed
+data from DCP content without modification. This has the advantage
+that creation of the new DCP will be quick, as the time-consuming
+JPEG2000 encoding is not necessary.
+</para>
+
+<para>
+DCP-o-matic can do this if you avoid changes to the following content
+settings:
+</para>
+
+<itemizedlist>
+<listitem>Crop</listitem>
+<listitem>Scaling</listitem>
+<listitem>Subtitle burn-in</listitem>
+<listitem>Fades</listitem>
+<listitem>Colour conversion</listitem>
+</itemizedlist>
+
+<para>
+If you do change any of these settings on a piece of DCP content
+DCP-o-matic will decode and then re-encode the JPEG2000 data.
+</para>
+
+</section>
+
+
+<section>
+<title>Making overlay files</title>
+
+<para>
+With its default settings, DCP-o-matic will take any data from DCP
+content and copy it into the DCP that it creates. See <xref linkend="fig-dcp-copy"/>.
+</para>
+
+<figure id="fig-dcp-copy">
+<title>Creating a new DCP by copying an existing one</title>
+<mediaobject><imageobject><imagedata scale="100" fileref="diagrams/dcp-copy&dia;"/></imageobject></mediaobject>
+</figure>
+
+<para>
+This can be inefficient in some cases. Consider, for example, a film
+which has ten different translations for which the subtitles are
+different but video and audio are the same. If the video and audio
+content takes up, say, 100Gb this means that the set of DCPs for every
+translation would be about 1Tb with a lot of duplicated data.
+</para>
+
+<para>
+The DCP format has a solution to this problem. One DCP can refer to
+the ‘assets’ (picture, sound or subtitle) of another DCP.
+For our translation example this means that we could have a
+‘base’ DCP (often called the OV or Original Version)
+containing video, audio and one set of subtitles and then any number
+of overlay DCPs (often called VF or Version Files) which refer to the
+base version and replace the original subtitles with their own. <xref
+linkend="fig-dcp-refer"/> shows this principle for one of our
+translations. The DCP that we make refers to the original content
+DCP's video and audio rather than containing a copy.
+</para>
+
+<figure id="fig-dcp-refer">
+<title>Creating a new DCP by referring to an existing one</title>
+<mediaobject><imageobject><imagedata scale="100" fileref="diagrams/dcp-refer&dia;"/></imageobject></mediaobject>
+</figure>
+
+<para>
+To play back the subtitled DCP the projectionist ingests both the base
+(OV) DCP and the overlay (VF) DCP, then plays the VF one.
+</para>
+
+</section>
+
+</section>
+
+
</chapter>
<!-- ============================================================== -->
<title>Burnt-in subtitles</title>
<mediaobject>
<imageobject>
- <imagedata scale="80" fileref="diagrams/burn-in&dia;"/>
+ <imagedata scale="100" fileref="diagrams/burn-in&dia;"/>
</imageobject>
</mediaobject>
</figure>
<title>Separate subtitles</title>
<mediaobject>
<imageobject>
- <imagedata scale="80" fileref="diagrams/discrete&dia;"/>
+ <imagedata scale="100" fileref="diagrams/discrete&dia;"/>
</imageobject>
</mediaobject>
</figure>
<title>Timecode</title>
<mediaobject>
<imageobject>
- <imagedata fileref="diagrams/timecode&dia;"/>
+ <imagedata scale="100" fileref="diagrams/timecode&dia;"/>
</imageobject>
</mediaobject>
</figure>
<guilabel>Edit..</guilabel> button next to the key.
</para>
+<para>
+The <guilabel>Reels</guilabel> and <guilabel>Reel length</guilabel>
+controls specify how the DCP will be split up into
+‘reels’. See <xref linkend="sec-reels"/> below.
+</para>
+
<para>
The <guilabel>Standard</guilabel> option specifies which of the two
DCP standards DCP-o-matic should use. If in doubt, use SMPTE (the
</listitem>
</itemizedlist>
+<!-- ============================================================== -->
+<section xml:id="sec-reels">
+<title>Reels</title>
+
+<para>
+A ‘reel’ in a DCP is a subsection of the DCP, in the same
+way as a 35mm reel is a section of a film. A DCP can be split up into
+any number of reels and the joins (the equivalent to 35mm splices)
+between the reels are seamless.
+</para>
+
+<para>
+There is no reason why you can't just use a single reel for the whole
+of your DCP, as there is no limit on their length. Many people choose
+to do this.
+</para>
+
+<para>
+There are, however, some possible advantages of splitting things up
+into reels:
+</para>
+
+<itemizedlist>
+<listitem>
+The picture, sound and subtitle data of the DCP will be
+split up into more smaller files on disk, rather than fewer larger
+files. This can be useful if the DCP is to be transferred on storage
+that have file size limits. The FAT32 filesystem, for example, can
+only hold files smaller than 4Gb. A 6Gb DCP with a single reel could
+not be transferred using a FAT32-formatted disk. If that DCP were
+split up into two 3Gb reels it could be transferred.
+</listitem>
+<listitem>
+It is easier to re-use DCP components if they are in reels. Consider,
+for example, a film company who wants to put a 5 second ident onto the
+beginning of DCPs that they distribute. If they receive a feature
+film DCP they can modify it to add their ident as a separate reel.
+This is easier than attaching the picture data in the DCP.
+</listitem>
+</itemizedlist>
+
+<para>
+DCP-o-matic offers three options for setting up the reels in your DCP:
+single reel, split by video content or custom.
+</para>
+
+<para>
+<guilabel>Single reel</guilabel>, as its name suggests, keeps the whole DCP as one reel.
+This is a perfectly good option if you have no particular reason to
+need reels.
+</para>
+
+<para>
+<guilabel>Split by video content</guilabel> puts each piece of source
+video content in its own reel, as shown in <xref linkend="fig-reels-by-video"/>.
+</para>
+
+<figure id="fig-reels-by-video">
+<title>Making reels using split by video content</title>
+<mediaobject><imageobject><imagedata scale="100" fileref="diagrams/reels-by-video&dia;"/></imageobject></mediaobject>
+</figure>
+
+<para>
+Here we have three video files (<code>ident.mp4</code>,
+<code>feature.ts</code> and <code>cred.mov</code>). With
+<guilabel>split by video content</guilabel> DCP-o-matic makes a new
+reel to hold each video file.
+</para>
+
+<para>
+<guilabel>Custom</guilabel> splits reels by the size of the files that
+will make up their video content. With <guilabel>Custom</guilabel>
+you must specify a reel length in Gb. Then no file in the DCP will be larger than this reel length.
+</para>
+
+</section>
+
+
<!-- ============================================================== -->
<section>
<title>Show audio</title>
<title>Creating a new film</title>
<mediaobject>
<imageobject>
- <imagedata fileref="diagrams/file-structure&dia;"/>
+ <imagedata scale="100" fileref="diagrams/file-structure&dia;"/>
</imageobject>
</mediaobject>
</figure>
projects / dcpomatic.git / blobdiff