This entry is intended to be read after my earlier entry on a similar subject:
Having provided a (relatively) simple system for putting your content in to DCP format, I now present a simple system for recovering it. When considering publishing this information I have tried to anticipate some of the outcomes. I have discussed it with people whose judgement I trust. I use no exploit, or “hack” or “bypass” here. I trust that you will only use this information to process content you have the rights to, or only with the full authority of the copyright holder.
The DCI specification provides a means to protect content against unauthorised access, and against tampering. The cinema industry uses it every day. There is no excuse not to use content protection in the cinema industry, particularly when key management is now so streamlined and automated.
If you did not install the digital_cinema_tools package:
then do it now because you will need it for the asdcp-test command
Other requirements are:
(4) A working knowledge of how a DCI package is organised
(5) Lots of disk space
(6) A supply of tea, or your preferred beverage(s)
You might want to turn off image thumbnail creation, as this can easily generate in excess of 6000 files in your working folder. At various points in this tutorial you will find yourself looking for various bits of information about the content such as frame rate, aspect ratio e.t.c. Most of this is held in the Control Play List (CPL) file. The ASSETMAP will define which file is the CPL. The contents are held in XML, so open the ASSETMAP, CPL etc in a web browser.
As the DCI Specification is tightly defined, this procedure ought to work on any JPEG-2000 encoded Digital Cinema Package (DCP) with these conditions:
(a) Not encrypted (no KDM required)
(b) Not stereo (2D content)
(c) Consists of only one reel – most shorts, trailers, adverts, public service announcements etc.
Extracting the picture stream, and conversion from CIE 1931.
First, read the ASSETMAP file. This is found within the folder which holds all the files which (together) comprise the DCP. The ASSETMAP file should tell you where to find the PacKing List (PKL). Search for “<PackingList>” and look a few lines down for the name of the actual PKL file.
Open the PKL file, and look for “asdcpKind=Picture”. That will give you the name of the MXF file which holds the picture information. Also there should be a pointer to the MXF file for the sound, make a note of that for later.
For the purposes of this procedure, I will assume you have determined that the picture file is called “MXF-video.mxf”. Open a command window, cd to the correct folder and issue this command (changing the name of the MXF file to suit):
asdcp-test -x frame MXF-video.mxf
What will happen is asdcp-test will create files of the names frame000000.j2k, frame000001.j2k, frame000002.j2k e.t.c. One file per frame of the DCP. These will be in JPEG-2000 format.
You may be able to import these files directly in to your video editing software. I will provide means to convert them in to other formats, which are more readily understood.
What you should consider at this point is that you may lose some colour information. DCI content uses the CIE 1931 colour space model, and gives a maximum of 12 bits per colour component, therefore 36 bits per pixel. In theory you could convert these JPEG-2000 images to TIFF format, and preserve all that colour resolution, but not all applications understand 48 bits per pixel TIFF files.
To be fair, I’m not sure how much it matters as my display device is 10 bits per channel at best. If you’re using a notebook, you may well only have 6 bits per channel.
To convert to PNG files use this (with a tiny loss of colour accuracy):
mogrify -format png -alpha Off -resize 999x540 -gamma 0.384615 -set colorspace XYZ -colorspace sRGB -depth 8 *.j2c
(a) The output images are resized, feel free to adjust the target size to suit your requirements. I’ve simply divided by 4 to get these figures.
(b) Notice the use of the unusual gamma, because in D-Cinema gamma is 2.6 at projection.
(c) Use “-depth 16″ and “format tiff” if you want to preserve all colour resolution. Worth doing for selected stills, not worth it for transcoding to video.
(d) This will take a long time, go and make a cup of tea. Other beverages may be available.
At this point you can pick out your favourite still frame.
If you intend to proceed all the way to producing a consumer-friendly video of the content, then read on.
Sorting out the sound.
The sound is not so hard to deal with, as the DCI Specification requires uncompressed sound. Common media player applications such as VLC can play audio held in the MXF container format without any sort of conversion. For simplicity’s sake, and because this post is mainly about the picture, I suggest converting the sound to a 2 channel WAV file like this:
mplayer MXF-audio.mxf -ao pcm:file=audio.wav,fast -channels 6 -af pan=2:0.4:0:0:0.4:0.2:0:0:0.2:0.3:0.3:0.1:0.1
This command mixes the six channel sound down to two channels in a standard RIFF format WAV file. The pan option tells mplayer how to mix each input channel to make two output channels. (Source thank you, it sounds slightly better than the example in the manual)
Encoding the video and sound.
You can use some magic command line incantations for this, but it is easier to import the image sequence in to OpenShot along with the 2 channel sound file.
Within OpenShot, create a profile which matches your chosen picture resolution and frame rate. Refer back to the mogrify command you used earlier.
(1) Frame rate is likely to be 24fps, as not all DCinema kit fully supports all valid frame rates. You will find it in the CPL file.
(2) The aspect ratio is likely to be 1.85, but look in the CPL file to confirm. Openshot will accept aspect ratios as a fraction, so you can use 185/100 or the simplest version as 37/20.
(3) The pixel aspect is “1/1″.
There is something which might trip you up. Check the CPL for the “<ReelList>” section. For the picture and sound there might be non-zero “<EntryPoint>” values. These values describe an offset within the video and audio, to show where playback should commence. Using the frame rate and offset (number of frames), calculate the offset between picture and sound. If both of these are zero, then it’s easier later on in OpenShot.
I did not set out to write an OpenShot tutorial, but there is a feature of OpenShot which is not well known. If you drag a file named similar to “image000000.png” to the Project File panel, OpenShot will recognise it as the first frame of a set of sequentially numbered frames. See this tutorial for the details. Add the sound file to the project in the same way.
Put the video on track 2 (upper), and sound on track 1 (lower).
If you have non-zero <EntryPoint> values: With reference to the offset you calculated earlier, move the video or sound left or right as required. If the picture needs to be ahead of sound, you can right-click and enter the offset with reference to the project time line.
Play it through to confirm correct synchronisation.
Use the Razor tool to remove the excess picture/sound from the beginning and end of the project as required. If you’re left with a blank space at the zero line of the project, move both tracks so they commence at zero on the timeline.
Export the project as (rendered) Video, check the profile in use is correct (matches resolution and frame rate) and choose sensible values for container format, video codec, audio codec and frame rate. Some versions of OpenShot (currently) seem to have a problem in saving the finished file to any other folder than /home, so don’t panic if the file is not where you expected it to be.
(Use these commands with care)
Final words and bits that don’t fit anywhere else.
There was a discussion about adding support for converting XYZ colours to RGB to ffmpeg. I’m no stranger to compiling code from source, but I’ve not tried this method.
As with my previous post on this subject, I extend my thanks to the same four people – for the same reasons.
Actually you can use this with 3D material, start with asdcptest -3 -x frame … and it will output all left eye and right eye frames. I’ll leave it as an exercise for the reader about further processing of the data.