VF DCP with subs for encrypted DCP

[Benja1972]

Huge amount of information!!!

I am trying to digest it slowly

Thank you Carsten.

I would propose to place this instruction in FAQ of DCP-o-matic

[Benja1972]

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

If I understand well in ALL cases even with version file which refers to OV assets we need to recreate KDM (for all assets in ensemble VF and OV) in DCP-o-matic directed to cinema projectors. Or for VF file connected to OV we also need to present original OV KDM issued for cinema projectors?

Thanks in advance
Sergei

[Carsten]

If I understand well in ALL cases even with version file which refers to OV assets we need to recreate KDM (for all assets in ensemble VF and OV) in DCP-o-matic directed to cinema projectors.

For encrypted content that needs to stay encrypted, yes.

Or for VF file connected to OV we also need to present original OV KDM issued for cinema projectors?

No, the OV needs it's own KDM only to be played in it's original form. For the VF to be played incl. the referenced OV assets, you only need to cretate a single new KDM targeted at the VF. This KDM needs to include all decryption keys for all assets referenced in the VF - those assets from the OV, plus new encrypted assets in the VF. DCP-o-matic will bundle OV and VF keys for you when you create the VF KDM.

KDMs connect specific projection systems with CPLs. CPLs use all assets needed for playout, so the KDM for this CPL needs to contain all asset decryption keys used by that CPL. At the moment of playout, KDMs or decryption keys for other CPLs are not usable for the server.

As KDMs are targeted at systems, not files, in this scenario where the OV will also need to be played (e.g. Original + synced or subtitled VF), there would be three KDMs involved

- DKDM A targeted at DCP-o-matic to unpack and reuse OV assets/keys, includes all OV asset keys
- KDM A targeted at projection system to play OV - includes all OV asset keys
- KDM B targeted at projection system to play VF - includes all OV asset keys that are reused in VF, plus new asset keys for VF assets.

In this example, DKDM A and KDM A contain exactly the same asset decryption keys, but are not identical KDMs, because DKDM A is encrypted/packed only to be used by your DCP-o-matic installation, while KDM A can only be used by the projection system it was targeted at. KDM A and KDM B would need to be reissued for other projection systems.

On the target projection system, you can play the encrypted VF even without having a KDM for the OV (or if that OV timeframe has expired). But you need to have the OV ingested fully at the server in order to play the VF. All projection systems I know do not care about the sequence for ingesting OV or VF - you can do OV first, VF following, or vice versa. They have no immediate interconnection. You may ingest a VF this week received from a broadband download, and the OV next week ingested from a hard drive. The moment the OV has been ingested fully, you can play it (if there is a valid KDM). If the VF is ingested, but not (yet) the OV, the VF is visible on the server, but even with a valid KDM and timeframe assigned, it can not be selected for playing.

I think I understand why many people get confused about the use of OV/VF and KDMs when creating dubbed or subtitled version - it's the idea that, if the server has a working KDM for the OV, why can't I just create a version file that plays with the OV, using the provided OV KDM and my own added assets (encrypted or not). But it doesn't work that way. If there is any encrypted content used by a CPL, then the KDM for this CPL needs to contain ALL decryption keys, not just those for the additional VF content. And in order to create a KDM with these decryption keys, you need to have a DKDM for the OV that allows you to extract these keys with DCP-o-matic.

Note that you can have a mix of encrypted and unencrypted content in a CPL. At playout time, the server will only look up keys for assets that are encrypted, unencrypted content is just played without decryption. This is used a lot in distribution - you would e.g. have an encrypted main feature that is introduced by a distributor logo/studio logo or copyright policy. As a studio logo or copyright policy isn't worth to be protected, and may be exchanged for different countrys, this part of the CPL is usually unencrypted. Encryption is always reel based, so in this case, the CPL could e.g. contain:

video_reel1_studiologo.mxf - audio_reel1_studiologo.mxf (both unencrypted)
video_reel2_feature.mxf - audio_reel2_feature.mxf (both encrypted)

Reel structures of OV and VF need to match. E.g. if your OV uses 7 reels for video and audio, and you want to replace the audio and create a dubbed VF, the audio in your VF also needs to be split into 7 reels, matching the OV video/audio reels. DCP-o-matic takes care of that if you select 'split by video content''. In that case, DCP-o-matic looks at the reel segmentation of referenced content (in this case, the video mxf), and splits the new audio so that it matches up. This is ONLY needed for when reusing with the OV/VF method. MXF Reuse, ReWrapping, Repackaging will allow you to alter reel structure if necessary.

Most people creating DCPs with DCP-o-matic will probably create one-reel DCPs (that is, one reel for video, one for audio, one for subtitles, etc), that is the default. If you re-use other DCPs, you may come across multi-reel compositions.
Except for heavy subtiling, using larger non-common font files (e.g. asian charsets), it is okay to create single reel DCPs. The single video mxf can grow quite large then, typically taking up 90% of the whole DCP size, but that is not a reel technical problem

I know this is all hard to understand and combine at first - as you see, DCP is a very different concept than MOV, MP4,,etc.

As DCP-o-matic makes it easy to convert simple videos into simple DCPs, it may appear as a simple format conversion - a MOV is converted into a DCP folder, no big deal. But when you want to go beyond simple 1:1 conversion, it get's tricky.

