ApplicationIdentification for DCDM compositions

[IMFTool]

ApplicationIdentification: Is the intention, for DCDM Compositions, to have both of the values specified in table 15 and table 19 be present? That's maybe worth a NOTE.

[palemieux]

ApplicationIdentification: Is the intention, for DCDM Compositions, to have both of the values specified in table 15 and table 19 be present?

Yes.

That's maybe worth a NOTE.

+1

[hnlocher]

ApplicationIdentification: Is the intention, for DCDM Compositions, to have both of the values specified in table 15 and table 19 be present?

Yes.

My first understanding was that the content of table 15 is for "general characteristics" and the one in table 19 for "DCDM characteristics"

If both appears in the same composition, then :

• Either they are concatenated in the same ApplicationIdentification tag. What should then be the separator ?

• or

As 2067-2 states:

The ExtensionProperties element of the Composition Playlist instance shall include a single instance of the ApplicationIdentification element specified in Table 10.

Then multiple ExtensionProperties occurence shall appear ? Seam not to be allowed by the schema.

[IMFTool]

The single instance of the ApplicationIdentification element, as defined in 2067-2, contains an xs:list of xs:anyURI elements. Any XML white space (e.g. one or more white spaces, CRs etc.) serves as separator between between xs:anyURI elements.

My understanding is that CD 2067-40:20XX does not specify a specific order of the URIs defined for App#4 DCDM CPLs.

I.e. either of the following Extension Property elements would be valid for a DCDM CPL: <ExtensionProperties> <cc:ApplicationIdentification xmlns:cc="http://www.smpte-ra.org/schemas/2067-2/2016">http://www.smpte-ra.org/ns/2067-40-DCDM/2020 http://www.smpte-ra.org/ns/2067-40/2020</cc:ApplicationIdentification> </ExtensionProperties>

<ExtensionProperties> <cc:ApplicationIdentification xmlns:cc="http://www.smpte-ra.org/schemas/2067-2/2016">http://www.smpte-ra.org/ns/2067-40/2020 http://www.smpte-ra.org/ns/2067-40-DCDM/2020</cc:ApplicationIdentification> </ExtensionProperties>

[dtatut]

ST2067-2 is very clear on how the ApplicationIdentification can handle mutiple URIs.

However what is not always clear is what do multiple URIs represent. For instance, for a CPL that complies with App 2 and App 2E, some CPLs use both App 2 & 2E URIs to signal compatibility with the 2 apps.

Here the rule seems different as the presence of both URIs indicate a specific variant of App 4. It's not exactly the same use as I described above.

Since ST2067 in general does not specify the roles of multiple URIs, it would be good to discuss if this is left to the Application Specification or if there must be a general rule that applications must adopt.

[fschleich]

Folks interested in App4 DCDM asked for a way to identify DCDM App4 packages as such early on (also minuted here). While one could check for Transfer Function ULs in the CPL descriptors, I think it's appropriate to use both Application Identification values (as outlined by Wolfgang) to allow for easy identification of specialized DCDM App4 packages. A note should be added to explain that. Does that work for you @hnlocher and @dtatut ?

Since ST2067 in general does not specify the roles of multiple URIs, it would be good to discuss if this is left to the Application Specification or if there must be a general rule that applications must adopt.

@dtatut - do you have a preference/suggestion?

[hnlocher]

I think we have that this issue is similar to the "hanging paragraph" problem.

If http://www.smpte-ra.org/schemas/2067-40/2020 is designating the whole application (common constraints, historical 2016 profile and DCDM profile)

if http://www.smpte-ra.org/schemas/2067-40/2020 + http://www.smpte-ra.org/schemas/2067-40-DCDM/2020 Is designating the DCM profile (DCDM size characteristics + COLOR.APP4.2 )

What is designating the Historical 2016 profile (General characteristics + COLOR.APP4.1) ?

[dtatut]

