Re: [DCP-o-matic] Signed or not

As far as I know, at some point unsigned SMPTE DCPs will be rejected by servers. I don't know which server currently enforces that already. Signing usually will prevent others from doing changes to the DCP. That could be a benefit or not. I have yet to do some testing of signed/unsigned Interop and SMPTE content on different servers to find out what happens. I did some test previously on our Sony which shows various validation indicators for ingested content. I haven't been able to find out exactly what they are based on, because they vary even for 'commercially' generated content - trailers, features, etc. I follow the ISDCF maling list for a while now and the ISDCF's struggle in the transition from Interop to SMPTE formatting. It's a simple technical, but complex behavioural process, which in turn makes it a complex technical matter again because of a necessary transitional process in order have no lost shows. Also we should not take for granted that the DCP-o-matic is doing it is completely right or the only way to implement it. We recently had an issue with a commercial DCP that was one of our first tests of an IP based download from a german content provider. We were able to ingest it okay, it would show up in the list of ingested features, but we couldn't select the CPL for playback, it simply didn't turn up in that CPL list. So there was obviously something wrong with it. Another download fixed it, but we weren't even sure wether they had changed something in the file now or if it was a download issue (a dedicated download client is used). As far as I know, 'Signing' is for authorative preventing of intentional or unintentional manipulation, while 'file hashes' provide some technical means to assure proper transmission and storage. Then a server could do some additional checks to make sure the content is correct, e.g. checking for valid audio or J2k file structures. I don't know which server applies which strategies. Most do some checking while or after ingesting. - Carsten