ffmpeg: Convert DCP to Quicktime

DCPs (or Digital Cinema Packages) are a fairly specialised form of distributing films and video for digital cinema. The emphasis of this format is on high-resolution, and high-quality – supporting up to 4k films encoded using the JPEG2000 codec.

In the vast majority of cases you would want to take your finished film, and convert it TO a DCP for distribution to cinemas, film festivals and so on. However, in a few instances I’ve had a need to reverse that conversion.

Now, I should make it clear that this process described here is only for unencrypted/unprotected DCPs. Clearly this process isn’t for converting a blockbuster feature films to H.264 for your home movie collection. I’ve just found it extremely useful when preparing content for our various film festivals, particularly when we need to create our awards ceremony or showreels promoting the film schedule, and where no other HD copy of the film is available.

Converting a DCP to a more common video format, such as Quicktime ProRes, is a very simply one-step process, but it involves some navigating of DCP folders and crazy filenames. A typical DCP folder will usually contain files that look something like this:

The ASSETMAP, VOLINDEX and .xml files are all used to describe the content, and help the digital cinema systems import, index and play back the films in the correct way. But what we’re really interested in are the two .mxf files.

You’ll notice two files ending in “_vid.mxf” and “_aud.mxf”. These are the video and audio streams that we’ll be using to convert to Quicktime. In the example above, you’ll notice that those two files begin with “jp2k_” and “wav_” respectively. This tells us that the video is in the JPEG2000 format, and the audio in the standard, uncompressed WAV format.

The beautiful thing about ffmpeg is that we now no longer need to worry about what those formats are, or indeed what colourspace the source material is in. ffmpeg will detect, and automatically convert for us.

(Yes, that’s correct: The latest version of ffmpeg will automatically convert the XYZ colourspace to RGB!)

… and now be patient. Decoding JPEG2000 and doing an XYZ->RGB colour conversion is a slow process!

The above command will convert the DCP using the ‘prores’ codec, and will simply copy the audio data. The reason we don’t have to pass in any other settings is that ffmpeg always try to do the right thing. In this case, ffmpeg has spotted the colourspace of the DCP is XYZ:

… and that the format we’re trying to convert to only supports the RGB (or in this case, YUV 4:2:2) colourspace:

So ffmpeg fills in the gaps, and applies a colour conversion. Clever, huh?

There’s a lot this command doesn’t do, however. It doesn’t perform any scaling or frame-rate conversion. The aim is primarily to convert the DCP to a format that most editing systems will understand.

The other main caveat with this method is the conversion process, particularly the colourspace part, is fairly rough. It’s enough to get you out of a hole at the 11th hour during a film festival, but it’s not something you’d want to use as part of your day-to-day workflow.

But hopefully this post is enough to get you started.

Update (23rd June 2014): ProRes Encoding Notes

This post was only meant as a proof of concept, rather than a step by step guide – but it’s worth pointing out a few extra things:

The Apple ProRes 422 codec used in the example above is not necessarily the best format for maintaining the highest fidelity within the RGB colourspace. A better choice would be ProRes 4444, which is capable of storing 10-bit RGB colour values at full resolution. While the file sizes would be larger than the ProRes 422 format, you would still benefit from the flexibility and editing performance you get from the ProRes codec.

ffmpeg’s ProRes encoder doesn’t support ProRes 4444 (yet) … but a variant of it does. You’ll need to use this command if you want to generate ProRes 4444 files:

Both of the above examples assume stereo is good enough for PC viewing, but there are plenty of examples out there to help you with advanced audio manipulation.

Audio Channel Mapping

Finally, check out the comment from William Isaac below. He’s spotted a problem when simply coping the audio stream from INTEROP DCPs, in that the channel mapping does not match that of the Dolby 5.1 standard mapping. He’s included an ffmpeg command that automagically remaps the audio during the encoding process.

Great article Oliver, got me out of a sticky situation today! I’m new to using ffmpeg but eager to learn. You mention above that ffmpeg automatically detects the XYZ colour space and coverts it to RGB. How would I opt out of the colour conversion? In other words, create a QT mov with a XYZ colour space? Thanks.

@Jho glad the info was useful to you. As for creating a QuickTime .mov in the XYZ colour space, the tricky bit is finding a codec that supports and understands that’s colour space. ProRes 4:2:2 is a YUV codec, that is incapable of containing the XYZ colour information. It’s theoretically possible for ProRes 4:4:4:4 to contain XYZ colour data, but I can find any information that it is actually possible. The ffmpeg prores encoder definitely doesn’t support this, which is why it does the conversion to RGB.