- Carsten

[scorpio81]

Reel structures of OV and VF need to match. E.g. if your OV uses 7 reels for video and audio, and you want to replace the audio and create a dubbed VF, the audio in your VF also needs to be split into 7 reels, matching the OV video/audio reels.

Well, ideally yes, but actually this isn't neccessary. There could be, for example, 7 video mxfs and 14 audio mxfs. To merge these into one video clip, CPL has reels, entry points and durations of reels. In this example, CPL will have 14 reels where each video mxf is splitted in two reels.
Using entry points and durations, one may split a one reel DCP (one video mxf and one audio mxf) into a 100 reel DCP but still with single audio and video mxf. This is how DCP editing is performed - reels are splitted, then a new or corrected video or audio could be inserted between reels or by replacing existing reels.

[Carsten]

Yes and no - 'reels' are CPL items, assets are file items. While an asset can be used by many reels, in part or fully, corresponding Video/Audio/Sub reels as established by their usage in CPLs need to match. So, while in general you can have 7 audio MXFs in a DCP, 9 video MXFs, and 12 reels in the CPL using these assets, you have to acknowledge:

- DCP-o-matic doesn't work like that, it will not create CPLs working that way when creating new DCPs - there is a strict one reel - one asset file relation

- reels as set in a CPL DO absolutely need to match, even if they access the MXF files in an unusual way. That is, there must always be one audio reel going with one video reel and one subtitle reel (if used), playing for the exact amount of time (timecode in the case of subs).

If you use the OV/VF approach, it is essential to understand that the OV assets can not be manipulated anymore. Consider them as residing remotely, and with DCP-o-matic having no way to rearrange them on a file level. As such, when creating a VF, DCP-o-matic needs to adjust the reel handling of the VF to that of the OV. This is also important for encrypted DCPs, as keys are conveyed in the KDM on an asset basis. You can not break up MXFs in an OV, as they are expected to stay untouched on the servers in the field, and need to keep their file/asset and key references.

What DCP-o-matic does when creating a VF is to look into the existing reel structure of the OV, and adapts the reel structure of the VF to that, so that in the VF CPL, each VF reel matches the corresponding OV reel, and so the VF reel structure has to follow the OV reel structure.

In theory, you could establish a new reel structure, but it would have to have certain limits as well (e.g. no less reels as assets, as you can not assign multiple assets to one reel). Also, interop subtitle files are in folders and referenced by folders, that structure as well as their timecodes in the XML file need to match reel structuring. Not a good idea to break this up, it would create a whole mess (for no useful reason).


Of course, if you create a new, fully self-contained DCP, you could use all sorts of tricks.If you don't use OV/VF packaging, you may load a full DCP and choose a new asset segmentation - because in this case, DCP-o-matic has access to all assets making up the new DCP, and is able to segment them as needed in the newly created DCP.

I was wondering wether there could be an option in DCP-o-matic to make long running stills (like black or 'intermission') by referencing the same content mxf again and again. Like referencing a 1s 'intermission' MXF 600 times.
This would also be a space saving option for having silent audio DCPs.
One possible issue preventing this is that it is undocumented how the various servers deal with very short blocks of MXF files. It could break their decoders. Some manufacturers claim that DCPs should not be shorter than 5s - don't know wether that is also the shortest possible length for an MXF file, audio or video. We also don't know wether some servers have limits about the number of reels that are allowed in one CPL.


- Carsten

[Benja1972]

Hi, once more time.

I would like to continue talking about OV to VF conversion for encrypted DCP. Thank you for all information I got here. And now I will have practical challenge, and I need help from community.

Here is my case. I am waiting from company OV DCP with KDM for my DoM installation and our cinema projectors. Timeframe for OV DCP will be September. For this period I need to make VF with french subtitles which I have in srt format. I prefer make it easy way, make VF DCP in DoM with reference to OV DCP and additional asset for subtitles unencrypted. After that I may produce KDM for VF which will contain all keys for all assets in VF DCP. The issue is that we are going to project VF DCP in November during our festival in 16-18 November. As I understood KDM for VF will not work in November. Company also mentioned that they provide us second KDM for festival period (16-18 November) without key for my DoM. But this KDM will not contain key for my subtitles asset, right? I am totally confused now. Should I send them my VF DCP with reference to OV but without video-audio content as they already have it?

My question is how I should correctly collaborate with our company to get working VF DCP during our festival timeframe? What should I ask them to provide and what should I send them back?

Thank you!

[BlackoutAM]

Hi everyone!

Carsten, thanks alot for the amount of insoframtion. My mind blowed up

I think I understand why many people get confused about the use of OV/VF and KDMs when creating dubbed or subtitled version - it's the idea that, if the server has a working KDM for the OV, why can't I just create a version file that plays with the OV, using the provided OV KDM and my own added assets (encrypted or not). But it doesn't work that way. If there is any encrypted content used by a CPL, then the KDM for this CPL needs to contain ALL decryption keys, not just those for the additional VF content. And in order to create a KDM with these decryption keys, you need to have a DKDM for the OV that allows you to extract these keys with DCP-o-matic.

- Carsten

I think this is my issue... I will get an OV DCP with KDM soon and I need to make VF with subtitles for it in DOM. Will it work or?.. I'm confused