Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IMF CPL Adapter #104

Open
ssteinbach opened this issue May 12, 2017 · 8 comments
Open

IMF CPL Adapter #104

ssteinbach opened this issue May 12, 2017 · 8 comments
Assignees
Labels
help wanted We're looking for help from the community - you're weclome to volunteer! needs discussion
Milestone

Comments

@ssteinbach
Copy link
Collaborator

This issue is a placeholder for something that has come up as a question but is not currently a priority.

@ssteinbach ssteinbach added help wanted We're looking for help from the community - you're weclome to volunteer! needs discussion labels May 12, 2017
@jminor jminor added this to the Public Beta 6 milestone Sep 7, 2017
@jminor jminor self-assigned this Sep 7, 2017
@jminor
Copy link
Collaborator

jminor commented Sep 23, 2017

Reference docs: http://ieeexplore.ieee.org/document/7560854/

@jminor
Copy link
Collaborator

jminor commented Sep 23, 2017

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.

@jminor
Copy link
Collaborator

jminor commented Oct 4, 2017

This might be a handy way to get metadata from the MXFs: https://github.com/markreidvfx/pymxf

@reinecke
Copy link
Collaborator

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?

@meshula
Copy link
Collaborator

meshula commented Oct 28, 2021

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.

@thecargocultnz
Copy link

@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?

@jminor
Copy link
Collaborator

jminor commented Apr 11, 2023

@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?

@jminor jminor added the stale label Jun 9, 2023
@jminor
Copy link
Collaborator

jminor commented Jun 22, 2023

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.

@jminor jminor removed the stale label Jun 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted We're looking for help from the community - you're weclome to volunteer! needs discussion
Projects
None yet
Development

No branches or pull requests

5 participants