Please login or register. November 16, 2018, 07:16:07 PM

Author Topic: Open Source DCP Workflow  (Read 85656 times)

Terrence Meiczinger

  • Administrator
  • Hero Member
  • *****
  • Posts: 560
    • View Profile
Open Source DCP Workflow
« on: April 29, 2010, 03:52:18 PM »
You can build a DCI compliant JPEG2000 digital cinema package using only open source tools with the work-flow outlined here. This post assumes you have all the necessary tools compiled and installed.

  • You can find the list of necessary tools here: Open Source Tools
  • You'll probably want to read up on compiling and installing the tools for your operating system

There are 4 main steps to creating a DCP:

  • Content normalization - Getting your content into JPEG2000 frames or MPEG2 and PCM WAV files.
  • Colorspace Conversion - Converting content into the XYZ colorspace. This only needed for JPEG2000.
  • MXF Container - Putting MXF wrappers around your content.
  • XML Descriptors - Generate XML files to describe content for ingest and playback.

Setup
For the purpose of this work-flow, we'll start with a 1920x1080p MPEG-4 file, called sample.mp4. You will need to have all of the tools compiled, installed and executable. The actual steps may vary slightly depending on your OS. The following are based on linux and you'll need to adjust them for your needs.

1. In the folder where sample.mp4 is located, create some directories to organize the intermediate files.

Code: [Select]
#mkdir audio
#mkdir tiff
#mkdir j2k

Content Normalization
The first step is getting your content into the right format. It is generally best to get your original source as close to the specification as possible. That is, while ffmpeg can convert the frame rate from 29.97 to 24fps, resize or change the aspect ratio, it is better to do this during editing or filming. If your editing package can export to a TIFF and 24-bit 48khz or 96khz uncompressed PCM wave files, then go to the next section.  Your software may also export to JPEG2000. However, unless it will perform XYZ colorspace conversion and is DCI compliant, you'll want to export to TIFF.

1. De-mux the video into TIF frames. This command will create 24 TIF files per second in the tif folder. The %06d tells FFmpeg to create a 6 digit padded file name for each frame, 000001.tif, 000002.tif, etc.

Code: [Select]
ffmpeg -y -i sample.mp4 -an -r 24 -vcodec tiff tiff/%06d.tiff
NOTE: OpenDCP currently only handles sRGB images. If your source is in say YCbCr/YUV420p, you'll need to convert them to sRGB. You can do this using adding the -pix_fmt rgb24 argument as follows:

Code: [Select]
ffmpeg -y -i sample.mp4 -an -r 24 -pix_fmt rgb24 -vcodec tiff tiff/%06d.tiff
2. De-mux the audio into a wav file.

Code: [Select]
ffmpeg -y -i sample.mp4 -acodec pcm_s24le -r 24 -ar 48000 audio/sample.wav
A limitation of FFmpeg is that it doesn't allow you to write individual tracks, so you if want 5.1, 6.1, etc you'll need to split your sound into separate audio tracks with a program like audacity or quicktime. You can also use SoX (Sound Exchange) to split the audio tracks.

Code: [Select]
sox sample.wav left.wav remix 1
sox sample.wav right.wav remix 2
sox sample.wav center.wav remix 3
sox sample.wav lfe.wav remix 4
sox sample.wav surrleft.wav remix 5
sox sample.wav surrright.wav remix 6

Thanks jonathanj.

XYZ Colorspace
Now that we have an image sequence in the correct frame rate, we need to adjust the color from the original colorspace to the XYZ. You can use OpenDCP to do the color conversion and jpeg2000 creation in one step.

Use the tool opendcp_j2k to convert the TIFF sequence to a JPEG200 frame sequence. It takes an input folder containing your tif images and an output folder to save the XYZ color converted JPEG2000 images. You can set the frame rate and profile as well.

Code: [Select]
opendcp_j2k -i tiff -o j2k -r 24 -p cinema2k
Note: There are other methods around that use ImageMagick or LittleCMS to convert content in to the XYZ color space. While they will indeed convert into the XYZ color space, they aren't exactly correct for digital cinema. They do not account for the companding function specified in the DCI specification. It might not be a huge difference depending on your source content, but it is something to be aware of.

