search

Ymagis / ClairMeta

Clairmeta is a python package for Digital Cinema Package (DCP) probing and checking.
BSD 3-Clause "New" or "Revised" License
84 stars 22 forks source link

Make check of pixel array size more strict to conform to RDD 52. #181

Closed matmat closed 3 years ago

matmat commented 3 years ago

Check for valid stored picture size according to RDD 52.

Maybe we should aim to adjust the use of "Resolution" throughout the project to be more specific about stored pixel array size vs. active pixel array size?

remia commented 3 years ago

Hey @matmat,

This looks fine.

I wonder if this check shouldn't actually live in it's own method so that we don't throw an error / warning for case where it's not relevant, ie. IOP or older SMPTE DCP ? Still unclear about what the best way to treat these RDD 52 checks but it feels like having the capability of easily enable / disable them from the check profile could be a nice feature:

'check_*_smpte_app_b21_*': 'SILENT or WARNING or ERROR'

I think we need some kind of builtin / first class logic to handle all these different type of DCPs (IOP, SMPTE, SMPTEB21, ...), I don't really like the current spread of conditionals in checks method depending on these standards. What's your take on this ?

Maybe we should aim to adjust the use of "Resolution" throughout the project to be more specific about stored pixel array size vs. active pixel array size?

Totally agree on that!

jamiegau commented 3 years ago

I think we need some kind of builtin / first class logic to handle all these different type of DCPs (IOP, SMPTE, SMPTEB21, ...) Exactly what I was thinking the other day.

I have been working on a free tool for small cinemas that is a small LMS type system that sucks in/Ingests DCPs in an automated process. As part of the process of ingesting, it generates a clairmeta report as so they know the Ingested assets are GOOD. So for example, with all the different internet DCP digital delivery services, the system automatically pulls in those DCPs as they arrive and ads them to a central LMS, AND checks to see they are OK. All to often a DCP arrives and a day before it is suppose to play. "Oh no it's corrupts" This automated system should fire issues as soon as possible giving them time to react to a fault.

Plus the delivery solutions from many of the service providers sucks in many ways. (From my perspective as a cinema owner)

I plan to roll it out to 5 test sites and see how they play with DCPs going through. My concern is false positives or SMPTE fails that are don;t really mean they will not play. And how to deal with those issues. Cinema owners may get all upset for no reason... "But the DCP fails verification". But then again it would weed out the companies who make poor DCPs in the long run.

It may be take it as it comes and feel the way through in terms of critcality of checks in the field. (As has been mentioned, this tool was more for producers and as such more critical.)

matmat commented 3 years ago

Thanks @remia!

I wonder if this check shouldn't actually live in it's own method so that we don't throw an error / warning for case where it's not relevant, ie. IOP or older SMPTE DCP ? Still unclear about what the best way to treat these RDD 52 checks but it feels like having the capability of easily enable / disable them from the check profile could be a nice feature:

'check_*_smpte_app_b21_*': 'SILENT or WARNING or ERROR'

I think we need some kind of builtin / first class logic to handle all these different type of DCPs (IOP, SMPTE, SMPTEB21, ...), I don't really like the current spread of conditionals in checks method depending on these standards. What's your take on this ?

I haven't thought this through enough yet, but:

My view is that the different kinds of DCPs are not so distinct in their specs and features as it first appears. Rather SMPTE is more of a "clarification" of Interop, and RDD 52 is a further "clarification" of the previous specs. There are some specific exceptions from this of course, but on the whole I think you can look at it more as an evolution of the same format rather than independantly different specs.

I think it is often beneficial to run SMPTE and RDD52 checks even on Interop as they act as a kind of sanity check for things that should have been specified in the first place even for an earlier spec. The current architecture in clairmeta makes that easy, you get good sanity checks for Interop "for free".

Maybe another option is to differentiate warnings/errors for the same checks depending on SMPTE/Interop/..?