I think that there is a duplication of children elements among
fileInfo (and, again,
<aces:clipId> …), which may be merged into one clip-referencing element that uses either either filename and metadata as reference anchor(s). Currenlty, filenames can be specified in either
<file> child and
<clipName> and in the independent
<fileInfo> elements, which is ambiguous. I think only the former of the two (
file) should stay.
Most importantly, a table is needed to match the value of
clipId element with one specified metadata per every major file format (OpenEXR, REDCODE, ARRIRAW, MXF, DPX, MP4, QuickTime, etc.). During recent talk with Chris I told I could produce one, which I still need to find out spare time to realize. Hope that, when it’s ready, file-format maintainers (especially those for camera-native formats) will come out and speak up to complete/fine-tune this list.
This one-to-one corresponding list is however, not enough for generic (and usually more complex) production cases, where you might want to stick an AMF to a different metadata. For example, what if your production workflows uses a clip’s starting ToD TimeCode to attach AMFs? Let’s think to a live recording scenario (e.g. sports event).
Therefore I proposed several time that a fourth element, called
<metadata> is introduced, whose attribute is the file-format maintainer’s original header metadata name. Multiple istances of it may be present – not just 0-1 occurrences.
For example, a severly over-specified example for R3D would be:
Understandably in real-world scenarios, just any one of the above six different lines is likely sufficient to uniquely bind the AMF to a particular clip. Using more than one at the same time, however, has the advantage that when the R3D file is transcoded – during the many stages of near-set, VFX prep, editorial, online, color-grading, compositing, mastering, versioning – there’s a higher chance at least one clipId reference sticks from one conversion to the next. Therefore, there’s a higher chance that the binding between the ACES pipeline (in the AMF) and footage is not broken.
Can you see?
- some format conversions may preserve filename;
- some other format conversions may preserve just eihter one of the TimeCodes;
- some other format conversions may preserve the UUID:
Ultimately, in an effort to preserve enough production metadata deep throughout the pipeline (from camera-natives down to finished, archived masters), the more metadata are used, the better it is.