Passing the options via the command line does work as expected.
1 2015-11-05 00:33:47
Re: Encryption Key and KeyID Are The Same In MXF (3 replies, posted in Support)
2 2015-11-03 14:27:38
Re: Encryption Key and KeyID Are The Same In MXF (3 replies, posted in Support)
I should elaborate that this was done via the GUI. I am going to try the command line directly next.
3 2015-11-03 14:18:23
Topic: Encryption Key and KeyID Are The Same In MXF (3 replies, posted in Support)
I've been playing around with using OpenDCP to make encrypted SMPTE MXFs, and have found that the package uses the Key ID field for both the Key and Key ID. This results in a track file that doesn't use the intended key, and more problematic, that the actual key is published in the Key ID.
I initially hoped that they were swapped, but it just looks like the same Key ID field is used for both value pairs. Obviously this would be a real problem in protecting content. 
You can verify this by making an encrypted MXF and using asdcp-unwrap -k to confirm which fields were used. Additionally, you can get the MXF's Key ID field by using asdcp-info -H test.mxf and looking for the "CryptographicKeyID = " field.
Thanks again for all your hard effort, it would be great to be able to use this package for encrypted asset creation!
-Erik
4 2014-11-24 19:04:51
Re: 7.1 Lrs/Rrs Mapped To Incorrect Channels (5 replies, posted in Support)
I've downloaded the Dolby Channel Identifier package and decomposed it into a readable WAV file.
If you look at the waveforms, you can see that channels 9 and 10 are silent, while 11 and 12 have "Left Rear Surround" and "Right Rear Surround" in them.
This follows the ISDCF spec for 7.1 package channel layout, as previously posted.
Package (DOLBY-71-CHANNEL-ID_TST_F_EN-XX_INT_71_2K_20110816_DLB):
https://drive.google.com/file/d/0B1jlgv … 91NzQ/edit
Screenshot:
http://goo.gl/vJn3Lu
5 2014-11-24 18:12:43
Re: 7.1 Lrs/Rrs Mapped To Incorrect Channels (5 replies, posted in Support)
Unfortunately, they are not correct in the way OpenDCP wraps them.
As the ISDCF document shows, if the old-style SDDS version of 7.1 were still used, which adds extra channels to the FRONT, it would be wrapping correctly. Unfortunately, 7.1 in its current state adds additional REAR channels.
Here's what you currently wrap:
1. L
2. R
3. C
4. Sub/LFE
5. Ls (5.1) / LsS (7.1)
6. Rs (5.1) / RsS (7.1)
7. HI
8. AD
9. Lc
10. Rc
11. Omitted
12. Omitted
To make properly formatted, contemporary 7.1 packages, there needs to be 12 total channels. I believe you have confused Lc/Rc for LsR/RsR.
Interop likely won't let you add channel labels, and if SMPTE does, of which there are few compliant players out there, it will require LsR/RsR and not the Lc/Rc mapping you currently use.
I'll see if I can find a 7.1 trailer and decompose its audio waveforms for you too examine.
6 2014-11-19 14:03:31
Topic: 7.1 Lrs/Rrs Mapped To Incorrect Channels (5 replies, posted in Support)
In doing a number of tests, comparing the generated packages made from openDCP with Wailua (the reference standard) and with the ISDCF audio channel layout document, it is apparent that openDCP assigns the extra two channels for 7.1 to the incorrect channels.
http://isdcf.com/ISDCF/Audio_Channels_16.html
The additional two channels for 7.1 DS are extra REAR channels, not extra front channels, as are currently mapped via openDCP. The layout is fairly strange, as there are some legacy wiring issues that needed to be considered.
The packages currently made by openDCP actually map to the older-style Sony SDDS 7.1 system, where there are additional front/center channels. These are no longer really supported, and have never been used in Digital Cinema (to my knowledge).
Creating a industry-standard 7.1 DCP would result in the following channel layout:
1. LEFT
2. RIGHT
3. CENTER
4. LFE/Sub
5. Left Surround Side
6. Right Surround Side
7. Hearing Impaired (Or Silence)
8. Visual Descriptive (Or Silence)
9. Silence (Formerly Center Left)
10. Silence (Formerly Center Right)
11. Left Surround Rear
12. Right Surround Rear
This presents a bit of awkwardness when creating these packages, as equal-duration silence needs to be generated to pad channels 7-10.
Other than that, the software is fantastic, and I use it regularly for many non-commercial applications. I'd be a happy donor if we could just address this one minor issue.
Thanks!