Each LEAF entry in the Groups Register must have a
KLVSyntax field that contains at least one value. Note: this statement is not dependent on the value of
KLVSyntax and Parent Groups
KLVSyntax values are not inherited from a parent Group.
If a Group has
IsConcrete set to
KLVSyntax is interpreted as signalling the intent / expectation that any sub-classes / Groups that inherit from it will use
KLVSyntax values within the specified list of values.
It is advisable (but not mandatory) that each Group specifies only
KLVSyntax values that are in the list of
KLVSyntax values specified by its parent Group (if it has a parent Group). Additional notes on this topic:
- If choosing (for a new Group) a value of
KLVSyntaxoutside the list specified by the parent Group the author of the new Group (sub-class) should carefully check that this is a sensible choice and will definitely work without problems.
- For example, the parent Group might have been designed as a Local Set but a sub-class is later defined which is to be encoded as a Pack. The order of Elements within the Group then suddenly becomes important and might need to be given some careful consideration: the parent Group was originally designed as a Local Set and so maybe no consideration was given at all to the order of Elements (because this is irrelevant in Local Set encoding).
KLVSyntax XML data type
KLVSyntax uses the
xs:hexBinary XML type – refer to Use of hexBinary for more details.
Use of the value
SMPTE ST 336 does not permit Byte 6 of a Group UL to have a value of
0x06 for KLV coding – this would suggest that it should not appear as a value for
KLVSyntax. However, this is the value of Byte 6 used for Groups / Classes in AAF (which does use SMPTE ULs but does not use KLV coding) and therefore this value does appear in the Groups Register for such Groups.
Current practice is for the value of
0x06 to be included in
KLVSyntax if, and only if, the Group is being designed explicitly for use in AAF (note that other practices have sometimes been followed). Not all permitted MXF Groups can necessarily be mapped directly to AAF (for example, some of the Types used by their member Elements might not map directly) and so it is not necessarily safe to assume that a value of
0x06 can be included in the
KLVSyntax property of a Group that is being designed for MXF.