Easy DCP checking error: Track "_j2c_.mxf" uses not specified p

[deliusan]

Hello everyone,
I am a happy DCPoMatic user for some time. Thanks to this forum I managed to fix a number of issues without having to open a topic, until now. I hope someone can shed some light into this issue:
I am using DCPoMatic 2.18.10 on a MacOS 13.5.1 Ventura. I made an encrypted SMPTE DCP for a 90min film. I made an OV clean version with the film, then I created a version file adding only subtitles on top of the OV. The jpg2000 sequence was already made from Resolve, DCPoMatic was set not to re-encode the jpg2000 stream, as it was already in the correct color space, data rate (190mbit/sec), etc. In the "NonStandard" settings tab I had the option "Allow use of SMPTE Bv2.0" un-ticked. The Player showed no errors upon checking, except some subtitles that had too many characters, etc. The problem appeared in the Cinema server, the version file CPL would not open. Could not find out which server was used. But I used EasyDCP to check the DCP, I attached the only error it showed. The error looks like this:
Track "FilmName_FTR-3_OV_enc_j2c_0bd2fa33-886a-424a-b8e6-fb074988c0d8.mxf" uses not specified profile "Profile 0".
The film is in a festival now, I prefer not showing the actual name, I hope you don't mind. I also attached a print screen with all the details.
Did someone see this error before?

Thank you very much for everyone's time! Please let me know if you need any more info.

[mdudzik]

Exporting JPEG2000 sequence directly from Resolve is a bad practice -- and wrong encoding profile is the exact reason. It will play on some servers, will stutter on others and on some it will crash at the start.

To my best knowledge there's no way to do it properly (unless you're using export as DCP option, not JPEG2000 sequence) -- but please correct me if I'm wrong.

What version of Resolve are you using?

[StephW999]

absolutely, it's possible on Resolve that the output jpeg2000 profile was set to IMF instead of DCI

[IoannisSyrogiannis]

The error that the cinema server showed could have been instrumental on figuring out what went wrong.
Though, you mean that the OV and the VF were ingested and validated on the server, but the VF, after the OV was also ingested, would show an error? Or wouldn't show anything?
Or the CPL would not appear?
I have close to zero experience with EasyDCP, but I wouldn't consider it impossible to be that the error 13 of EasyDCP (checking with SMPTE RDD 52 specs, among others) and the problem on the server to be two different things, that don't affect one-another. So, I would consider starting by troubleshooting the problem on the server. Especially if the validation from DCP-o-matic player is trouble free. (Indeed, the DCP-o-matic Verifier does not support encryption for the time being.)

Often enough, with computers, the issues are simpler than we find when we go looking. Best to start from defining the problem, not go looking for one to solve.

@StephW999
What you write makes sense, but wouldn't that be caught by verification, especially if "verify picture asset details" was checked?

[carl]

What you write makes sense, but wouldn't that be caught by verification, especially if "verify picture asset details" was checked?

If we're talking about the "codestream capabilities" in the J2K header, DCP-o-matic unfortunately isn't currently checking that. If anyone has one of these bad IMF MXFs from Resolve lying around that they could send me, that would help!

[StephW999]

Hello Carl,
Here's a link to download a sequence of jpeg2000 withIMF profile. If that helps,
https://we.tl/t-PAxlqsXcWp

[carl]

Thanks!

[deliusan]

Exporting JPEG2000 sequence directly from Resolve is a bad practice -- and wrong encoding profile is the exact reason. It will play on some servers, will stutter on others and on some it will crash at the start.

To my best knowledge there's no way to do it properly (unless you're using export as DCP option, not JPEG2000 sequence) -- but please correct me if I'm wrong.

What version of Resolve are you using?

I am using Resolve 18.6 on the same Mac. Exporting as Jpeg2000 sequencce with "Kakadu DCP codec". This seems to work well from the color space point of view at least. I limit the datarate to 190mbit/sec to keep everything safe regarding old cinema servers. In this case, DCPoMatic just pacckages the image into MXF without any further encoding. So are you saying this type of export renders jpg2000 files with the wrong metadata?
Thank you!

[deliusan]

The error that the cinema server showed could have been instrumental on figuring out what went wrong.
Though, you mean that the OV and the VF were ingested and validated on the server, but the VF, after the OV was also ingested, would show an error? Or wouldn't show anything?
Or the CPL would not appear?
I have close to zero experience with EasyDCP, but I wouldn't consider it impossible to be that the error 13 of EasyDCP (checking with SMPTE RDD 52 specs, among others) and the problem on the server to be two different things, that don't affect one-another. So, I would consider starting by troubleshooting the problem on the server. Especially if the validation from DCP-o-matic player is trouble free. (Indeed, the DCP-o-matic Verifier does not support encryption for the time being.)

Often enough, with computers, the issues are simpler than we find when we go looking. Best to start from defining the problem, not go looking for one to solve.

@StephW999
What you write makes sense, but wouldn't that be caught by verification, especially if "verify picture asset details" was checked?

I asked for a picture with the error code from the cinema server, but I got nothing from them. They just said the CPL was simply "not read" by the cinema server. This is only for the version file CPL. Oddly enough, the OV DCP that actually contains the image+sound works.

[deliusan]

What you write makes sense, but wouldn't that be caught by verification, especially if "verify picture asset details" was checked?

If we're talking about the "codestream capabilities" in the J2K header, DCP-o-matic unfortunately isn't currently checking that. If anyone has one of these bad IMF MXFs from Resolve lying around that they could send me, that would help!

Hey, Carl! I will add more info here. The jpg2000 was rendered from Resolve, but not as IMF. I attached the settings. I also made a 1sec render from the same project, with the original settings, maybe it helps.

So I kept the same OV DCP. But instead of the VF-2 CPL that had errors, I made a new CPL (VF-3) with exactly the same settings, with one exception: in the "NonStandard" settings tab I ticked the option "Allow use of SMPTE Bv2.0". The cinema server accepted the new CPL without issues. I also checked the new CPL VF-3 in EasyDCP and this time there were no errors, just some warnings. I attached a new printscreen. Keeping in mind the same original Jpg2000 was used (same OV), it seems there is some metadata mismatch somewhere that the RDD52 format is not happy with... But it is interesting, because the OV had that option un-ticked when it was made and it worked standalone. So some problem appears when I create the additional CPL (that only adds subtitles) with the same setting. I hope all this helps! Thank you for your time!