[Fixes request] Validation

[cosmonaut786]

Hello, I would like to point some issues in the validation tool and request them to be fixed if possible.

- SMPTE FLAVOURS:
I've been getting warnings for SMPTE A DCPs not containing metadata, but according to the standards that is indeed correct (markers, CPL metadata, etc). I've attached a table explaining each DCP flavour.

- AUDIO NOT CONFIG 4 NOT FLAGGED
Validation is not flagging when audio is not config 4 (WTF) in SMPTE DCPs (shown in the attached table as well).

- GUARD BIT NOT SPECIFIED
Lastly, for guard bit flags, would it be possible to include which are the affected reels with incorrect guard bit values? AFAIK it's only an issue when there is a discrepancy within the package, but it would be great to be able to see what is the guard bit value of each reel. Sometimes it's just one reel with an incorrect value but there is no way of finding out which one, so the only way to fix it is by re-encoding the whole DCP.


Thanks!

[IoannisSyrogiannis]

You know, not everyone that reads this know that by "WTF" you mean "Wild Track Format".

But, for whomever may help, I want to take the opportunity to ask a question:
If I run `asdcp-info -H` on a video file of a DCP, is there somewhere among the results to check according to what version of SMPTE that DCP was authored?
Or, otherwise, is that obvious on the CPL or PKL or ASSETMAP files?

[carl]

- SMPTE FLAVOURS:
I've been getting warnings for SMPTE A DCPs not containing metadata, but according to the standards that is indeed correct (markers, CPL metadata, etc). I've attached a table explaining each DCP flavour

This warning should appear in the "SMPTE Bv2.1" tab though, I think? I've been a bit reluctant to indulge this "here's a standard, oh but no wait here's 3 different subsets of it, you can pick one and so will we, good luck" stuff but maybe we need to think about it a bit... as Ioannis points out, AFAIK there is no way to know which subset the DCP was supposed to be made with, so I went with the current approach of separating Bv2.1-only errors into their own tab. Another way could be to specify before verification which subset to verify against, but that's awkward when verifying multiple DCPs.

- AUDIO NOT CONFIG 4 NOT FLAGGED
Validation is not flagging when audio is not config 4 (WTF) in SMPTE DCPs (shown in the attached table as well).

Will fix: https://dcpomatic.com/bugs/view.php?id=2983

- GUARD BIT NOT SPECIFIED
Lastly, for guard bit flags, would it be possible to include which are the affected reels with incorrect guard bit values? AFAIK it's only an issue when there is a discrepancy within the package, but it would be great to be able to see what is the guard bit value of each reel. Sometimes it's just one reel with an incorrect value but there is no way of finding out which one, so the only way to fix it is by re-encoding the whole DCP.

Do you have a reference for this?

[StephW999]

hello Ioannis

yes, for PCM file essence there are indications like :

for smpte Bv2.1: (eg. for 5.1)
MCATagSymbol = sg51
Label Set Type: SMPTE
ChannelFormat: 4
ChannelAssignment: 060e2b34.0401010b.04020210.03010400

for smpte A:
idem Bv2.1 without MCA
ChannelFormat: 4
ChannelAssignment: 060e2b34.0401010b.04020210.03010400

for smpte original 429-2: (eg. for 5.1 - Channel configuration <> 4)
Label Set Type: SMPTE
ChannelFormat: 1
ChannelAssignment: 060e2b34.0401010b.04020210.03010100

for interop :
Label Set Type: InterOp

[IoannisSyrogiannis]

Thank you StephW999, that was helpful. (!)
I suppose that one deducts by elimination, then. That is a valid solution.
I knew about the SMPTE 429 2 Channel Configuration 4 symbol, but I was wondering if (in a same fashion that wild track format is shown by running ´asdcp-test -i audiofile.mxf´ and getting the ChannelAssignment) one could figure out what generation the SMPTE DCP was. Or, maybe, on the video essence.
Like if it was saying "Name = File Package: SMPTE 429-4 frame wrapping of JPEG 2000 codestreams", or "EssenceContainers: such-and-such" and that meant that it is Bv2.1, or 2.0, etc.

[StephW999]

@Ioannis
in dcp smpte "DCI-48" for jpeg2000 there is no difference in wrap between smpte 429 / A / B

@Carl
with DoM, when we do a DCP Bv2.0, there is an error in the CPL metadata :
in the <meta:ExtensionMetadata scope="http://isdcf.com/ns/cplmd/app"> tag
it should be:
meta:Value>SMPTE-RDD-52:2020-Bv2.0</meta:Value>
instead of meta:Value>SMPTE-RDD-52:2020-Bv2.1</meta:Value>

[carl]

with DoM, when we do a DCP Bv2.0, there is an error in the CPL metadata :
in the <meta:ExtensionMetadata scope="http://isdcf.com/ns/cplmd/app"> tag
it should be:
meta:Value>SMPTE-RDD-52:2020-Bv2.0</meta:Value>
instead of meta:Value>SMPTE-RDD-52:2020-Bv2.1</meta:Value>

Thanks, will fix.

https://dcpomatic.com/bugs/view.php?id=2988

[carl]

I'm not sure that a particular property of the PCM file really tells you how a DCP was intended to be authored... if a "Bv2.0" DCP is supposed to have features x, y and z, and it has only x and y, should the verifier report that z is missing, or that x and y are incorrectly present?

It feels clearer to me if we separate errors out according to the version of the standard that they violate (like we do now with Bv2.1 - if you don't care about complying with Bv2.1, the idea is that you can just ignore the things in that tab).

One could imagine a similar Bv2.0 tab, and if you only want to "achieve" SMPTE A then you can ignore both the Bv2.0 and Bv2.1 tabs. I hoped this sub-versioning thing would go away, but it seems that we're now stuck with it.

Is there something bad about this approach that I missed?

[Carsten]

We can not deduct something like SMPTE A or Bv2.0 compliance (I would already avoid the term 'compliance' to begin with) from specifics of a single asset. I was never happy with the options to create SMPTE A and 2.0 compositions. Everyone should stay on Interop, or choose SMPTE Bv2.1.

I understand some people's needs to create SMPTE A or SMPTE Bv2.0 compatible files towards legacy equipment.
But I thinks it's wrong to support these formats beyond this. These were meant to be transitional consent, not specifications.

[cosmonaut786]

SMPTE A is intended for short content (trailers, ads, etc) when you don't need like FFEC/FFMC markers or metadata. It is also used for features that contain stereo audio only as SMPTE 2.1 does not recognise stereo as a valid audio format (only mono, 5.1 or 7.1).
SMPTE 2.0 is deprecated and should not be used.

@carl regarding the guard bit, I am afraid I have no official reference in any of the standards, I guess it's just industry practice?

Thanks