CLYCbCr, XYZ and KEY colorimetry

[garethsb]

ST 2110-20 and RFC 9134 (JPEG XS) define colorimetry values for CLYCbCr (constant luminance YCbCr), and XYZ colorspaces, and key.

IS-04 v1.3 raw video Flow components cannot represent these colorspaces, because the enum for components.name doesn't include the necessary entries and there isn't an escape via e.g. a string pattern.

PR #33 added support for components for coded video Flows, e.g. JPEG XS, using the same definition.

Should we add enum entries to the schema in the Parameter Registers even though this wouldn't solve the problem for video/raw Flows?

E.g.

              "Yc",
              "Cbc",
              "Crc",
              "X",
              "Z",
              "Key",

Or should we roll that back and add a color_sampling attribute (with values like the same-named parameter constraint in the Capabilities register) instead?

---

FWIW, there are just a few other "closed enums" in IS-04 and IS-05 that we might prefer were open to extension without having to bump the spec version...

In IS-04

• Clock ref_type has fixed options of internal or ptp (does IPMX want to be able to indicate something else?)
• PTP Clock version is fixed to IEEE1588-2008 (someone might want IEEE1588-2019?)
• Audio channels.symbol has a fixed list of options (and there are channel groupings that they can't represent - see IS-05-02 test_15 cannot handle an fmtp attribute with channel-order=SMPTE2110.(AES3) nmos-testing#543)

In IS-05

• fec_type has fixed options of XOR and Reed-Solomon (sufficient for all time?!)
• more importantly /transporttype has a fixed list of options (and a larger change would be needed to make the schemas for new transport types "pluggable")

[andrewbonney]

Given that the JXS flow register adds to other enums already, I would suggest there is little harm in doing the same for the component name. This perpetuates the intended flexibility of the structure and doesn't result in duplication.

The closed enum issue ought to be dealt with in IS-04/05. This is clearly going to become a bigger issue in the future and given that we now have an extension mechanism in the parameter registers which we didn't have when the enums were originally created I'd hope this would be simple to specify. The question of whether this requires a version bump will have to go to the group as the bump mechanism is clearly there to help systems which might not have accounted for this and don't handle it gracefully, but as we know a version bump has its own downsides.