If, howerver, there is a <clipID> element into the AMF, then the AMF is soft-linking one (or more) color pipeline(s) with a specific file (or file sequence, or file package).
In such a case, <clipID> is a bond with a filesystem object, therefore the soft-link shall depend on that file-format’s metadata.
Should the footage change either metadata, content and file-format, the <clipID> element in the AMF shall follow, by changing altogether, otherwise the binding is broken.
Therefore, when figuring out what goes into <clipID>, it’s important to have a list of possible options that depend on the file format. It’s logical and, in case an AMF-compatible application can’t playback or render a particular file format, then there’s no point in the application parsing how the AMF binds to that file-format via its specific metadata.
.
I hope this clarifies my position a bit better.
As I said a few times, in order to make AMF (ex ACESclip) really usable and actually used by products, it’s necessary that every file-format maintainers come up with candidate metadata to be used in <clipID> for their own format(s).
I call upon exr, ISO (mp4, png, jpg2k), SMPTE (mxf, IMF, dpx), Arri (ARRIRAW), RED (Redcode), Adobe (tiff, dng), Apple (QuickTIme), etc.
Now some proposal on how <clipID> can be practically populated, depending on the file format:
-
<file> for storing the filename of any single-file footage (MXF, QuickTime, MP4, etc.)
-
<seq> for storing the filename of a sequence of files. The # character is used, by default, for any single digits in the frame numbering, but can be optionally overridden with an optional idx argument. Optional min and max arguments may be used to bind an AMF to a particular “sub” frame range (that is useful if we have cuts within the same frame sequence, and multiple AMF per each cut); alternatively
-
<Id> for storing a DCP or IMF “clip” unique to a file package by referencing the package UUID…
Then, in addition to the above filesystem-specific elements, the following optional ones can be used:
-
<TimeCode> containing the clip’s starting TimeCode. If more than one TimeCode is supported a sring with the TC type is added in the optional type argument. Available TimeCode type names are filesystem-specific,
-
<clipName> containing the clip’s main tapename/clipname/reelname, as specified by file-format maintainer. If more of them are present within the same file format, then the rest can be specified in a sub-element
-
<modificationDateTime> the footage’s update time as reported in the filesystem. Applications should be lax anought to expected weigting in timezone differences, plus time drifts due to some filesystem’s time granularity.
- a generic
<metadata> element, with a mandatory attribute containing the name of one particular metadata specific to the given file format. If the fileformat’s metadata are explicitly named (e.g. in OpenEXR container), then there is no ambiguity at all.
Some example <clipID> practical usecases:
<seq>movie_r3_hdgrd.master.#######.exr</seq>
<metadata key="user.productionName">Movie Title</metadata>
<metadata key="user.reelNumber">3</metadata>
In this case a whole sequence of EXRs is referenced by filename ony. Two named metadata are used to link further.
<Id>urn:uuid:f7b77066-2762-4483-a253-739524337266</Id>
<metadata key="Annotation">MovieTitle_FTR-DVis_EN-XX_4K_20190309_VF</metadata>
<metadata key="ContentTitle">MovieTitle_FTR-DVis_EN-XX_4K_20190309_VF</metadata>
<metadata key="Creator">Clipster 6.0.0.7 (build 106320)</metadata>
In this case the binding of the whole AMF is with an IMF package’s own CPL, furthere referenced by the name of the IMP and, optionally, by the creator application’s name.
<seq idx="#" min="1" max="3">A001_C012_AE0306_###.R3D</seq>
<clipName>A001C012</clipName>
<modificationDateTime>2014-06-20T12:24:03+02:30</modificationDateTime>
Here is a REDCODE example where the whole clip is recovered by means of a standard REDCODE metadata field, that the manufacturer should have pre-emptively declared as the standard/default for an AMF’s path filename indications.
