search

SMPTE / st429-16

SMPTE ST 429-16
Other
2 stars 0 forks source link

Request for new document type: CompositionMetadataProperties #2

Open jhursty opened 3 years ago

jhursty commented 3 years ago

Additional composition metadata can be divided into two categories. Those metadata items in the first category are equivalent to structural metadata elsewhere in the DCP (for example MCA labels.) Items in the second category are provided by the operator and have no correlation with CPL structural metadata (e.g., ReleaseTerritory.) In an automated mastering environment the items in the later category are most easily processed using an interoperable group structure that can be interpreted by automation systems. The existing CompositionMetadataAsset structure is not appropriate for this purpose because it contains required elements in the former category, which may not be known at the time it is created.

The proposal is to create a new standalone XML document, CompositionMetadataProperties, for use by automated mastering systems, which contains only the items of the later (operator provided) category. This new structure is best defined in ST 429-16 so that it can take advantage of the existing definitions of the relevant metadata properties and avoid divergence of meaning with regard to the definition of the CompositionMetadataAsset element. The automation system can then assemble the complete CompositionMetadataAsset element using structural metadata in the DCP and properties expressed in the CompositionMetadataProperties element.

jhursty commented 3 years ago

cpl-metadata-properties.txt This is an XSD file but github made me use .txt

palemieux commented 3 years ago

@jhursty Can you provide an example of a workflow/implementation that is not possible with the current structures?

jhursty commented 3 years ago
  1. An IMF App. 4 DCDM master is created, call it imp-1. ... Some time later, in another context, it becomes necessary to create a DCP version of imp-1, to be called dcp-1...
  2. The process that creates dcp-1 is a cloud-based, headless process. It is presented with instructions that select imp-1 as input and configure the process to produce the correct formulation of dcp-1.
  3. dcp-1 is completed and distributed to the delight of all involved.

The issues are these: A. In step 1 one might know some of these (operator provided) properties but maybe not all. In the rare case that one does have all the necessary detail, there is no interoperable method to store these properties in an App4 IMP.

B. The property values may be changed after imp-1 is authored (step 1) but before the production of dcp-1 (step 2.) There is no interoperable method to collect these properties for transmission to the DCP processor .

C. In most cases the property values will not be known until just before step 2. Again, no interoperable method. etc.

D. One might address Issue A by proposing a stand-alone instance of CompositionMetadataAsset to be included in the IMP, either as a sidecar file or by direct inclusion in the CPL's ExtensionProperties. Issues B and C could be similarly addressed. This stand-alone use of CompositionMetadataAsset is inconvenient for two reasons: a.) It includes elements irrelevant to the job at hand (EditRate, IntrinsicDuration) b.) it requires values (MainSoundSampleRate, MainPictureStoredArea) that are intrinsic to the composition metadata and therefore serve no purpose other than one day being wrong.

Issues D.a and D.b are, in my opinion, a risk to interoperability because their very presence will trigger disagreement about how and when they are to be ignored. In my experience it is difficult to settle interoperability where optional elements are involved, especially those items which may be in conflict with some other aspect of the object model.

palemieux commented 3 years ago

Below is my attempt at summarizing the process of creating a DCP from a DCDM, regardless of whether the DCDM is an IMF composition or a bunch of TIFF and WAV files.

image

You are suggesting standardizing the distribution metadata, as illustrated in the figure?

jhursty commented 3 years ago

Yes.

palemieux commented 3 years ago

Assuming that "create DCP" is a headless process, I would expect the distribution metadata to be delivered through an API. If this is the case, I would consider defining an abstract model for the metadata, with bindings to XML and JSON. The latter is emerging as the standard for API data structures on the web.