Validation of DCPs

[Kavenzmann]

Hi,

recently I had a few DCPs, made with DCP-o-matic, rejected from the servers.
The validation of the DCPs was always without any issues within DCP-o-matic.
easyDCP Demo gave me some errors, that are not further explsained. Need to pay first...

It's a 90 minute DCP encoded with Resolve in DCI Flat with a DCI full (2048x1080) picture that was scaled to fit the width of 1998 of the flat container.
Could this be a problem already?

How can I inspect/validate the DCP?
Unfortunately, I don'T have a Linux on hand for DCP Inspector and the validation of Dom seems to be not sufficient.

[Carsten]

>rejected

Any details about this? There are a number of possible reasons why even a formally correct DCP can not be detected or ingested or played on a server. Were you on site when this happened? Were there specific errors?

Which version of DCP-o-matic did you use to validate the DCP?

How was your workflow between Resolve and DCP-o-matic?

- Carsten

[StephW999]

Hello Kavenzmann , Hello Carsten,
Maybe it's just a problem of DCP naming.

The newest version of EasyDCP player (v4.0.x) inspect the title

https://registry-page.isdcf.com/general/
https://registry-page.isdcf.com/illustratedguide/

[Kavenzmann]

Hi,

i bought EasyDCP for one month to inspect the DCP as it's really short on time.
It was a naming issue as I forgot the date somehow...Stupid.

A really expensive mistake!

[Carsten]

Maybe EasyDCP (they are obviously making business from being overly picky), but DCP servers should never reject a DCP because of the title - unless you use very weird/illegal characters in your name. But a DCP with the simple name

'dcp', in folder 'dcp' should still ingest on every server. The ISDCF/DCNC name is not a mandatory standard, and to my knowledge, is not enforced by any server.

Occasionally, we do get commercials or trailers that do not follow the ISDCF/DCNC scheme, but they never caused problems.

When using DCP-o-matic, it is always a good idea to let DCP-o-matic create the ISDCF/DCNC name, though.

[Kavenzmann]

Yes.

The naming was not from DCP-o-matic but done by myself...

My problem is that this was the only warning I got from EasyDCP and I got no warning at all from Dom (latest version).
The DCP was rejected in 3 cinemas always because of a CPL issue or "missing media". But nobody could describe any better.

Let's see, the new DCP (made with Dom) is on its way to the cinemas again.

[Carsten]

These CPL/missing media issues are completely different (and severe), and are not caused by a bad name.

Can you show us a screen shot of the directory/file structure of this DCP?

How did you go from Davinci through DCP-o-matic with this DCP?


- Carsten

[gunnar]

These CPL/missing media issues are completely different (and severe), and are not caused by a bad name.

Carsten is right.
What I suspect is this rejection actually has nothing to do with the DCP nor the DoM itself.
If the DCP has now been rejected in three different cinemas the reason for that must be that the DCP got corrupted during transfer on the way to those cinemas.
Did you transfer it via FTP? If so then you must set your FTP client to binary as default transfer type. DCPs WILL get corrupted otherwise.

The naming issue is not the reason why three cinemas reject the very same DCP.

[Kavenzmann]

Hi,

the DCP was created directly by DaVinci Resolve, now I remember!

Here's the screenshot of the folder:

Bildschirmfoto 2022-01-14 um 11.13.41.png

Here's the new one with lower bitrate, that was okay.
Made with Dom out of a JPEG2000 sequence from Resolve and a 5.1 polyWAV file:

Bildschirmfoto 2022-01-14 um 11.10.16.png

I see, that the naming is completely different!

[Carsten]

Yeah, but everything is okay with the naming and the filenames. Again, they don't have to follow strict technical rules, it's just a recommendation that helps human operators to identify content.

If your DCPs are rejected by some servers, there must be other problems.


A JPEG2000 sequence from Resolve that has been reused (not recompressed) by DCP-o-matic is NOT DCI compliant! The JPEG2000 image export from Davinci Resolve was never meant to be used immediately in a DCP. We had loads of problems with these Resolve J2K sequences that have been piped through DCP-o-matic - people thought it was DCP-o-matic's fault, but it simply was not the correct workflow. Latest 2.15.x players should find these issues when validating. The previous hash-check-only validation in 2.14.x does not catch these issues.