VF DCP with subs for encrypted DCP

[jackkras]

Hello!

I have very important question and I don't understand if it possible or not.
Can I make VF DCP with subtitles for encrypted DCP if I haven't KDM for DCP-o-matic?
Our distributor don't want to give us KDM for DCP-o-matic (DKDM), only for cinema. And we want (and need) to make subtitles. Can we make VF DCP without KDM or this impossible?

Thank you very much.

[Carsten]

It's impossible without a (D)KDM.

- Carsten

[jackkras]

Thank you for answer!

As I understand, we haven't way to make screenings such DCPs with subtitles? Yes?

[cloud06]

I had similar issue. I don't get why they do it... Probably want to charge for versioning...

[Carsten]

Why they don't do it? If they give away a DKDM for an encrypted feature, it is no longer encrypted and safe for them. IF someone chooses to encrypt, it is logical they don't give out DKDMs lightheartedly.

There are options for external subtitles, but you have to find your way through it as well, and more complicated than DCP/XML subtitling.

- Carsten

[IoannisSyrogiannis]

I am not sure the original poster has in mind that, even if one can make a VF for an encrypted DCP, they will still have to use a KDM for it, and it won't be the same as the one for the OV, since the CPL (for one) will be different.
Theoretically, one can make a hand-made VF file, adding the unencrypted (xml) subtitles they can procure, but it wouldn't be of any use without the proper KDM to support reproduction (play-out).

All the above, supposing that DOM wouldn't decrypt an encrypted content, in order to transcode it to an unencrypted copy of it. If it does, my mistake, I didn't have a clue.

[Benja1972]

Hello!

I have kind of similar question or problem. I am helping make french subtitles for small film festival.

Suppose I would ask our distributors and would get from them DCP OV with KDM for my DCP-o-matic installation along with KDMs for our cinema projectors.
If I succeed to make DCP VF with french subtitles from OV does it means that VF will be totally enecrypted and it is only me who will decide to make it encrypted or not to provide to cinema? Do I need to provide KDM of OV for cinema? KDM for OV usually is limited by dates of festival with some extension. If I make new DCP VF with french subtitles unencrypted, will it works all the time? Or it will contain some encryption for original assets from OV?

Thanks for any kind of clarification.
Sergei

[Carsten]

Pfff, that probably deserves a long answer. However, the longer, the less probable that is being read
It certainly is a request we hear very often, so I guess it deserves a proper tutorial.

Let me think about it, and I will probably also do some test first to supply some screenshots.

- Carsten

[Benja1972]

Thank you, Carsten!

It is what I am looking for a long time. Two years ago I had negative experience on adding our home-made subtitles to encrypted DCP. This year we have new festival and I am hoping to make some progress as asking distributors to add our subtitles to their DCP costs us a lot of money.

Cheers
Sergei

[Carsten]

First of all - every CPL, every film version, uses a single KDM, but that KDM contains decryption keys for all encrypted assets being used by this specific CPL. So, in fact, a movie doesn't use a single encryption key, but multiple keys. e.g. a CPL using 3 reels of encrypted video, audio and subtitles (SMPTE) already uses 9 decryption keys. You don't have to deal with them individually, as the KDM bundles them nicely, and the server will assign each key to each asset during playout. Keys and assets find themselves by numbering them.

In theory, every asset can have it's own encryption key value. I don't know how many DCP mastering systems actually use that option. If you encrypt in DCP-o-matic, every encrypted asset uses the same encryption key value, as only one key is created in the GUI when you choose 'Encrypted' (either chosen randomly, or set manually). When creating the KDM for an encrypted CPL, DCP-o-matic will copy the same key value into all encrypted asset keys. So, even with only one key configured in DOM, every asset has it's own encryption key, but their value is all the same.

That said - no, an asset that has a valid decryption key with another CPL (e.g. OV), will not use that key entry for decryption of a VF CPL referencing the same asset. Every CPL must carry all keys in it's KDM needed to decrypt every single asset assessed by that CPL. Of cause, these keys needed for shared assets have the same values, but the server treats them as completely separate data. We often receive english OVs and german VFs, but only KDMs for the german VF. The KDM for the german VF contains keys for the english video tracks, but we can not use them outside the context of the german VF. Also, every KDM comes with a playout time-frame. OV and VF KDMs may have different time-frames, even if they use the same key values for shared assets. Therefore, every KDM-CPL key bundle is self contained and unique.

So, when you get a DKDM for DCP-o-matic in order to create a version file of that encrypted CPL, and when you assign that DKDM to the OV, DCP-o-matic needs to 'open' the DKDM and extract all keys for all the assets that are referenced in the OV, then repackage them for the VF KDM. The original OV KDM or the DKDM is then no longer needed or useful for playout.

If you add new encrypted content to the VF (that is, encrypt the VF), DCP-o-matic also needs to add a new key to these pre-existing keys and later put pre-existing and new keys into the KDM targeted at this specific VF. If your OV is encrypted, your VF needs to be encrypted as well, there is no other way to transport the OV key references in the VF. You can of course create an encrypted VF that references an unencrypted OV.

