|
|
I am trying to find a thread that might be related to this within the forum, but I couldn't.
Though, I feel I should mention that on other DCP authoring programs, the choice to encrypt only some of the essences of a DCP is there. My experience comes from using CineAsset, where one could tick boxes on what essences were meant to be encrypted. On top of that, I have had in my hands at least one SMPTE DCP made on a third party authoring program that had the subtitles (only) non encrypted.
Therefore, if the question is that the essence created by DCPoMatic (for the VF) was not encrypted, that is not unheard of.
If it is that it (the new material) was not encrypted, but, without a KDM for the specific CPL that would include all the essences in question, the CPL should not play with the player, even if the KDM available includes all of the files that are encrypted (a repackaged DCP and rebuilt CPL) and is for the same target machine... well, it doesn't make any practical sense (with the keys available), but one can argue that it's the appropriate behavior. |
|
|
Based on the above, I tried today to make a VF with non-encrypted content for an OV that is encrypted.
The problem I came upon, and that was the only thing that seemed wrong to me and should be considered a missing feature or bug, is the fact that I could not create a (D)KDM for that CPL/VF.
I checked the CPL of the VF, the encrypted assets included the line:
<KeyId>urn:uuid:b1aaab1a-b1aa-b1aa-b1aa-b1ab1ab1ab1a</KeyId> (a different key ID for each asset, the encrypted DCP was not made in DCP-o-matic).
which on the .dcpdig file corresponded to the decryption key (<Key>) for the asset. The key itself was not apparent.
With the 2.18.20 player, I could not "play" the DCP. Yet, I haven't tried with the OV, VF and .dcpdig file inside the project folder. The OV was on another drive.
I got the "needs KDM" expected error. (And, closing the loop, no KDM could be created.) |
|
|
Can't edit note, so I am adding one:
Further testing showed that the non-encrypted VF DCP could be shown, both in the player and the author (the main editing application, that is), with the (D)KDM of the OV. Which is a savior of a situation, since the KDM for the non-encrypted VF couldn't be made.
It worth mentioning that using (D)KDMs for encrypted VFs (same video and audio with the OV, but encrypted subtitles with a different key - that is to say, not made by DCP-o-matic) would trigger an error, saying that this KDM was not made for this CPL.
This is a personal opinion:
That behavior is solely on DCP-o-matic. A digital cinema server would not allow screening that Version File. So, it is important to be able to create DKDMs and KDMs for a non encrypted VF of an encrypted OV, to make sure they are able to be screened.
On the other hand, allowing to create a VF that is not encrypted to complement an encrypted OV (or, in other DCP authoring software, to choose what you want to encrypt and what not) has nothing uncommon about it. As an ability, it shouldn't be excluded.
The question of being able to edit, or play a DCP VF using the (D)KDM for the OV that has all the encrypted assets, I understand that it is a gray area. Yet, from my point of view, and given that DCP-o-matic is not a commercial DCP player, but mostly a DCP authoring program, I welcome the simplicity that "issue" provides.
One can agree that this is cutting corners, but given the alternatives are not excluding the ability to import the VF in a project, but just time consuming, in order to get there, I find no wrong into saving time. |
