Open ssteinbach opened 7 years ago
Reference docs: http://ieeexplore.ieee.org/document/7560854/
FYI, we made some progress on a 1st draft of IMF CPL writing today. The adapter needs the clips to be pre-decorated with a bunch of MXF metadata, so this will require some help from a media linker and/or a script to scan the MXFs for the required info.
This might be a handy way to get metadata from the MXFs: https://github.com/markreidvfx/pymxf
Is this something we feel like should be shipped with OTIO and supported by the core team, or would it make sense to make it an optional adapter plugin in the OTIO github project as federated repo?
My position is that new adaptors should be federated projects, and that it's important to decouple iteration gates on the core library from projects, such as adapters, that rely on the core library with no reciprocal dependency. Adapters in the main project mean that the adapter and library mutually gate each other. We don't have the resources to validate adapters across a full conformance matrix, adapters naturally belong in the community driven domain.
@jminor how did you go with this in the end? I don't see an IMF adaptor in the contrib collection but is it something that people are still interested in?
@thecargocultnz I did a tiny, incomplete proof of concept that attempts to make a CPL from an OTIO, but nothing more. I know some other folks with more IMF expertise have incorporated OTIO into their process, but not in the form of an adapter, so it isn't really portable. I don't know much about the IMF toolset, but it seems Java focused?
From TSC discussion:
Making a CPL adapter that is read-only (CPL to OTIO) could be helpful, but the other way around would be awkward since there are so many constraints on IMF/CPL.
We're heard that the IMF user group might be looking at OTIO interop for carrying metadata.
This issue is a placeholder for something that has come up as a question but is not currently a priority.