27 Feb
2018
27 Feb
'18
9:48 p.m.
Hi Jim,
I think we can do it by loading the bad DCP into DoM and re-making it. I
believe the error is in the signer certificates that DCP-o-matic created
for you the first time it ran. The quickest fix, if you don't mind, would
be for you to send me your DCP-o-matic's config.xml (off-list, as it
contains secrets), then I can put in some new certificates and send it you
back.
If you then re-make the DCP and send me the CPL from it I can check to see
if the fix has stuck before you send it to MPS.
All the best,
Carl
On Tue, 27 Feb 2018, Jim Dummett wrote:
Thanks for very swift reply Carl. Great!
Yes, I am in a position to resupply to them. However, it'd be more practical
if I can rewrap an existing DCP using DCP-o-matic rather than encode again
from from the ProRes. I already made an unencrypted DCP in case of such an
eventuality. Obviously running a rewrap is pretty quick, whereas encode from
scratch will be an overnight job. They expect me to fix it fairly quickly or
hand it over to them to fix (not cheap I imagine).
I don't know if rewrapping is going to make the fix trickier though.
Anyway, I'll do whatever is most likely to create a resolution.
Many thanks,
Jim
On 27/02/2018 21:28, Carl Hetherington wrote:
Hi Jim,
I think I see what they are complaining about. Are you in a position to
make another DCP and get it re-checked?
All the best,
Carl
On Tue, 27 Feb 2018 20:24:55 +0000
Jim Dummett via DCPomatic <dcpomatic(a)carlh.net> wrote:
Hi Carl and all.
I've just had a DCP rejected at QC by Motion Picture Solutions.
The film is being distributed by a major studio (though it's a one-day
release, so not as big a deal as that sounds, it's really not big
budget). Foolish of me to get involved - I knew they'd run the DCP
through a QC process which was going to be incredibly tight, and I did
fear a fail based on something nitpicky. And so it is. Damn me for just
trying to help out!
There's a wider issue about how it might advantage market leaders to
ensure that DCPs created with "unprofessional" tools like DCP-o-matic
are branded as "faulty". But that's a rant for another day!
Anyway, below are the details I've been given so far. Of course, if any
chance of a swift fix, that'd be great. But more importantly I hope this
may be an opportunity to harden DCP-o-matic and get it one step closer
to being viewed on the same level as the big boys.
Here's the info:
DCP made using DCP-o-matic 2.10.5 on Mac OS 10.12.6. 2K Flat, Interop,
24fps, 20 minute reels. Made from ProResHQ 1080p 25fps.
The DCP is encrypted. Signing and encryption keys are the ones DCPoM
made automatically.
The reason given by MPS for QC fail is:
/"The cpl has been incorrectly signed - UTF8 rather than ASN.1//
//
//The following flag occurred on ingest: Hashed OK, but with flags such
as these in Wailua://
//
//crt=mp+ROXiXhhwYBtsBVkeaURJZD5s=;String encoding of Issuer O is not
ASN.1 PRINTABLESTRING: "UTF8STRING"//
//
//Now, whilst not a major issue – I wanted to flag it with you. It will
play on most systems but there is a chance it may not on some
players/servers.//"/
I've asked for the full Wailua output. Will post it here if I get it.
Here is a link to the DCP-o-matic project folder + DCP (MXF files
removed for size): https://fil.email/VUGNrpkk
I've redacted the encryption key in metadata.xml and file paths in the
DCPoM log files. The title of the film is not redacted but I would ask
if everyone could please avoid mentioning it on the mailing list. I
don't want to cause anyone embarrassment.
Has anyone come up against this before?
Many thanks,
Jim