DCP Verification Error Codes

[serpico009]

Hello, all.

I ran a DCP I recently created using DCP-o-matic 2 through the Player's verification tool, and received the following errors; I was hoping for some details about what they mean, and whether they'll be an impediment to playback in the cinema.

Looking through some other posts, it seems like some of these errors are benign, and others may have to do with the DCP being read off an external hard drive during the Verify process. I have not copied the DCP back to my computer hard drive to double-check.

Any insights would be appreciated.

Errors (X's in place of actual file name):

The hash of the picture asset xxxx.mxf does not agree with the PKL file. This probably means that the asset file is corrupt.

SMPTE Bv2.1 errors:

A 2K JPEG2000 frame has 2 guard bits instead of 1.
The DCP is a feature but has no FFEC (first frame of end credits) marker.
The DCP is a feature but has no FFMC (first frame of moving credits) marker.
The CPL c3dd8cec-5374-46e3-881e-8921f70dbcce has no CPL metadata tag.

Warnings:

The DCP has no FFOC (first frame of content) marker.
The DCP has no LFOC (last frame of content) marker.

[carl]

All those errors/warnings are fairly benign except the one about the hash being wrong. This indicates that data is being corrupted either on being written to the external drive, or on being read back (or both). If it happens on write, that is almost certain to cause major problems with playback.

Perhaps you could say what operating system you are using and how the external drive is formatted.

[serpico009]

Hi Carl, thanks for responding.

I'm using the latest stable version of DCP-o-matic 2 on a Late 2013 iMac with OS 10.14.6.

The external drive is a Lacie RAID drive formatted Mac OS Extended (Journaled).

Unfortunately, that's where I'm storing all of my DCPs. I copy them over to the external drive, and then delete them from my Mac. In most cases, however, I am uploading those DCPs wherever they need to go (Dropbox, MASV, etc) from my hard drive before archiving them on the external drive.

I assume that copying the DCP back to the iMac hard drive for testing wouldn't make sense, then. But I'm in the process of trying it anyway.

[carl]

Unfortunately there are persistent reports of strange problems like this when using external RAID / NAS devices and DCP-o-matic, and I have so far been unable to reproduce any of them.

I suspect that somewhere down the line DoM is doing something wrong when reading from/writing to devices that sometimes experience network/bus delays.

If you copy the DCP back to the iMac hard drive and it then verifies OK it would support my suspicions! Do let us know what you find.

Out of interest, what model is your external RAID?

[serpico009]

Carl, good morning.

The external drive is a LaCie 2big Thunderbolt 2 drive. I'm using the Thunderbolt connection to mount the drive to my iMac.

As I mentioned, all of my DCP file packages are saved there, including both projects I've made myself and projects received from other producers/filmmakers.

I've spent the morning using DoM Player's Verify tool to check the DCPs one by one.

So far, only the DCP that prompted the original post has returned the "The hash of the picture asset xxxx.mxf does not agree with the PKL file. This probably means that the asset file is corrupt" error. That includes both professionally authored DCPs obtained from other producers/filmmakers (including one made with DCP-o-matic 2.10.5 back in 2018) as well as those made by me with the current stable version of DoM.

Based on the above, it doesn't seem like any file corruption was introduced by copying to the LaCie. More likely, there's something I did wrong when I created this particular DCP. I plan on re-creating and testing it directly from the iMac hard drive later today.

In the meantime, what else could cause the hash error? Are there any other known causes? Is there any information I could supply about this particular project that might help pin this down?

Some basic details about the project in question:

• All of my projects, including this one, use two film files: a 5 second and 11 frame company logo clip (MP4), followed by that particular film's source file (a ProRes in this instance, MP4 for some others).

• Everything is 23.98, being converted in DoM to 24fps (or 100.1% speed)

• Some of the films have 5.1 mixes, most have stereo. This project uses a 5.1 mix from the ProRes that is mixed down, ie it is not 6 individual mono audio tracks

• I've done some manipulation of the feature's audio channels, including increasing the overall volume by +5dBs and lowering the L and R volumes by about -3dBs each to give the center channel some room

• Under the timing tab, in all my projects including this one, I have the feature set to start at 5 seconds and 11 frames, the same point where the logo clip ends.

• All of the DCPs I've created, including this one, are SMPTE, save for one Interop project

[Carsten]

The hash error can only be caused by a technical issue, not a bad choice of DCP parameters or source footage. Something went wrong during or after writing the DCP. Some servers may still offer to play the DCP, but probably most of todays servers will reject it with a similar error. You may, though, try to repair the DCP with DCP-o-matic. Import it, create a new DCP from it. You will probably need to tick 'recompress' in order for DCP-o-matic to create new media assets. One may also try to identify the specific asset in question and have a look at it. Sometime the issue may show in the form of a corrupted frame. Sometime, even if some data is corrupt, nothing can be seen, because the error is small. Sometimes, DCP-o-matic may even crash reading that frame. In theory, and for some strange reason, it could be that the video MXF is 100% correct, and the hash value is bad.

Rarely, hash errors can be caused not by defective stored data, but by a a read error during the hash verification. In that case, the DCP could be 100% correct, and the error is misleading. May be caused by a bad removable drive connection, computer memory, or driver issue. Sometimes, performing the check on the same DCP on a different computer may show no errors.

[Sailing Cookie]

Hi Carl,

Thanks a lot for your software (amazing).

I have the following message on a DCP that plays fine on my station (in Da Vinci and DCP o Matic player), but crashes a server (don't know which brand) :

SMPTE Bv2.1 errors:
The CPL c3dd8cec-5374-46e3-881e-8921f70dbcce has no CPL metadata tag.

Warnings:
The DCP has no FFOC (first frame of content) marker.
The DCP has no LFOC (last frame of content) marker.

Could you elaborate a little on those ? Seems not to bad to me but do you think it can causes the server to stutter at a specific point in the film than crash (no error message) ?

Thanks

SC

[Carsten]

Those two errors (better: warnings, or hints) will not cause a server to crash. If DCP-o-matic does not report a hash problem, it could be a datarate or J2K codestream issue. Do you know which software was used to create this DCP/J2K?

[Sailing Cookie]

Thanks a lot Carsten,

Should have more infos soon but the DCP was made fully in Da Vinci Resolve with Kakadu encoder (limited at 220Mb/s in 2K scope).
Crashes only on Doremi server (work on others)....
Only info I have from now is that it crashes the server with no error message.

Any clue ?

SC

[Carsten]

Doremi and >200MBit/s is a known problem. Datarates need to be set conservative for classic Doremi servers. I have seen that happen myself, too, with a DCP that I created. I lowered the data rate (I think from 235MBit/s to 210MBit/s), and it played okay. The 235MBit/s never caused issues on other servers.
Yes, these Doremis should support 250MBit/s per spec, but certain combinations of data rate for individual color components break the Dolphin decoder, and this is not covered by any formal test.