Validation of DCPs

[Kavenzmann]

I did do quite some DCPs successful with Resolve only.
The Kakadu JPEG2000 export engine can export DCI compliant DCPs since some time now.

But it's far from hasslefree, still.

Nice, that you upgraded Dom's verification tools!
That was always one missing link for me.

But it didn't find any errors with the old rejected DCP.

[Carsten]

Kakadu yes, but not the generic JPEG2000 image sequence export.


If current DCP-o-matic 2.15 player validates your DCPs okay, and they fail with the mentioned errors on servers, it is most likely that something went wrong during transport. Corrupt media, bad filesystem driver, transmission protocol error, cable/connector issues, etc.

[Kavenzmann]

FYI: DCP is running just fine now.

As I remember, The issue was indeed Resolve and not DCP-o-matic.
Sadly, that I did buy a monthly EasyDCP license - next time the budget goes to Dom.

Thanks everybody for helping out!

[satantango]

Hi Kavenzmann and all.
Would you care to elaborate on why the kakadu dci export from resolve is far from hassle free? I have used fnord for a decade inside after effects but it is painfully slow, so was trying to switch to resolve now. Made some encodes that worked fine. Packing I do with dcp o matic or open dcp.
Thanks!

[IoannisSyrogiannis]

I will pick up this thread, because it has a fitting title and it mentions different verification methods between 2.14 and (nowadays) 2.16.
I would like carl, development, to consider having both type of info on failures.
What I mean:
I had an incoming for a festival, a multi-reel DCP that I firstly checked on an ICMP-X by playing out of its USB connection (no ingesting - no playing out the full feature). When ingesting, I was confronted with an error.
I checked on two different computers, one with one of the latest 2.14 versions, one with the latest 2.16.
The 2.16 version player reported:
- Could not read video frame X
- No errors found
The 2.14 version player reported:
- The hash of Y on the PKL file does not agree with the Y file.
Where "Y" is very helpful to determine which file is the problematic one. Otherwise, one will need to open the CPL and start figuring out what file that X frame resides into.

Also, I don't know if there is a viable solution to the following, but, for better or for worse, I am mentioning it:
If the Player tries to read a DCP to which the path name + the essences' names are long, it might end up not succeeding. Renaming folders of moving the DCP isn't always an option. Deluxe, on "Recommended Guidelines for Digital Cinema Source and DCP Content Delivery" does mention one or two things (3.2.4.2), but if a package can not be opened, it can not be checked as well...

Finally, whenever I try to validate a VF, (with the OV pointed out and loaded) it seems it fails. Yet, to be honest, I haven't tried that on v2.16.
Is it only me?

[Carsten]

While I am writing this, DCP-o-matic player 2.16.5 is verifying a VF/OV combo on my notebook. Seems to work now. One result of the verification is indication of the VF nature of the DCP. One can both verify just the VF, or the VF with the OV added.

The verification in 2.14.x was very basic, just the hash check and no progress, almost no reporting at all. I think a nice addition would be to save a full validation report. That would help in identifying long/convoluted file names/paths.

[IoannisSyrogiannis]

Yes, saving a full report might be helpful.
What I am trying to convey, though, is that I miss some original info that was already available in the past version and made work easier.
Determining the file that is failing, being able to see how long an encrypted DCP is, by sliding the pointer all the way to the end, those things that I could do or find with 2.14 and I can't any more.
So, they might be worth the consideration.

[Carsten]

I would also like to pass on the picture frame size verification, as it takes very long, and is not always necessary.

I guess this is all not complicated to do, we just need to make useful requests to Carl.

[carl]

Feel free to post bugs. I think I have a fix for the slider with encrypted DCPs. I think the other problems you mention can be summarised as:

• Failure to open DCPs with long pathnames (on Windows, I guess?)
• Picture frame size verification is slow.
• Bad error reporting with a corrupted video frame on 2.16.x (i.e. it gives an unhelpful error and also says "no errors found")?

Let me know if I missed something... and like I say, feel free to add things to the bug tracker - that way we can talk about the bugs directly, I can prioritise things, you get email updates when things change, etc... basically things are much less likely to get lost than if they are just in forum threads.

[IoannisSyrogiannis]

I, for one, will try from now on.
Yet, I am not familiar with the philosophy of filing a bug and the forum user interaction may help if the error lies on use.
Like that VF verification that I didn't know that goes O.K. nowadays.
So, I suppose efficiency lies in between the use of both.

P.S. Yes, that was Windows. I haven't yet had that on Linux.