DCP rejected due to Guardbit value

[ricardisimo]

Hi everyone. We got this same message from Deluxe regarding a SMPTE feature DCP (namely that rather than having a 1 or a 2 for the guardbit, our DCP had both) that I re-wrapped using version 2.18.33 git blahblahblah. There are a few wrinkles to this:

• The original DCP was Interop, and my end product was SMPTE

• I had to crop out the original opening logo via time code trimming, as the distributor had changed

• And finally, I started out the new composition with a new animated logo - an mp4 - reflective of the new distributor

Based on what I'm reading here, the dcpomatic version should not have been the issue, correct? Any idea if one of the details listed above was the culprit here? What I'm confused about is that this is supposed to be about resolution, namely 2k vs. 4k. But everything I was working with was exactly 2k scope, both the new mp4 logo and the original DCP.

Last question: Is it safe to say that Wolfgang's dcp_inspect tool simply does not check for this?

[Wolfgang Woehl]

Guard-bit values 1 for 2K and 2 for 4K are _not_ part of the DCI spec. Deluxe's claim may, in turn, originate in RDD 52's misleading attribution "as per DCI Digital Cinema System Specification" - they're just not in there. Bit like a cat chasing and catching its own tail.

JPEG 2000 permits guard-bit values from 0 through 7. RDD 52:2020/Bv2.1 narrows that range to one prescribed value for each D-Cinema resolution: 1 for 2K codestreams and 2 for 4K codestreams. This constrains encoder output and reduces the parameter space that cinema decoders need to handle reliably. As an interoperability measure, that makes sense.

It does not follow that other guard-bit values were previously undecodable or invalid. Decoders read the signalled value from the codestream, and the world did not end before Bv2.1 introduced this constraint - field truth, I reckon.

Sorry, I take cover when I get nerdsniped. And yes, dcp_inspect (the old CLI version) does not check this.

[barber]

Hi everyone. We got this same message from Deluxe regarding a SMPTE feature DCP (namely that rather than having a 1 or a 2 for the guardbit, our DCP had both) that I re-wrapped using version 2.18.33 git blahblahblah. There are a few wrinkles to this:

• The original DCP was Interop, and my end product was SMPTE

• I had to crop out the original opening logo via time code trimming, as the distributor had changed

• And finally, I started out the new composition with a new animated logo - an mp4 - reflective of the new distributor

Based on what I'm reading here, the dcpomatic version should not have been the issue, correct? Any idea if one of the details listed above was the culprit here?

Hi, here are some possible explanations:
- When you added the new logo, DCP-o-matic encoded the new JPEG2000 frames with a correct guardbit value for 2K.
- The original Interop DCP had an incorrect guardbit value for 2K and DoM just copied and rewrapped these frames

The Verifier tool in DCP-o-matic should show a warning about these guardbit values.
If you force re-encoding from JPEG2000 input, it will fix it.
Actually an inconsistent guardbit value across DCP reels is known to cause more problems and visible artefacts than a consistent incorrect value on all frames of a DCP, which is harmless.

[StephW999]

Guard-bit values 1 for 2K and 2 for 4K are _not_ part of the DCI spec. Deluxe's claim may, in turn, originate in RDD 52's misleading attribution "as per DCI Digital Cinema System Specification" -

+1
It also appears that easyDCP Creator and DaVinci Resolve create 4K DCPs with Bitguard=1. That's not a problem.

[ricardisimo]

I thank you all very kindly.