It may be possible to simply re-wrap the JPEG2000 frames into a QuickTime .mov file (QuickTime, like AVI, MKV and MXF, is just a container after all). But I’m not sure what advantage this would give you over the original MXF files.

Many thanks for this incredibly useful posting. Just a few observations if I may:

1. If you’re more interested in getting something fairly small to play on a pc than in re-editing, suggest changing ‘prores’ to ‘h264’.

2. If this gives you a file that plays audio ok but with a black screen (ie no video), then after ‘h264’ try putting ‘-pix_fmt yuv422p’ or ‘-pix_fmt yuv420p’. By default ffmpeg gives the highest available quality, which with a DCP as the source is 4:4:4 chroma subsampling, but some pc-based players may not support it.

3. Running the conversion on an Interop DCP, I found that centre channel content was being output on the left surround channel. To investigate this further I downloaded a Dolby 5.1 test clip from http://www.freedcp.net/dcp/test/dolby/dolby_channel_id_51_flat.zip. Beware that although this clip is a DCP for testing 5.1 sound, it actually has 8 audio channels present! I do not know why the Interop DCP channel order (L,R,C,LFE,Ls,Rs) cannot simply be copied in ffmpeg and the resulting pcm audio stream be correct when played, but it isn’t. The way I overcame these issues was to replace ‘copy ‘ with the codec ‘pcm_s24le’ (which appears to be the same codec that the audio essence is encoded with in the DCP); to specify ‘-ac 6’ to ensure that ffmpeg would never attempt to generate more than 6 channels of audio output, and then to re-map the audio channels using ‘-map_channel 1.0.0 -map_channel 1.0.1 -map_channel 1.0.4 -map_channel 1.0.5 -map_channel 1.0.2 -map_channel 1.0.3’. (This approach does result in any other audio channels present in the stream simply being discarded.) So, my command line for converting the Dolby 5.1 test DCP mentioned above, runing in the directory which contains the DCP folder is as follows:

Hi William, thanks for your comments. I admit, this post was more of a proof-of-concept for getting DCPs back into the edit suite, but you’re right – a more useful application may be the creation of H.264 viewing copies. I’ve added a few extra steps to the post that hopefully cover this.

I’ve a huge fan of the H.264 codec (I personally prefer the libx264 encoder within ffmpeg), and find it baffling ffmpeg allows H.264 422 videos to be created by default. Very few players support the 422 format, and I’m always forgetting to add that -pix_fmt!

In my specific case, the aim was retain as much of the original image fidelity, but also allow a workflow that fit with our existing editing tools to allow us to create clips, nomination reels and award ceremony AV sequences for our festivals. Hence the choice of ProRes. For simple ‘viewing’ though, you can’t beat H.264.

As for the audio mapping problem, I’d not come across that. Thanks for sharing. We have had trouble before now with mis-matched audio channels, and this would well have been the culprit. Thanks!

I wonder if it is a problem with my source files, because third-party decoder (which eventually base on ffmpeg) has the same result. In the metadata of the source file shown by ffmpeg I found this entry for the input file: „Stream #0:0: Video: jpeg2000, rgb48le(12 bpc), 1998×1080, 24 tbr, 24 tbn, 24 tbc“

Could that mean, that they use jpeg2000 with rgb colour space instead of xyz colour space? Is that possible? And: do you have any suggestions, what i can do to get a useable file for cutting? Thanks!

Hi guys, to avoid the greenish look I suggest use DCI converter plugin on Adobe Premiere Pro. It corrects the color to the original value and it is a free plug in. Very easy to use. It’s working for me.If you find another way, please publish here.

Hi, i was wondering if you can help me a bit everytime i get to this step [filenamefor_vid.mxf] and replace it with the name of my file 4d008f15-b4af-4d6a-95e1-322e75e47e2e.mxf i get a error in command promt like “[4d008f15-b4af-4d6a-95e1-322e75e47e2e.mxf] : no such file or directory

You need to remove those [square] brackets around your filename … I only added them to make it clearer that was the part you needed to replace. Maybe I should have stuck with quotation marks! I’ll update the post.

Categories

Meta

Welcome

Hi, I'm Oli Trenouth, and I’m deeply passionate about both software development, and all things audio and video. I’m an established software developer, audio engineer and video editor with over 17 years experience.

This website aims to showcase my work, my thoughts and tutorials. Thank you for visiting :)