(For those that may be confused by the terms 'keys' and KDM - 'Key' here is the symmetrical actual encryption key that is used to encrypt the individual assets. In a distribution situation, the encryption keys for all distributed DCPs/discs, etc. are the same across all media/duplicates.
The KDM is a 'bundle' of these keys, encrypted again, towards a specific projection system/server/media block (or mastering / KDM creation system in the case of DCP-o-matic, then it's called a DKDM). KDMs make sure that the necessarily identical decryption keys (across identical distribution media) can only be used by the specific target system the KDM is issued for. So the asset encryption/decryption keys become encrypted themselves in the KDM, and can only be decrypted (unpacked) and applied for decryption of assets/media by a specific server/media block.)


Also, keep in mind that for Interop DCPs, subtitles are packed into folders of fonts and XML subtitle files per reel, and always stay unencrypted. For SMPTE DCPs, subtitle fonts and XML files are wrapped into MXFs per reel (and encrypted if chosen so).
DCP-o-matic will automatically adjust the asset/subtitle file handling based on the chosen wrapping type (Interop or SMPTE), there is no need to adjust this manually. Note that you can not mix SMPTE and Interop for OV and VF - they always need to match. DCP-o-matic will detect and complain if you try to create an Interop VF based on a SMPTE OV or vice versa. You may, though, be able to convert a SMPTE DCP into an Interop DCP or vice versa using one of the rewrapping methods explained below.


Now - to create a new DCP from an encrypted 'master' DCP, there are actually four ways (!) to do this:

- by creating a version file, that is, only adding additional assets to the VF (like subtitles), but re-use preingested content from the OV
Most people prefer this method as it saves space, because only a small VF package (in the case of a subtitle VF) needs to be distributed in addition to the OV carrying all major video and audio assets.

- by CPL re-wrapping, that is, not just referencing external assets, but repacking them into a new complete DCP according to the CPL of the existing DCP. You import the pre-existing DCP/CPL into DCP-o-matic, and leave 'refer to existing DCP' unchecked. Then, upon DCP creation, DCP-o-matic will compile all assets active in this project into a new self contained DCP, thereby following the order set in the original CPL. If any assets are encrypted, and a DKDM has been assigned to the CPL using them, DCP-o-matic needs to decrypt all assets, and put's them into the new DCP. This new DCP may stay unencrypted (thus being converted from encrypted to unencrypted), or may again be encrypted with a new key that is chosen randomly, or setup manually under the DCP tab 'Encrypted'/'Key'. This re-encryption is NOT a re-encoding. DCP-o-matic just unscrambles and rescrambles the data, but the video J2C frames, audio or subtitles themselves remain untouched. That way, the original decryption key of the original DCP/CPL is lost, and a new key is used (and later wrapped into the KDMs).

- by asset-rewrapping, where you ignore the CPL, but import all assets individually into DCP-o-matic, the MXF video, audio, and subtitle XML (interop) or mxf wrapped subtile (SMPTE) files. Very similar to the CPL re-wrapping, but you have access to the individual assets, and may, e.g. discard a specific reel, replace an audio or subtitle MXF, resync, etc. This asset rewrapping may be useful if for some reason, the CPL using these assets, or other metadata, like assetmap, packaging list, etc. is lost or corrupt, so a CPL/DCP can not be recognized by a server or DCP-o-matic. This DCP will then not ingest or play on DCI servers, but you may rescue it by rewrapping it's assets into a new functional CPL/DCP. However, if these assets had been encrypted, there is no way to have DCP-o-matic decrypt them currently. DCP-o-matic will only accept CPL referenced KDMs, not individual-per-asset decryption keys.

- by re-encoding (re-compression), where you will import either the full CPL, or the individual assets, and actually recompress (for video) or reformat (audio/subs) the data into a new DCP.
If you don't alter any content parameters before clicking 'Make DCP', DCP-o-matic will not re-encode, but re-wrap. If you introduce the smallest amount of cropping, color transform change, or adjust audio level, mapping, etc., DCP-o-matic needs to re-compress, re-process, etc. the assets, which will take much longer than rewrapping. I think, currently there is no way to actively trigger DCP-o-matic into re-encoding without any changes applied to the assets. The speed that you will experience during the making of the DCP usually is a clear indicator of what is going on. Re-Wrapping will fly through the files, while re-compression will take ages again.

All Re-Wrapping and Re-Compression methods will create a new, fully self-contained DCP, while of course, a version file created by refering to a pre-existing DCP/CPL will always need this OV to be ingested together with the VF.

I do see quite a few commercially mastered DCPs that do not use the OV/VF approach for alternative versions - simply because it demands some attention by the distributor and cinema to manage OVs and VFs, and, hard discs are big enough nowadays to host multiple self-contained DCPs. If you distribute through broadband networks, then of course the OV/VF system is unbeatable in saving transmission time and cost.

So much for now, I told you it will be long, and it's not even a tutorial yet

- Carsten