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

AAF adapter should support writing compositions #236

Open
jminor opened this Issue Feb 22, 2018 · 14 comments

Comments

3 participants
@jminor
Collaborator

jminor commented Feb 22, 2018

We have read support (see #1) but we would like to be able to write AAF compositions as well.

@jminor jminor added this to the 1.0 Release milestone Feb 22, 2018

@jminor jminor added this to To do in AAF Adapter Feb 22, 2018

@hasielhassan

This comment has been minimized.

hasielhassan commented Apr 9, 2018

Hi

I have been working on a custom AAF reading/writing pipeline with Media Composer in a studio, I will love to use OTIO instead, are you working in the writing module already?

If not, I will love to help with it, the only thing is that my code is using pyaa2 instead of the regular one, which is good because it doesn't require any dependency.

I will still need to adapt my code to follow the OTIO workflow but I think that it will worth it at the end :)

Let me know, and thanks so much for this amazing project!

@jminor

This comment has been minimized.

Collaborator

jminor commented Apr 9, 2018

Hi @hasielhassan,
We haven't started on the AAF writing features for OTIO's AAF adapter yet (our legacy pipeline does this in C++) since the reading part is just starting to be used in production & we want to make sure that is solid before tackling the writing part.
We are in discussion right now about whether to switch to using pyaaf2 or not. Our initial experimentation is promising. Can you elaborate on your experience with pyaaf2 and what has/hasn't been working well? Are you using it to make AAF compositions, or embedded media, or both?

@hasielhassan

This comment has been minimized.

hasielhassan commented Apr 10, 2018

In general y found pyaaf2 easiest to use since it already encapsulates a lot of the nested structures into single methods, and even that the documentation is not fully complete, is really useful to just open and read the source, which is not totally possible with pyaaf (and im still far from totally understand c++ from the aaf sdk)

The workflow here is to build updated sequences on the fly based on editorial data and Versions from Shotgun and just open them on MC to do adjustments, Im still strugling with external (ama) linking which i can't get to properly connect to the external files, which I see as ideal workflow (then after a review the editor can import the required media), so right now im mainly using embeded media, but i recently started managing mob ids on my own so i build aaf files with embeded media as libraries without compositions and then separated compositions with "links" pointing to the same mob ids, doing this we dont duplicate the information unnecesary (which was my first problem.

So at least for simple sequences of just trimed clips is working fine, for both video and audio.

My next step is to use transitions and speed changes.

Im still learning the format and I see why you are woking on otio, there is a lot of different ways to structure the files, aaf files that i creared work on avid but not on resolve for example and im still not sure which are the main differences, seems that MC is more flexible but im not sure if pyaaf2 have someghing to do.

@jminor

This comment has been minimized.

Collaborator

jminor commented Apr 10, 2018

That sounds like an ambitious project - and very similar to the pipeline we are building with OTIO. In our legacy pipeline we make individual media AAFs for each clip and a separate AAF composition which references the MobIDs from those clips. This lets us deliver a handful of new clips and a composition that refers to a mix of the new clips and older ones we have delivered previously. It also lets us ensure that the media AAFs have all of the production metadata that we care about, such that an exported AAF composition later will have that metadata on it as well.

Our plan is to replicate that same workflow using OTIO. We've started with reading the AAF composition exported from Media Composer via the AAF adapter in OTIO and then working backwards upstream from there.

Our next internal milestone will include adding more features to the reading side of the AAF adapter, but it isn't clear yet when we'll start on the writing part. If you are able/willing to build your AAF compositions via an OTIO adapter, then we could certainly offer guidance, advice, testing, etc. The advantage of doing it as an adapter is that you can then use/compare to other output formats (e.g. FCPXML, EDL). For example, Resolve and Premiere can read FCPXML.

@jminor

This comment has been minimized.

Collaborator

jminor commented Nov 5, 2018

@MartinDelille

This comment has been minimized.

MartinDelille commented Nov 6, 2018

our legacy pipeline does this in C++

@jminor I'm interested into writing AAF in C++. Can you point me where to start?

@jminor

This comment has been minimized.

Collaborator

jminor commented Nov 6, 2018

Hi @MartinDelille, we have a developer starting work on the C++ API for OTIO this week, and another scheduled to start on AAF writing in the next couple of months. Can you explain the use case you have in mind?

@MartinDelille

This comment has been minimized.

MartinDelille commented Nov 6, 2018

I develop a recording software and I would like export session to Pro Tools. AAF seems to be handling pretty much what I need.

I would be very pleased to contribute to the OTIO!

@MartinDelille

This comment has been minimized.

MartinDelille commented Nov 6, 2018

I want to create a multitrack session with multiple track at different position. I want also to be able to add some fade in/out automation on the audio clip.

@jminor

This comment has been minimized.

Collaborator

jminor commented Nov 6, 2018

Okay, that sounds similar to what we're aiming for - our use case is for video, but otherwise it is the same. We have heard from other people that Pro Tools AAFs are a bit different from Media Composer AAFs, so maybe it would be good to make sure we have sample AAFs and unit tests for both so we can make sure we uncover any gotchas early.

If you're available to help, then take a look at the guide to contributing: https://opentimelineio.readthedocs.io/en/latest/tutorials/contributing.html
and if you are able to produce some sample AAFs from Pro Tools, that would help to get things going.
We will likely want to track the progress on putting media into AAFs, and for anything specific to Pro Tools separately from this issue, but the work will overlap.

@MartinDelille

This comment has been minimized.

MartinDelille commented Nov 7, 2018

I will just check with my boss that the CLA is ok.

Regarding the licence, why don't you use GPL/LGPL that is more protective for the contributors and the users?

I have Pro Tools install on my computer so I can definitely provide any sample you need. I already did some retro engineering on some proprietary format so I can also be some help there.

I had a quick look at the cpp_api folder and saw that you are using pybind11. Why don't you link it as a git submodule?

@MartinDelille

This comment has been minimized.

MartinDelille commented Nov 7, 2018

Also I build successfully the content of https://github.com/ssteinbach/OpenTimelineIO/tree/cpp_api/cpp_api but failed to link it to my simple test program written in Qt.

I have the following error:

ld: library not found for -lopentime.cpython-37m-darwin
@jminor

This comment has been minimized.

Collaborator

jminor commented Nov 7, 2018

Our company chose the license that they felt is most widely accepted within our industry.

The work on a full C++ API is just starting. When that is ready, we will make it easy to build (submodule, CMake, or whatever) and include a sample program.

@MartinDelille

This comment has been minimized.

MartinDelille commented Nov 12, 2018

Our company chose the license that they felt is most widely accepted within our industry.

No problem I totally respect that. I'm just checking with my legal departement that it is ok for me to sign the CLA.

The work on a full C++ API is just starting. When that is ready, we will make it easy to build (submodule, CMake, or whatever) and include a sample program.

Ok these are just some remark I made but it's totally fine if you fix it later on.

Do you have an estimated roadmap on this project?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment