Decrypting VF for use with decrypted OV

[IoannisSyrogiannis]

I ran into a problem, again today, and I wanted to pick your minds on that.
Manipulating a number of DCPs, I have -every now and then- to either encrypt, for exhibition, or decrypt, for archiving a number of DCPs, including OVs and VFs.
Because of the relatively less restrained character of the non-encrypted DCPs, creating encrypted out of them is less demanding in terms of steps necessary.
Going the other way, though (encrypted -> non encrypted, is more complicated, when one wants to make VFs. Writing exclusively about SMPTE packages, examples of encrypted VFs may include:
A VF that only holds a version with the animated logo of a festival (additional reel).
A VF that only holds a subtitle version.
A VF that holds the 7.1 audio version of a 5.1, or (more scarcely, but still appears in newer productions) the IAB (Immersive Audio Stream) audio version.
A random (I use the word loosely) combination of the above.

As things stand and according to my understanding of DCP-o-matic's functions, what I have to do (A) before dealing with versions, is to create an OV of the encrypted one.
B) For the VF (let's say it is a subtitle VF, since that's the most common case), I add to a project the encrypted VF, I am asked for the OV and then the DKDM and, then, I am allowed to make a non-encrypted VF for the encrypted OV.
C) Then, I have to use the decrypted essences, in order to add as files (not a DCP) to a new project, where I first add the OV and set it to be used as reference.
The last step will be the one that will create the non-encrypted VF for the non-encrypted OV.


First of all, I should mention here that if one couldn't make a non-encrypted VF for an encrypted OV, the only way would have been to decrypt the version file (VF) as a complete DCP (OV) and then to use the subtitle MXF file for making the version file for the non-encrypted DCP. Therefore, I am really glad that one can do just that: Make a VF with unencrypted essences that has encrypted content on the OV.
(I don't know if this is relevant to this bug or not. If it is, a warning would have been better than not allowing to do so.)

Then, my question is this: Is there a way to skip step B?
Meaning:
1) Import an encrypted VF
2) Import a DKDM (but not the OV as well)
3) Reference an other OV (non-encrypted), instead of the OV this VF was created for.

I tried to import to the project both the encrypted OV and the non-encrypted DCP, so I could try to discard the video and audio reels of the encrypted and set on VF settings a reference to the non-encrypted.
If I do just importing, the timing will be wrong (one DCP after another).
If I try to change the timing, I can't reference anything.

[carl]

It seems to me that the "tricky" or more unusual step here is where you take your decrypted VF (referring to an encrypted OV) and you want to make that VF refer to a different OV (i.e. an OV where all the IDs are different) but which just so happens to have the same pattern of asset and reel lengths. I can't imagine a situation where this would be useful other than this case of creating a decrypted copy of an encrypted DCP, and I also can't imagine what general UI you might offer to make this kind of thing easy.

I don't have any great ideas but two ways forward that come to mind are:

• Just make a separate tool to handle this - give it a VF/OV set and tell it to encrypt or decrypt it.
• Add some "Replace OV" option on the content context menu, so you'd add your decrypted VF, give it the encrypted OV, then right-click on the VF in the content list, choose "Replace OV...", give it the unencrypted OV and do "Make DCP" again.

[IoannisSyrogiannis]

Indeed, the reference to the OV is the tricky part. Which part would have to play its role in both ways you mention. Since, in the case of the VF (on the OV/VF set), one needs to do just the same.

The other situation is when creating encrypted versions out of decrypted ones. Imagine the following scenario: You make two or more (subtitled) versions of your movie, to feed the festival demand with your short or full feature length. Often enough, decrypted is less trouble and you go with that. Especially if you want to have check-screenings. Then, you want to forward those packages for regular screenings. The need for more regulation is greater and then encryption is knocking on your door as well. At least on my local market, that is the most common course of things. Even though, many local productions reach their television period very soon.
The other case where decrypted -> encrypted is useful is when "classics" find their way to foreign screenings, where the circumstances are unknown and unpredictable. A cinema or a festival wants to screen „BeFreier und Befreite“. The Kinematek has the DCPs they use for their shows (subtitled, with audio description, etc.), but wants to send away and therefore encrypt. A cinema archive that offers screenings make sense to keep non-encrypted DCPs in storage. Sending abroad is where few selected titles need to be encrypted.

