Sorry that my connection suddenly became bumpy, far from mainland.
As regards multiple-pipeline AMF, I strongly encourage the enforcing of multiple pipelines within the same file (possibly distinguishing one with a “
default” tag), vs multiple AMF files (one per pipeline) because of the very nature of XML.
In fact, if the pipeline purpose is indicated in the AMF filname only and is rather not self-described in the XML itself filenames may be misinterpreted (as is already happening with LUT naming conventions), as we all know that naming conventions change from facility to facility, show to shop, application to application.
By referencing the pipeline within AMF it would be enought to have simple tagging element with the pipeline name; for example, an attribute in the AMF’s main element:
Besides, since AMF is XML-based, it may likely be used, in the future, to extend the XML capabilities of other, larger files (for example the SCM component of an IMF package, some FCPXML flavours, and so on).
Seemingly, AMF may be extended itself by embedding it with other XML namespaces.
So what happens if multiple pipelines are joined from individual AMF files into a larger XML file from some delivery or postproduction or archival workflows?
Who decides what pipeline is each AMF coming from, after filenames are lost in such a process?
Multiple AMF files should be elected (thus based on “filesystem-only” charactersitics, like filename, or “same-folder-as-the-footage”) only in the “on-set” case, where the AMF has been existing before any footage is rendered.