@fschleich : My preference is that ApplicationIdentification URIs designate the application(s) that the CPL is supposed to be compliant with. A single URI solution or a multiple URI solution does not change much. In this particular case, probably the http://www.smpte-ra.org/schemas/2067-40-DCDM/2020 would have been sufficient anyways.

[palemieux]

What is designating the Historical 2016 profile (General characteristics + COLOR.APP4.1) ?

There is no such designator today.

Is there a need for such a designator from the community? If so, a separate ticket should be opened to add such a designator.

In this particular case, probably the http://www.smpte-ra.org/schemas/2067-40-DCDM/2020 would have been sufficient anyways.

@dtatut Can you clarify your request? Are you suggesting three distinct designators (App4-not-DCDM, App4-DCDM, App4) or two designators (App4-not-DCDM, App4-DCDM), or something else?

[dtatut]

@palemieux : I don't understand your question. Where did I request three distinct designators? What I stated above is that having 2 URIs to identify the DCDM variant is perfectly acceptable, even though I do not see the added value. Simply using the single URI http://www.smpte-ra.org/schemas/2067-40-DCDM/2020 would have achieved the same desired result in the particular case of App 4 here. Did I miss any important reason that makes my comment irrelevant?

It does not matter much what solution is used in the end as long as the application specification is clear about the usage of the single/multiple URIs

[palemieux]

Simply using the single URI http://www.smpte-ra.org/schemas/2067-40-DCDM/2020 would have achieved the same desired result in the particular case of App 4 here.

Yes, it would achieve the same result, but would require the text in Section 7.1 to specify that the designator http://www.smpte-ra.org/schemas/2067-40/2020 shall not be used if the designator http://www.smpte-ra.org/schemas/2067-40-DCDM/2020 is present. I would think that this makes the logic more complicated.

In any case, implementations need to be able to accept multiple values in ApplicationIdentification since proprietary and/or future designators may be present.

Can you list scenarios where requiring multiple designators or accepting multiple designators would result in interop issues? Apologies if you have already done so earlier and I missed it.

[dtatut]

@palemieux : yes, absolutely, implementations MUST support multiple URIs and application users could really benefit from using this feature.

For the moment we have not encountered interop issues. ST2067-2 is clear enough on how these things should work. However multiple designators are not really used in the market place today. Maybe the IMFUG should do some educational work on the topic.

TSP2121-4 is a perfect example where 2 designators could have made sense.... maybe in a future revision?

[hnlocher]

Yes, it would achieve the same result, but would require the text in Section 7.1 to specify that the designator http://www.smpte-ra.org/schemas/2067-40/2020 shall not be used if the designator http://www.smpte-ra.org/schemas/2067-40-DCDM/2020 is present. I would think that this makes the logic more complicated.

A alternate wording solution would be to suppress section 8 and to propose in 7.1 to use http://www.smpte-ra.org/ns/2067-40/2020 for general characteristics and http://www.smpte-ra.org/ns/2067-40-DCDM/2020 for DCDM characteristics.

[palemieux]

20200629 DG telecon

If the two labels are mutually exclusive as suggested at https://github.com/SMPTE/st2067-40-2ED/issues/1#issuecomment-637002923, then the (classic) designator http://www.smpte-ra.org/schemas/2067-40/2020 would need to be more specific. The document structure may also need to change to make the two subsets symmetric.

[hnlocher]

A new structure with suppression of section 8, and changing section 7.1 to offer one identifier or the other.

• 35PM-CD-ST-2067-40-revision2018-2020-07-22(redlineFrom2020-07-07)

[hnlocher]

20200727 DG

Use "linear characteristics" instead of "general characteristics" as suggested by Wolfgang Ruppel.

[hnlocher]

• Change "general characteristics" with "linear characteristics"

35PM-CD-ST-2067-40-revision2018-2020-07-28-11h53(redlineFrom2020-07-22)

[hnlocher]

Changes reflected into pull request #21