INFO: usdotio added to the OpenUSD repository.

[ggarra13]

Required:

---

[x ] I believe this isn't a duplicate topic
[x ] This report is not related to an adapter

Select One:

[ ] Build problem
[ ] Incorrect Functionality or bug
[ x] New feature or functionality

Description

I have added a new PR to the OpenUSD repository with a python utility called usdotio that allows adding and extracting OpenTimelineIO .otio data to/from a .usd file. You can have multiple .otio files added, so that, for example, a TV set model carries its own .otio file, while the main root carries another. The .otio data is added in a tree fashion in the .usd file, for easy inspection and modification with usdview or similar.

Optional

---

Environment

Operating System: Linux, Windows and macOS
Python version if appropriate: 3.10

Reproduction Steps

usdotio add input.otio sphere.usda # sphere.usda is modified in place and input.otio is added to it at the root
usdotio save output.otio sphere_with_otio.usda # output.otio is created from the sphere_with_otio.usda file

Log output if appropriate

Sample data and other attachements

[meshula]

Hi Gonzalo! This is a very cool project. I wonder if it might make sense for it to be an OTIO project under the https://github.com/opentimelineio organizational umbrella? The reason I think that might be a good idea is that it seems logical that the OpenTimelineIO community would be most active, and responsible for, deciding how mappings between USD & OTIO make the most sense. If it's committed at the USD side of things, then updates and releases would occur at the USD cadence. I think it would make sense to update the project when it has new features or when new OTIO releases occur, rather than at the pace of USD releases.

It would also keep innovation in the space focussed with the OTIO community. I have a feeling your project is going to spark a lot of creative applications, and that might prompt evolution and iteration of the plugin.

What do you think?

[ggarra13]

I disagree. I think the project belongs to the USD repository, because of several things:

1. Political. USD is not a standard that yet all companies want to support (I think it is currently just supported by Pixar, Animal Logic, Nvidia and a portion of the Khronos group and most DCC applications with bugs in it), unlike OTIO, which is now a established one among editing applications and part of the ASWF.
2. Easier to test and debug. Thanks to Pixar's usdview in OpenUSD it makes it very easy do debug, see and iterate changes, while if it is in OTIO it would make it difficult. The unit test system in OpenUSD is more robust than the one in OTIO.
3. I coded usdotio with forwards compatibility in mind. If some OTIO schema changes, new attributes are stored in and retrieved from an "unknown" metadata attribute in USD, making it remain compatible even if you don't have the new parameters show in the USD gui, without having to wait for OpenUSD's schemas to be upgraded.
4. As you work for Pixar, I'll be blunt. Pixar+Apple scare the heck of a monopoly out of me. Nvidia also scares me, but less. I prefer to keep working on Linux and Windows.

[meshula]

Everyone agrees with you that stakeholders should be involved in the future of USD, that's why AOUSD has been formed.

I see your points two and three, about usdview being a good basis for a debugging tool, and the advantages of that testing environment, and iterating with the USD infrastructure. I didn't and don't mean to suggest that you change the project in any way. I simply mean that it could make sense to host it as it is, in an Academy Software Foundation project, because ASWF is vendor neutral, community focussed, and a good place to bridge projects.

[md84419]

The project was presented to the OTIO TSG today.
The slide pack is available here: https://academysoftwarefdn.slack.com/files/UMR15BVME/F06PM8WAMSP/opentimelineio___openusd.pdf