Myself, recently, had to go either way. Either because the original screening DCP would be good to be archived unencrypted, or because an encrypted copy was deemed the wise choice for sending abroad titles that were never hit the market as high-definition. You know a well known movie that has no DCP, nor HD candidate around? (There is a BD, I think Spanish, around.) I would never have guessed: „The Wall“!

Without having figured out the best way to go about it, I wonder why one would need to go all that way around with option B (replace OV):
One could have added on the project the original, encrypted VF, then add the KDM, and then choose to "Replace OV..." and "Make DCP" again.
The tricky part here would have been VFs on VFs. Meaning, EN-XX 5.1 original OV, EN-XX 5.1 (with "Media Creative Europe") VF, EN-FR 5.1 (subtitles only) VF for the "Media Creative Europe" version.

It goes without saying that the option A (whole set of OV and VFs encrypted or decrypted in one go) would be the easiest for the end user.
I will take a break, because it's way past midnight and come back with how I imagine such a procedure could work.
Yet, I think that the option A, with the option of having an offset, in case of an added animation, like "move all to start of reel number #" would save the time of rendering a DCP, in order to harvest its essences and re-build on the new encrypted/decrypted OV.

[carl]

It might be interesting to consider a change so that a single project can produce multiple DCPs. I never liked the workflow for making VFs.

Maybe you could add A.mp4, B.wav and C.srt to a project, then somehow say "A and B are in the OV, C in a VF", click "Make DCPs" and both OV and VF are made.

Then for your case you could load the encrypted VF and OV, they would automatically be set up so that VF goes in the VF, OV goes in the OV, make sure encrypted is not ticked, click "Make DCPs" and you're finished.

I guess the existing workflow of "make an OV, add it to a new project, then add the VF components and make the VF" could also be handled by a third option in the "where does this content end up" choice: so each piece of content (or perhaps each component of each piece of content) goes: Nowhere, OV or VF.

[IoannisSyrogiannis]

This is an approach that sees versioning as part of a greater project. And, while it asks for either having all the version files available upon creating the DCP (1), or retaining the project files and/or folder until the final product is rendered, it benefits from a tidier structure and a wider overview (the word "holistic" came to mind) of the project. It could even had the choice to pass those OVs and VFs to the combiner.

There is a drawback, of course. It would call for a new, more "advanced" user interface, to the end of making things clearer with more than one content files (and probably reels) and more manageable(2). While I would have been more than happy to see DCP-o-matic going that way, it might end up being less intuitive and/or less friendly for an unexperienced user that wants to just make things work with an MP4 or a ProRes.

1) Not only one subtitle, or audio, but more, even. And assigning each essence to the OV or more than one VFs.
2) I am imagining the content list to be split to reel tabs as well, depending on reel/content, or -alternatively- being grouped into blocks (vertical segregation). Another, more radical change would have been built a representation of the timeline under or over where the status info and bars are now, giving it more of a non-linear editing feeling, while timing (or reel assignment) is handled by the lower half of the content list, as it is now and would be brought up by either clicking the content in question, or its representation on the timeline. All of those implementations/changes would cost long development hours and higher complexity (=> more bugs), though.

[carl]

There is a drawback, of course. It would call for a new, more "advanced" user interface, to the end of making things clearer with more than one content files (and probably reels) and more manageable(2). While I would have been more than happy to see DCP-o-matic going that way, it might end up being less intuitive and/or less friendly for an unexperienced user that wants to just make things work with an MP4 or a ProRes.

This was one of the motivations for putting the VF controls into a separate dialogue - before there was this ugly and confusing checkbox "make VF and refer to OV" in the video/audio/subtitle tabs and it was nice to move them into a dialogue. Then you can just ignore that stuff if you don't care.

If we could hide the "where does this content go" UI enough I think this creation of multiple DCPs per project could be quite invisible to the casual user. Everything defaults to going into the OV.