MXF Container
Now, we have all of the content in the correct format for digital cinema. The next step is to place these inside media containers, in this case MXF. This part is a simple step to perform, but why it needs to be done can be a little confusing to understand for a lot of people. This is because it is easy to confuse the difference between and codec and a container. A codec is the method of encoding or decoding data, which in most cases is a way of compressing or decompressing data. The container only describes how elements are stored into a single file. The elements in a container could be anything, even other containers. A single MXF file could contain encoded audio and encoded video, but in the case of digital cinema, the audio and video elements are stored in separate MXF containers. As a result, you'll have an MXF file containing one or more audio files (wav files) and another MXF file containing one or more video files (jpeg frames).

We can use opendcp_mxf create the MXF wrappers.

1. Create the audio MXF file.
You can supply a single wav file on the command line or if you have multiple channels, a folder containing wav files. When supplying a folder, you to need map each wav file to the correct channel. This is done by prefixing each wav file with the channel number, so the software knows how to assemble them.

01 Left
02 Right
03 Center
04 Sub
05 Left surround
06 Right surround

So, we would simply prefix the file names.

Code: [Select]
Ex.
      01_sample.wav (left channel)
      02_sample.wav (right channel)
      ...

In our original example, we only have one audio file. We want to specify that we are using 24fps with the -r argument.

Code: [Select]
opendcp_mxf -i audio/sample.wav -o sample.audio.mxf -r 24
2. Create the video MXF file.
This will take all the jpeg frames in a directory and place them into a single file.

Code: [Select]
opendcp_mxf -i j2k -o sample.video.mxf -r 24
XML Descriptors
We now have two nice and neat MXF files. In a lot of cases, you'd have a single MXF that contained the audio and the video and that would be it.  You'd give the MXF file to somebody and they could play it. However, in digital cinema, we need have a few more steps that are needed to tell the digital server what to do with the MXF files. This may sound redundant and just adds another level of confusion. However, we can quickly see the advantage with an example. Let's say you want to distribute your film worldwide in multiple languages. The video is going to be the same for all of them, just the audio would be different. So, rather than creating a single huge file for every language, we can keep them separate. We can use the same video MXF and include one or more audio MXFs, which can be linked together using XML files. This saves a lot of space and time.

We need to create 4 XML files, the composition playlist (CPL), package list (PKL), assetmap, and volume index. We can use OpenDCP to create these XML files.

OpenDCP will create all of the XML files in one step. You supply the MXF files and any additional tags. Only the --reel is mandatory.

Code: [Select]
opendcp_xml --kind feature --title SAMPLE_DCP --reel sample.video.mxf sample.audio.mxf
The END
That is it, you should now have a working DCP. The final step would be to get the content onto each server. That varies depending on the server. Some have utilities that upload the content over the network, support CD/DVD, USB drives, etc. If you using a storage medium, like a USB drive, you'll need to have it formatted in a way that it can be read by the server. A lot of servers use linux, which would use the ext3 format.
« Last Edit: April 07, 2012, 02:21:26 AM by Terrence Meiczinger »

Cineman

  • Jr. Member
  • ***
  • Posts: 57
    • View Profile
Re: Open Source DCP Workflow
« Reply #1 on: February 02, 2011, 10:27:53 AM »
Hi I’ve been making DCP’s for some time using the ffmpeg, imagemagick, asdcp-test opencinema tools rout. And I'm trying out openDCP_j2k and have a couple of queries firstly i entered the command line
opendcp_j2k -e 1 -i d:\tif -o d:\j2c -r 24 -p cinema2k
to enable kakdu but got the following response
OpenDCP J2K 0.16 (c) 2010-2011 Terrence Meiczinger, All Rights Reserved.
  Encoder: Kakadu
'kdu_compress' is not recognized as an internal or external command,
operable program or batch file.
[ERROR] Kakadu JPEG2000 conversion failed d:\tif/00000001.tif
[ERROR] JPEG200 conversion d:\tif/00000001.tif failed
[FATAL] Exiting...

secondly i tried the -t 2 command but it still only opened 1 thread, even though it says the default is 4
Also whilst on the subject of j2k i noticed that this version of openJpeg is encoding constant bit rate whilst the windows binary available from their web site is variable bit rate which gives a much more compact j2c file without any loss of quality on complex images. Can this mode be used?
Also how  does one use the multiple reel function for longer dcp's and the inclusion of subtitles.

