Finally. A course that covers all aspects of Digital Cinema Mastering!
Do you want to prepare your short film for projection in cinemas?
Or do you just want to know how hollywood blockbusters are distributed around the world?
In this software-independent course you will understand one of the most important aspects of video and film post-production.
Learn essential background facts on important topics around the D-Cinema Mastering process.
...and much more!
The course is technical but is easily accessible by everyone with basic knowledge of video workflows.
This course has a strong focus on Encryption for Digital Cinema.
Mainly because (until now) it is almost impossible to find any comprehensive information that is easy to understand.
After this course you will feel confident enough to talk to any professional about the Digital Cinema Mastering process and have an in-depth understanding of it's technical aspects.
You will also be able to handle any software product on the market that encodes Digital Cinema Packages without getting confused about all the various terms and acronyms that are used.
Main take-aways of this lecture are:
The DCI workflow encompasses a number of steps that lead from the Digital Source Master to the final DCP.
The main steps are:
The content can always be encrypted during the last process.
Many resolutions and frame rates have been added to the DCI specification. 2K, 4K and HD1080 format should be supported as well as common frame rates such as 25p and 30p.
Although it is the year 2014 there may be playback servers around that do not support newer resolutions. I recommend that you test any non-2K 24p format if possible.
This is he reason why this lecture suggests to add HD into a 2K frame for example and to do some padding.
Can it work without any padding, just using and HD resolution? Probably yes.
Bit depth in D-Cinema is always 12-bit.
Event a 16 bit TIFF DCDM contains a 12-bit image in which the last 4 bits are essentially zeroed out.
12-bit was chosen, because anything less would introduce visible banding artefacts.
Keep in mind that a Digital Cinema Distribution Master (DCDM) is supposed to be the last step in which the image is altered. All following steps are only image encoding and encryption.
Since a lot of applications do not require to render a DCDM first, this step is often simply skipped and part of the final DCP creation.
This is also the case for JPEG2000. Few applications require you to actually output a JPEG2000 file sequence as part of the DCP creation. Many times you can go from a Digital Source Master straight to the MXF files of a DCP.
The XYZ Colour Space is a mathematical model to derive more colour spaces, such as RGB.
Colours outside of the horseshoe shape are considered outside of the visible spectrum of the human eye.
By choosing an XYZ colour space, we make the Digital Cinema Distribution Master (DCDM) device independent.
The following Youtube video gives a great visualisation:
The by far most useful book to understand colour mastering for D-Cinema is:
Colour and Mastering for Digital Cinema by Glenn Kennel
The colour space conversion from RGB or XYZ is often "fixed and locked" by the software you are using.
It will often want to know what the "source colour space" of the DSM is, so that it then can apply the correct transformation.
Again, depending on the Software you are using you can bypass these rigid settings and apply a customised 3D-LUT or "Look-up Table".
This lecture covers the most important benefits of JPEG2000.
Some of the main advantages of JPEG2000 are:
Since JPEG2000 is always wrapped into an MXF container during the last step.
Mainly because MXF files are easier to handle and can carry customisable metadata.
This lecture covers the basic approach and differences between DCT and wavelet compression.
Wavelet based image compression can be found throughout Post-Production.
Cineform is the most dominant example in post-production, as well as REDCODE, which is JPEG2000 based.
I highly recommend the following links for more information:
The JPEG2000 bandwidth in D-Cinema should never exceed 250 Mbit.
An un-compliant data rate may cause stuttering on the server side. For Stereoscopic 3D the bandwidth is 125 Mbit due to the doubled frame rate.
As far as I know all DCP software products take this into consideration.
When you generate a JPEG2000 sequence and then wrap it into an MXF container, make sure to use the same frame rate (and consequently bandwidth).
Lastly, you can decide to choose a significant smaller bandwidth than 250 Mbit. This will result in a smaller DCP.
Audio Mapping for D-Cinema: If you are using a DCP encoding software, it will most likely help you with the mapping. However, you may need to create individual audio files that can be used in each "track".
There are three commonly used subtitle formats: XML, PNG and MXF
MXF subtitles "wrap" the subtitle file. Once big benefit is that it can then be encrypted along with the rest of the DCP assets.
The MXF file format has many flavours, such as OP1a or OPatom, AS-02 and so on.
"OP" stands for "Operational Pattern"
In Digital Cinema the MXF structure would be similar to what editing system such as Avid Media Composer use (OPatom). It essentially means that you have separate audio and video MXFs.
Further recommended reading:
MXF files in Digital Cinema have always separated video, audio and subtitle content.
This has many benefits, for example audio or video files can be swapped independently for versioning purposes.
D-Cinema reels are similar to chapter markers.
Every reel is effectively a MXF file which agains represents an individual asset.
This consequently means, that reels can be replaced with other assets, which is done during versioning.
DCP software products often allows you to load a DCP and then swap the reels with different audio or video content.
The resulting supplemental DCP would then only contain the new content and be significantly smaller.
A CPL or Composition Playlist is similar to an iTunes or MP3 playlist. It assembles assets for playback.
In D-Cinema this is done by the server which looks for the UUIDs of the individual MXF files.
In case of a supplemental DCP, the CPL with the "country version" would point to the video assets of the english version and the audio assets of the particular country for example.
This course covers the various types of metadata files that are created along with a DCP.
PKL and CPL are always an integral part of the DCP and essential during the verification and integrity check.
Encryption for D-Cinema allows for control on a very granular level.
Cinema playback systems can be limited to a specific time frame during which they can playback the content. It is also possible to let them play only specific language version for example.
Symmetric & Asymmetric Encryption , Private and Public Keys
Keys are essentially a string of letters and numbers. A public key can be sent via email, the private key however is kept in a secure place.
This place can be on a local computer system for example. Or, in case of playback servers, the private keys are programmed into the hardware and not accessible by anyone (except the manufacturer).
When creating a DCP, the AES key(s) are encrypted again using an RSA encryption.
This encryption is not necessarily done by the same software that encoded the DCP. Some software products produce a "digest file" that contains the AES keys and which are then loaded into a different software module for further encryption.
Other products may place the AES keys into a KDM that can only be accessed by the system which created the encrypted DCP. The same system would then load its own KDM to playback the encrypted content and/or to make more KDMs .
It is mandatory for encrypted DCPs to have a Certificate Chain and optional for unencrypted DCPs (although recommended).
A individual Certificate Chain can be provided by a vendor or by a Certification Authority (CA).
Signatures are a good way to ensure that the content was created by a trustworthy source.
Not mentioned in this slide:
Hash values are created from the track files during the encryption process and embedded into the metadata files.
These values are then cross-checked during the decryption process as mentioned in the next slide.
The Decryption Process of a KDM and the DCP assets are done within the playback server environment which can't be accessed by a person (for example the projectionist).
The link between server and projector is also encrypted.
A Distribution Key Delivery Message (DKDM) is never something that involves the end-user (the cinema). It is always an intermediate step.
There is virtually no difference between a DKDM and a normal KDM. Except that the DKDM is used to "transport" the AES keys securely to the service provider who creates more KDMs for the end-user.
Update - I was asked to give an example, so here it is:
"Let’s say you are a content provider. You receive a movie and then create a DCP. You don’t want to deal with KDM’s. In fact, you may not even have the rights to handle KDM’s.
There are specialised companies or departments who manage all the thousands of KDMs that go to cinemas. It is a business model in its own right and special applications are used to do this. Here is a vendor that provides KDM management systems: http://www.cinecert.com/products/
Your company makes the DCP and sends it to several cinemas. Keep in mind that the same DCP is sent to multiple cinemas (or the same DCP Version for a particular country).
A DCP has an AES encryption and since you don’t have the rights to create KDMs for the cinema servers someone else has to do it.
How do you get the AES key safely to the person who has to generate the KDMs?
Well, you apply the same principle. When you create a DCP you create a KDM for the distributor.
The workstation of the KDM distributor has a private and public key. The private key is (similar to a DCP server) in a hidden place on the hard disk.
The workstation administrator has given you the public key which you use to create a KDM.
Since you don’t send the KDM to a server, but another service provider who distributes more KDMs, you have just created a DKDM.
The service provider receives the KDM and loads it into the program. He now has the AES key for the DCP that you have sent to the cinemas.
On his machine, the operator has 1,000s of public keys. He is now able to create more KDM for the cinemas.
As you can see, at no stage he was required to receive the actual DCP."
Watermarking can be done for audio and video files separately.
It is a metadata flag in the DCP that tells the playback system to enable it in real-time.
Watermarking is invisible to the human eye and requires special technology to read it.
I am specialising in Audio/Video Post-Production and D-Cinema workflows.
During my career I have consulted various post-production and broadcast facilities world-wide and implemented new workflows utilising cutting edge technology.
My area of expertise covers various technical aspects of video post-production, such as hardware infrastructure, software applications and VFX pipelines.