We made a lot of DCPs for my most recent film project 6Below. These included the final ones that were delivered to Deluxe and the theaters at release. Creating DCPs can still be a bit of a workflow challenge, but the options available are much better than they were in the past. Our initial tests of Wraptor DCP, which is included with Premiere Pro, were not very promising, for a number of reasons. We were looking for 4K DCPs with 7.1 audio, and the included plugin is limited to 2K at 5.1 audio. We did some tests with the Wraptor Pro plugin, but eventually determined that the free program DCP-O-Matic was the best solution for us. I am writing about both the workflow that we actually used, and the workflow I would recommend in hindsight, with the benefit of the experiences I have had since then.
There are four significant steps for creating a DCP from a 23.976p timeline in Premiere. First, the output must be converted to true 24p, either by duplicating every thousandth frame, or speeding up the picture and audio by 100.1%. Next, the image must be converted from your editing color space (usually Rec.709, but could be Rec.2020 or DCI-P3) to CIE XYZ colorspace. Third, the image must be encoded as a very specific flavor of JPEG2000 file. (JPEG2000 is a very flexible data compression architecture, allowing a variable number of channels, from single for RAW images, to 3 channels for RGB images, to 7 or more for other scientific or research applications.) Optionally the encoded file can be encrypted for secure delivery and playback control. Lastly the JPEG2000 files need to be wrapped in MXF files with a number of other metadata files to make the complete Digital Cinema “Package.”
It would be great if there were check boxes for all four of those things in Adobe Media Encoder, but that is not currently the case. Wraptor coverts to XYZ and encodes to JPEG2000, but there are some issues with the wrapping, and it doesn’t handle the 23.976p->24p conversion very well. The default JPEG2000 MXF encoder doesn’t do the speed change, the XYZ color space, or the wrapping. Fjord’s plugin bypasses the speed issue, does the XYZ conversion and the JPEG2000 encoding, but doesn’t encrypt or wrap the files. So clearly another solution is required. Enter DCP-O-Matic, a free open source DCP creation tool-set. It can take care of each of those steps in the process, but there are more efficient ways to utilize it in a hybrid workflow.
For 6Below, we edited at 4Kp23.976 so the first step was that we needed to speed everything up 100.1% to get it to exactly 24p for the DCP export. There are a variety of ways to do this, but the approach I used was to export 4K DPXs from the 23.976p project, import them into a new project reinterpreted to 24p. (The DPXs were a required deliverable anyway.) Then after syncing the audio, I exported a 4K Cineform file at 24p with 8 channels of audio to use in DCP-O-Matic to encode to the required JPEG2000 in XYZ colorspace. The resulting file took 30 hours to encode in 4K, but gave us a final DCP for delivery. Edits to the finished piece could be made without re-encoding the entire thing, due to the fact that DCP-O-Matic can edit JPEG2000 files natively, without re-encoding them.
With the benefit of another year of experience and many DCPs made, there is an even better way to go. Exporting DCP compliant .J2C files directly out of Adobe Media encoder is possible with this free JPEG2000 plugin from Fjord software. Using that to export directly out of a 23.976p sequence allows one to bypass the 24p issue for the moment because it is a frame sequence, and get the content into the XYZ colorspace and encoded to JPEG2000.
Those files can be imported into DCP-O-Matic for the much faster encryption and wrapping stages. The audio still needs to be handled separately, and I would recommend exporting a 23.976p master WAV, importing that back into Premiere, speeding it up 100.1%, optionally checking it against the reinterpreted J2C files, and then exporting a 24p audio master.
There are a few things to keep in mind when using DCP-O-Matic. The J2C files have to be imported as a folder, meaning that each sequence should be isolated in a dedicated folder, which is a good practice anyway. Once they are imported, make sure they are set to be used at 24p. In most cases you will want to set the software to InterOp instead of SMPTE. If you do have 7.1 audio, you need to make a 12 channel DCP. The first 6 channels follow the usually 5.1 order: (L,R,C,Lf,Ls,Rs) but the rear left and right streams go in channels 11 and 12 respectively.
Another issue that weighs on the workflow choices is encoding speed. Some of that will depend on the content of your source timeline, so we will be benchmarking from the point of having a flattened file. 4K obviously is more resource intensive than 2K, so we tested both. Doing everything in DCP-O-Matic took 18x times the run time for all of the steps combined in 4K, and 3x the run-time for 2K. (Our 100 minute film took 30 hours to export to DCP in 4K, and 5 hours in 2K.) Using the .J2C frame export approach is about twice as fast in my 4K tests, but only slightly faster than DCP-O-Matic at 2K. None of the encoders we are testing have really been optimized for speed, and are usually making minimal use of the 20 CPU cores I have available on my workstation. I ran a separate set of identical tests on my Thinkpad P71 laptop, and the encode times were only slightly longer, illustrating how none of this software is fully utilizing the processing power available in a high end workstation.
Task for 10 Minute Clip | Xeon 2K | Laptop 2K | Xeon 4K | Laptop 4K |
Encoding in DCP-O-Matic | 28Min | 40Min | 167Min | 173Min |
Encoding in AME to .J2C | 30Min | 33Min | 80Min | 93Min |
Encrypting in DCP-O-Matic | 2Min | 3Min | 3Min | 5Min |
If we could get an optimized JPEG2000 encoder option in AME that supports XYZ color and utilizes multiple threads, the encode time could be cut significantly with existing hardware. Until that day comes, budget your encoding time accordingly. The other factor when encoding is bitrate, which is limited to a maximum for 250Mb/sec, but I would recommend 200Mb for 4K, and 100-150 for 2K. Any more than that is usually overkill.
Hi Mike,
I am the author of DCP-o-matic. Thanks for the write-up! There’s a couple of small things I’d like to raise. Firstly, DCP-o-matic can do your 23.976 -> 24 conversion; it can speed up audio to match the video rate increase. Get in touch if it’s not clear how to do that! Secondly, DCP-o-matic can encode using multiple cores (and can use extra encoding machines across a network). If that’s not working for you, do come over to dcpomatic.com and get in touch somehow. Granted, the encoder that we use (openjpeg) is not the fastest in the world but we do try to offer parallel processing to get around that.
Your numbers about DoM taking 30 hours to export to DCP in 4K, and 5 hours in 2K are surprising… I should look into that.
Kind regards,
Heey! Why are you speeding up audio without handling pitch? Your sound engineer allowed this? Don’t do it ever again. Maybe 23.976 to 24fps is not really noticeable, but if you do it for 25fps to 24fps (for interop, 4% slowdown), there will be really annoying pitch distortion. Don’t forget to handle pitch!:) And about speed of encoding – why didn’t you write about your cores’ utilization? It sounds really wrong – to encode 4k DCP in 30 hours. And most likely it’s about your OS, not DCP-O-MATIC.
I didn’t mention compensating for pitch because I have separate 23.976p and 24p masters from my sound engineer, and because most editing applications compensate for pitch when making your own speed adjustments to audio (specifically Premiere Pro does). So that should be taken care of automatically in most cases. And at no point do I talk about adjusting from 25p, which a 40x greater change in TRT, and definitely requires more care in regards to maintaining quality through that conversion. In regards to render time, core usage is minimal, presumably due to poor threading. I don’t break my DCP into reels, which is probably how DCP-O-Matic usually approaches parallel encoding. I have bypassed this issue by encoding to J2K elsewhere, and just using DCP-O-Matic for the encrypting and wrapping steps, as detailed in my more recent article on this topic.