I think the question is how do you specify what goes where... in particular, what granularity do you need? I guess, for example, you want to be able to load a MP4 with embedded subtitles and have the image/sound go to OV and the subtitles to VF, which suggests either a quite complex matrix in the VF dialog, or putting things back into the video/audio/subtitle tabs (which seems a shame).

[carl]

am imagining the content list to be split to reel tabs as well, depending on reel/content, or -alternatively- being grouped into blocks (vertical segregation). Another, more radical change would have been built a representation of the timeline under or over where the status info and bars are now, giving it more of a non-linear editing feeling, while timing (or reel assignment) is handled by the lower half of the content list, as it is now and would be brought up by either clicking the content in question, or its representation on the timeline. All of those implementations/changes would cost long development hours and higher complexity (=> more bugs), though.

It seems to me like reel management is mostly a separate topic, and I agree that the UI implications for providing comprehensive reel control feel a lot more complicated.

[IoannisSyrogiannis]

It seems to me like reel management is mostly a separate topic, and I agree that the UI implications for providing comprehensive reel control feel a lot more complicated.

It may as well be, if you think of reels instead of (imported) content that is meant to play alongside. (Two MP4 files, one after another.)

This was one of the motivations for putting the VF controls into a separate dialogue - before there was this ugly and confusing checkbox "make VF and refer to OV" in the video/audio/subtitle tabs and it was nice to move them into a dialogue. Then you can just ignore that stuff if you don't care.

If we could hide the "where does this content go" UI enough I think this creation of multiple DCPs per project could be quite invisible to the casual user. Everything defaults to going into the OV.

I think the question is how do you specify what goes where... in particular, what granularity do you need? I guess, for example, you want to be able to load a MP4 with embedded subtitles and have the image/sound go to OV and the subtitles to VF, which suggests either a quite complex matrix in the VF dialog, or putting things back into the video/audio/subtitle tabs (which seems a shame).

One simple to work with but less simple to create solution might have been a matrix that would include all version files on one side and start with one receptor on the other side, with additional ones introduced with a plus sign.

I imagine a scenario where a BluRay disc has different audio files and one exports into an MKV two different audio streams and three different subtitles. For the sake of simplicity, we will imagine that the subtitles are OCRed into text, instead of image. We are also not having any subtitles on the OV. It happens, sometimes, that there is, due to different dialogues etc.

For the sake of simplicity, we will also imagine that there is only one .mkv file as content.

OV-VF.PNG

That might have had another, less demanding representation, but that would have been something like the matrix used on the audio configuration tab.

[carl]

Interesting... I wonder we could tweak that to
1. derive the correct OV automatically (i.e. minimise the overall DCP size, or something) so we don't have to specify it, then
2. flip everything left to right so that we can use drop-down boxes instead of 1-to-many lines.

ui.png

[IoannisSyrogiannis]

The final number of CPLs shouldn't (forcibly) be all possible combinations of audio language and subtitle language, since a combination DE-VLS, for instance, wouldn't serve much of an audience (to be honest, my example of FR-VLS is not frequent either, on an American title, Flemish AND French subtitles are more common than a French overdub with Flemish subtitles). Same with FR-FR or DE-DE.
Yet, if there are X audio languages and Y subtitles on play, a minimum of X+Y-1 combinations would make sense. That would be all audio languages in use, and all subtitle languages in use with at least one audio language. "+" / "-" signs for customizing would make sense afterwards.

The language of each audio is (mostly) specified by the user, or by metadata in the file. So, on the first case, the OV may be also specified by the user. On the second case, a preset of first audio stream is OV with the ability to edit would/should be working well.

In regards to audio, and especially for masters with discrete audio channels or separate files, assigning would still be a thing.

Having the OV according to the smaller DCP size could not work if there is -say- an English 5.1 with a Spanish 2.0 overdub. And if one goes with the prompt to choose 8 or 16 audio channels, the output would be the same. The other way around, having the biggest package, would probably auto-pick the Atmos version as OV. Not a catastrophe, but not ideal either.