Example RV OTIO reading application plugin

[avrata]

Re-creating #395 as an example RV plugin for loading an OTIO file into the current RV context.

[codecov-io]

Codecov Report

Merging #565 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master    #565      +/-   ##
=========================================
- Coverage   81.61%   81.6%   -0.01%     
=========================================
  Files          72      72              
  Lines        2730    2729       -1     
=========================================
- Hits         2228    2227       -1     
  Misses        502     502

Flag	Coverage Δ
#py27	81.58% <ø> (ø)	⬆️
#py36	81.58% <ø> (ø)	⬆️
#py37	81.58% <ø> (ø)	⬆️

Impacted Files	Coverage Δ
...ntimelineio/opentimelineio-bindings/otio_utils.cpp	87.2% <0%> (-0.3%)	⬇️
src/opentimelineio/deserialization.cpp	53.19% <0%> (ø)	⬆️
src/opentimelineio/stackAlgorithm.cpp	82.97% <0%> (+0.37%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1ac88cb...2785a65. Read the comment docs.

[eric-desruisseaux-adsk]

Hi, my name is Eric Desruisseaux, I am a SW developer at Autodesk. I am very happy to see this PR, good job! I think the approach makes great sense. I have a few questions.

1. Did you think of how this could scale to support custom SchemaDef? One way to do this could be to expose the WRITE_TYPE_MAP map and let the user append its own "Schema --> function" entry. Assuming that the $OTIO_PLUGIN_MANIFEST_PATH path is properly set, this would require very minimal work per custom schema and would allow customization.

2. Did you try loading timelines with nested compositions? The create_rv_node_from_otio function seems to support arbitrary structures, but I am wondering if you've successfully done it.

3. Did you think of how you'd write the reverse logic? RV to OTIO? Since the RV graph topology is arbitrary and OTIO supports nested tracks, an RV-to-OTIO package could support almost all RV graph cases but I guess we could start with a fixed number of topologies, ie.: Stack of Sequences of Sources, Stack of Sources, Sequence of Sources. Any thoughts?

4. Metadata is supported in _create_item (for Clips and Gaps), but I think OTIO supports metadata on all objects. It would be nice if the plug-in supported it too.

5. Are there any known limitations which should be discussed (and ideally documented in the plug-in or elsewhere)?

Again, great work, this is very nice!

Eric

[eric-desruisseaux-adsk]

Another question :

6. The package calls otio.adapters.read_from_file. If I understand properly, this can be implemented by any registered adapter in opentimelineio. Does it mean that any format supported by adapters could be loaded through the package (ie.: native OTIO, but also FCP, AAF, etc.)?

[ssteinbach]

Another question :

1. The package calls otio.adapters.read_from_file. If I understand properly, this can be implemented by any registered adapter in opentimelineio. Does it mean that any format supported by adapters could be loaded through the package (ie.: native OTIO, but also FCP, AAF, etc.)?

Yes, otio.adapters.read_from_file will dispatch to the adapter plugins based on file suffix.

[avrata]

Yes, otio.adapters.read_from_file will dispatch to the adapter plugins based on file suffix.

Exactly, there is this code:

if ext in otio.adapters.suffixes_with_defined_adapters(read=True):

That'll have the plugin only "wake up" when it sees extensions that OTIO supports. There is an interesting question though of who would "win" in the case where there is any overlap with other supported extensions from other plugins or the built in file reading logic since this is not using the standard way file format plugins work.

[jminor]

@eric-desruisseaux-adsk here are responses to your numbered questions:

1. I agree that would be great if there was a clean way to override or extend the WRITE_TYPE_MAP entries. Internally we are using a fork of this code which uses a special Pixar-specific node for dissolves. If there was a mechanism to override/extend then we wouldn't need a fork.

2. We did some testing with multi-track and nesting, but not an exhaustive test. Most of our production use cases are single track. I think @ssteinbach's RV adapter might have more testing around that, but I'm not sure.

3. I believe that @JoshBurnell and @swallitsch built the inverse (RV to OTIO plugin). OTIO is missing the notion of a Layout, but perhaps this is just a Stack with metadata about placement?

4. Ideally RV (and any other app) would carry OTIO metadata around blindly and round-trip it back out again. This would allow production metadata to flow through RV seamlessly.

5. Yes, there are some known limitations. In particular, image sequences are not formally handled, but can work if you use RV syntax in a MediaReference's target_url. We should discuss better handling for that.

[eric-desruisseaux-adsk]

Thanks @jminor for your answers!

3. We've implemented support for layouts by adding custom metadata at the media-reference level. We injected some resolution-independent coordinates and sizes that we call bounds. Bounds are basically 4 doubles : centerX, centerY, sizeX, sizeY. Those are in an arbitrary units so pixel density has no impact on the way the source is displayed. This is similar to the concept of Data Window in OpenEXR. It differs from a 2D Transform (effect) in that it is seen as source-metadata, but ultimately it is still implemented by a RVTransform2D node in the source group.

At some point (unrelated to this RV package) it would be nice to have a discussion on what would be the best way to make this data OTIO standard.

[eidmi]

Which relates to the discussion we had previously in representing position and size in a universal coordinate system.

[jminor]

Yes, we'd like to hear more details about your universal coordinate system. Are you available to discuss at our next OTIO Technical Steering Committee meeting (video conf) Sept 26th?

Separate from that, do you see any of items 1-6 as blockers to accepting this PR, or smaller changes that should be addressed? You should be able to check out @avrata's branch to try it yourself.

[eric-desruisseaux-adsk]

I already checked it out and played with it in RV, I tried it with our OTIO and it worked well, except of course for all the missing private schemas. The only thing that I think should be added (now or in a follow-up) is the support of the metadata on all nodes (as expected based on the OTIO spec).

The rest was more some curiosity/question I had.

Thanks!

Eric

[jminor]

Great. @avrata is going to look at the metadata support.

[avrata]

I took a quick pass at adding metadata to each rv node if the associated otio item has any here: f7af52c If this looks interesting I can look into trying to update the external rv adapter with this same pattern as well. I did change the property location of the RV metadata with this a little to something that made more sense to me (.otio.metadata), but that's easy to revert if people are attached to the old one.

[ssteinbach]

Looks great, thanks @avrata. I had two really small questions.

[eric-desruisseaux-adsk]

Thanks @avrata!