I'm eagerly awaiting the encryption and KDM generation modules when they become available and would be keen to beta test.

Whilst looking for more information about openDCP i stumbled across the gui on github probably a work in progress copy, i unzipped it into my openDCP folder and tried to compile a dcp but it didn’t seem to actually connect to the other openDCP apps perhaps its not finished yet. It also seems to have a few errors with regards to the audio functions. Although it has the options for 2 channel 5.1 and 7.1 DCP's the file select icon only locates the first two channels 1 & 2. you cant select centre and sub or Ls and Rs wav files if you select 5.1 or 7.1. Also the 7.1 channel layout is completely wrong. In 7.1 the two additional channels are back Left surround and back right surround, like stereo EX there are no inner left and inner Right for screen channels, and as yet no plans for them, though additional screen speakers to add a height element have not bee ruled out. Also back left surround and right surround are in fact on AES pair ch11 & 12. mute wav files have to be present at ch9 & 10  positions and AI HI channels have to be present on channels 7 & 8 or they also have to be mute wav files to keep the wav interleave correct. If this channel layout is not adhered to it can lead to erratic behaviour on some servers.

Once these anomalies have been corrected this looks like a very  good set of programs and I will be changing my dcp making process accordingly.




Terrence Meiczinger

  • Administrator
  • Hero Member
  • *****
  • Posts: 560
    • View Profile
Re: Open Source DCP Workflow
« Reply #2 on: February 02, 2011, 11:11:58 AM »
Hello,

You have to download and install Kakadu. If on windows, you need to copy the kdu_compress into the same directory as opendcp. Also, by doing so you agree to Kakdu's license terms which are non-commerical use unless you have obtained a commercial license from them.

The Windows version is not currently multi-threaded, so you will only see 1 thread due to Visual Studio Express disabling multi-threading. It should work, if one compiled it in Visual Studio Professional, but I do not have access to that.

You can supply multiple reels and would need a subtitle mxf for each reel, but the subtitle code is not fully functional yet.

You can supply a -q <quality> ratio to opendcp_j2k to adjust the overall image size. It is pretty linear so, -q 50 will create an image 50% the size. What is acceptable depends on your source, but I've used -q 60 with good results.

The project on github is a development repository and nothing there is really usable. The GUI work is in progress and what you downloaded is a mockup with no functionality outside of some GUI components. The 7.1 elements are Left Side and Right Side, but they will not be implemented.

Thanks for the feedback. OpenDCP is beta code, so there is still a lot of work to be done.
« Last Edit: February 03, 2011, 05:08:47 PM by Terrence »

Cineman

  • Jr. Member
  • ***
  • Posts: 57
    • View Profile
Re: Open Source DCP Workflow
« Reply #3 on: February 12, 2011, 04:29:02 AM »
Hi Terrence,

Im making interop and smpte test packages of the same content. Is the only switch the one in the opendcp_mxf program or is there another in opendcp_xml which i have missed, i thought the pkl and cpl were different for interop and smpte packages. or does your program detect what sort of mfx file its processing and make the approprate changes to the xml files.



Mike

Terrence Meiczinger

  • Administrator
  • Hero Member
  • *****
  • Posts: 560
    • View Profile
Re: Open Source DCP Workflow
« Reply #4 on: February 12, 2011, 01:02:41 PM »
Hi Terrence,

Im making interop and smpte test packages of the same content. Is the only switch the one in the opendcp_mxf program or is there another in opendcp_xml which i have missed, i thought the pkl and cpl were different for interop and smpte packages. or does your program detect what sort of mfx file its processing and make the approprate changes to the xml files.


Mike

You only need to specify the flag into opendcp_mxf. From there opendcp_xml will detect whether your MXF file is SMPTE or Interop and create the appropriate packages.

I recently found a couple issues in OpenDCP in regards to the MXF Interop XML files. The Dolby and Doremi servers ignore the problem, but other servers might not be as forgiving. I'll have an updated version posted soon.

Wolfgang Woehl

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 312
    • View Profile
Re: Open Source DCP Workflow
« Reply #5 on: April 08, 2011, 07:40:58 PM »
Hi. I pushed some code to collect and check X.509 certificates for Digital Cinema/SMPTE compliance upstream. Checks are following http://www.dcimovies.com/DCI_CTP_v1_1.pdf, chapter 2. See https://github.com/wolfgangw/digital_cinema_tools/blob/master/dc_crypto_context.rb.

These certificates are used to sign DCPs and KDMs (See https://github.com/wolfgangw/digital_cinema_tools/blob/master/make-dc-certificate-chain.rb for PoC code to generate some of those certificates and https://github.com/wolfgangw/digital_cinema_tools/wiki/Cinemaslides to actually use them -- in a weird way.)

Best, Wolfgang

Terrence Meiczinger

  • Administrator
  • Hero Member
  • *****
  • Posts: 560
    • View Profile
Re: Open Source DCP Workflow
« Reply #6 on: April 12, 2011, 10:48:40 PM »
Hi. I pushed some code to collect and check X.509 certificates for Digital Cinema/SMPTE compliance upstream. Checks are following http://www.dcimovies.com/DCI_CTP_v1_1.pdf, chapter 2. See https://github.com/wolfgangw/digital_cinema_tools/blob/master/dc_crypto_context.rb.

These certificates are used to sign DCPs and KDMs (See https://github.com/wolfgangw/digital_cinema_tools/blob/master/make-dc-certificate-chain.rb for PoC code to generate some of those certificates and https://github.com/wolfgangw/digital_cinema_tools/wiki/Cinemaslides to actually use them -- in a weird way.)

Best, Wolfgang

Nice work Wolfgang! If anybody wants to know about KDMs, Encryption, etc... Wolfgang is the guy. His work has helped me tremendously with OpenDCP.

MaSTeRMaMay

  • Guest
Re: Open Source DCP Workflow
« Reply #7 on: December 01, 2011, 05:26:44 PM »
The problem with the ffmpeg is that it does not parallelize the image to tiff encoding process. The first method I used was to get the video info (frame count using MediaInfo), then split video to mkv's without reencoding (mkvs count is the same as conversion thread counts), then convert them to tiff using ffmpeg. I'll post the whole scripts I currently use in a few days. It's better to handle scaling and padding on tiff creating (libavfilter could be used for that).

Then, the tiffs undergo the OpenDCP conversion.

For sound you have to normalize its volume (sox norm -20), conforming to framerate as needed and trimming (or padding by silence), because sound duration is not always accurate.

The second method I'd like to finish in a few days is done by writing some app using libavcodec, libavfilter and libopendcp. Using sox for audio.

The main problem here is that only the DSP100 servers do not support 30 fps rate, and you'll have somehow to handle this. Currently, I just do not care.

Terrence Meiczinger

  • Administrator
  • Hero Member
  • *****
  • Posts: 560
    • View Profile
Re: Open Source DCP Workflow
« Reply #8 on: December 01, 2011, 09:57:03 PM »
I've done some basic work to incorporate libav and libsndfile into OpenDCP to make it more versatile for input types. I just also re-wrote the wav MXF writer so it will be easier to automatically create silence wavs or pad short wav files. The FFmpeg/libav licenses are kinda strange, so I haven't fully incorporated them in yet.

MaSTeRMaMay

  • Guest
Re: Open Source DCP Workflow
« Reply #9 on: December 01, 2011, 10:26:47 PM »
So, working ffmpeg code:

Code: [Select]
ffmpeg -i ${name} -an -pix_fmt rgb24 -r 24 -vf 'scale=min(1998\,a*1080):min(1080\,1998/a),pad=1998:1080:(ow-iw)/2:(oh-ih)/2' -vcodec tiff tiff_flat/frame%08d.tif
ffmpeg -i ${name} -an -pix_fmt rgb24 -r 24 -vf 'scale=min(2048\,a*858):min(858\,2048/a),pad=2048:858:(ow-iw)/2:(oh-ih)/2' -vcodec tiff tiff_scope/frame%08d.tif

Currently also looking forward to incorporate XYZ conversion code into ffmpeg (adding pix_fmt XYZ), but that might be not a great idea, because ffmpeg might not be able to handle more than 8 bit images perfectly...

for audio it's better to use:
Code: [Select]
sox ${audio} -r 48000 -b 24 -t wavpcm wav/01_audio.wav tempo ${tempo} norm -20 trim 0 ${trim} remix 1
sox ${audio} -r 48000 -b 24 -t wavpcm wav/02_audio.wav tempo ${tempo} norm -20 trim 0 ${trim} remix 2
sox ${audio} -r 48000 -b 24 -t wavpcm wav/03_audio.wav tempo ${tempo} norm -20 trim 0 ${trim} remix 3
sox ${audio} -r 48000 -b 24 -t wavpcm wav/04_audio.wav tempo ${tempo} norm -20 trim 0 ${trim} remix 4
sox ${audio} -r 48000 -b 24 -t wavpcm wav/05_audio.wav tempo ${tempo} norm -20 trim 0 ${trim} remix 5
sox ${audio} -r 48000 -b 24 -t wavpcm wav/06_audio.wav tempo ${tempo} norm -20 trim 0 ${trim} remix 6

tempo here could be simply obtained by using mediainfo binary:
Code: [Select]
fpsf=`mediainfo --Inform="Video;%FrameRate%" ${name}`
frames=`mediainfo --Inform="Video;%FrameCount%" ${name}`
So, then you just understand, which one fps you will have to conform to, and... just select the required tempo (0.96 for 25->24 fps, 1.001 for 23.97->24, and so on)

Coeur Noir

  • Jr. Member
  • ***
  • Posts: 77
    • View Profile
Re: Open Source DCP Workflow
« Reply #10 on: December 02, 2011, 05:18:37 AM »
What is the version of ffmpeg you use, MaSTeRMaMay ?

I've noticed months ago quite a big difference between resizing images with ffmpeg and ImageMagick.

From a 1280x720 source to 1998x1080 output, the result was far better with ImageMagick's convert. I may went wrong somewhere. So my question is :

do you know if there's really a difference in resizing process between ffmpeg and ImageMagick's convert ?

MaSTeRMaMay

  • Guest
Re: Open Source DCP Workflow
« Reply #11 on: December 02, 2011, 08:55:24 AM »
It also depends on what algorithm you chose using ImageMagick. I have not compared these - had almost every ad at least in FullHD, so was scaling down and padding at most. I use gentoo, so prefer the latest version of every software I use. On OSX I used ffmpeg 0.7.7. It will be great for somebody to take a look at comparing scaling using ImageMagick and ffmpeg.

Terrence Meiczinger

  • Administrator
  • Hero Member
  • *****
  • Posts: 560
    • View Profile
Re: Open Source DCP Workflow
« Reply #12 on: December 02, 2011, 04:26:52 PM »
I did some tests last year and ImageMagick's scaling was quite a bit better than FFmpeg. There are numerous scaling algorithm's and I didn't check the code to see what each was using.

As far as audio, I'm not sure the need to do anything in regard to frame rate/tempo/etc. Audio by itself doesn't really have a notion of frame rate, only time duration. You just demux as 24-bit, 48khz and it doesn't matter what the source was. During the sound MXF creation, the audio will be broken into data chunks based on the frame rate and number of channels. The actual audio isn't change in any way.
« Last Edit: December 02, 2011, 04:29:24 PM by Terrence »

MaSTeRMaMay

  • Guest
Re: Open Source DCP Workflow
« Reply #13 on: December 03, 2011, 08:42:39 PM »
Yup, but you will have to conform it to 24 fps, if source was 25 fps one, because the video will be played at 24 fps, so the duration will be more by factor of 25/24. So, you will have to use the tempo effect of SoX, or any other method to conform it.

Terrence Meiczinger

  • Administrator
  • Hero Member
  • *****
  • Posts: 560
    • View Profile
Re: Open Source DCP Workflow
« Reply #14 on: December 03, 2011, 09:15:44 PM »
In the case of DCPs, the conforming happens by virtue of the MXF creation process... at least that is what happens in OpenDCP. I would think every other DCP tool does the same thing. It is easy enough to test and determine if OpenDCP is doing the correct thing.

dcinemaforum.com

Re: Open Source DCP Workflow
« Reply #14 on: December 03, 2011, 09:15:44 PM »