New In Beta: OTIO Import and Export

[eric escobar]

Premiere Pro Beta has support for Open Timeline IO interchage format (OTIO). Our current implementation includes the basic information for interchange with other products that support the OTIO standard:

• names
• cutlist with clips at correct place in sequence
• source in/out
• durations
• starting timecode and timecode formats
• fps
• multiple tracks
• track names
• linear speed
• sequence markers (start time, duration, name, color)

Premiere Pro's OTIO support includes Premiere round-tripping information as well:

• clip markers (start time, duration, comments, name, color).
• Seqence frame size
• Sequence sample rate

When importing OTIO files created outside of Premiere Pro, some sequence settings may not transfer automatically and will require manual adjustment.

To export a sequence to OTIO, go to File menu/Export/OpenTimelineIO.

To import an OTIO sequence, go to File menu/Import or use the Media Browser.

Please give OTIO Import and Export a try and let us know what kind of workflows you want to use this for. Let us know what we are missing.

[ScottSimmons]

@eric escobar  how does .otio handle file paths for media? Does that travel with the timeline in an otio export?

[Bruce Bullis · Accepted solution]

Yes!

"target_url": "file:///Users/username/Movies/examplemedia.mxf"

[ScottSimmons]

Same system, same media locations, OTIO from PPro to Resolve was unable to find most media on a half-hour show, mostly ProRes sources with some music, sound fx and graphics. A Resolve deep search was able to find a lot of the ProRes but nothing else. The XML was able to conform and find most all of the media. 

[ScottSimmons]

And just wanted to note some otio testing today on a big show but relatively simple overall resulted in much better results with an XML than OTIO. 

[eric escobar]

Hello Scott!
XML is currently a far more robust interchange format than OTIO, so it makes sense that you're getting better results there. The consortium that is setting the OTIO standards is still very much in the early stages of building a more robust and performant standard. These are the early days of OTIO, please keep telling us what you want to see. I will convey the message!
Best, 

Eric

[ScottSimmons]

Oh that's interesting. I know some of the OTIO discussions go back years and years so I thought it was much more robust at this point than FCP XML (which itself is pretty dang old). Not that it really went anywhere over the last near decade. Eric, are you saying that now that it's got some agreement of use between the big NLE makers, it's finally going to be developed to be usable?  

I think it's obvious what we would want it to carry across, which is any timeline data not proprietary to the NLE.

[eric escobar]

OTIO is currently in development with input from various vendors and customers in the global film and TV industry. You can find out more about the project from the Academy Software Foundation website.

[Tranquil_Cosmos157F]

I don't see Avid, Apple and Blackmagic Design logos on the menbers page on the website. Thats's a bummer.

[ScottSimmons]

Is Adobe's on there? I don't see any logos. Resolve was the first of the NLEs to support OTIO, then Avid added a tech preview and now Adobe. Reading some of the OTIO materials there is a lot of mention about VFX workflows so I hope that doesn't become the predominant use for it. We really could use a modern interchange between NLEs. 

[Bruce Bullis · Accepted solution]

> Is Adobe's on there? I don't see any logos.

https://www.aswf.io/members/

[ScottSimmons]

Ahh perfect. Thank you! 

[trevor_7307]

Resolve has had otio and otioz import/export in recent versions.

Avid have 'preview' of otio export (Windows only) in recent versions of MC. No mention of protools yet that I've seen.

With them all joining the party, to some extent, then there's hope this will see improvement over AAF and XML. 

[Trevor_Asq]

https://github.com/AcademySoftwareFoundation/OpenTimelineIO/blob/main/ADOPTERS.md

Is the list of what NLEs are supporting OTIO

[clement_7191]

Hi,
That is great news, thank you!
Could you please add the basic PPro clip metadata to be exported in the clip metadata of the OTIO file.
I'm refering to the clip  "Tape Name", "Description" fields and etc from the Metadata Window.

Best,

C

[Bruce Bullis]

How would that get used, in other OTIO hosts? [We're trying to understand the use case, for when OTIO would be a better vehicle than a PPro project for such info...]

[clement_7191]

One of the main uses case I can think of would be client interactions, as we cannot dictate which Edit software they are using, however,  all software more or less support the same metadata keys.

Another use case would be for Asset Management System interactions, metadata are used all way through the production, not only on Edit time. This would mean we can leave breadcrums to be able to follow where a clip comes from.

Basically:

OTIO > PPro would mean to not have to manually enter again the metadata in a PPro project for each clip, minimizing mistakes made.

PPro > OTIO would mean that the metadata agreed/decided by Edit in PPro is available to all consumers of that file.

[Bruce Bullis]

Makes sense, thanks; we're convinced, metdata is a good idea. 🙂

I'm curious: Presuming we puts loads of PPro-generated metadata into OTIO files, which specific NLEs and MAMs are you hoping will read them? 

[clement_7191]

Great news! 🙂
So to start with, OTIO file can be used as standalone as well, so in Python scripts, for instance, we can get to the clip name, file path, any clip metadata without having to open any software.

Working mainly in the VFX/Animation industry, the main Edit software already supporting OTIO that we use are Final Cut PRo, Davinci Resolve Studio, the foundry suite (Hiero / Nuke Studio), RV, and ffmpeg.

But OTIO usage doesn't stop there, we are also using in 3d DCCs, to build/export sequence wide 3d scenes in Maya. for instance.

[Bruce Bullis]

>So to start with, OTIO file can be used...

Yes, we're already familiar with what OTIO could do... 😉

I meant to ask: For which specific workflows would you use OTIO, from/to Premiere Pro?

[clement_7191]

Regarding workflows, that would be most of them.

I've mentioned a couple in earlier already, a more specific one could be:

Some Layout 3d artists have the need to update the cut from the animatic reference so they export a new OTIO, could be only for a few impacted shots. Edit import it to get the updated cut in PPro. Edit live review it with the client and export a new sequence/episode wide OTIO file, to update our AMS reference and potentially deliver that OTIO to the client along with the latest movies so they can update the cut on their side too.

And all those import/export, again, carrying crucial information via metadata, not only to accelerate workflows but also to manage dependencies.

[Eric Reinecke]

I want to give a big +1 to this request as well.
When an editor does an offline edit (using editorial proxy media), we use the tape/reel name to help identify the original source camera files. When it comes time to send the edit to online/finishing, we need to find out:

1. What original source material was used (parsing this from file names is unreliable)
2. What frame ranges were used in those sources

This way, when you have a show that was shooting TB/per day of material you can go back to the footage database, unarchive just the source material that was used, and transfer that subset of media to the finishing editor. In cloud workflows this saves a ton of time downloading only the footage used in the cut.
This is also a place where EDL is historically problemmatic becasue if there is any complexity in the timeline (like transitions) the exact frame range used from the source to render the output is implicit. Assistant editors spend a lot of time "grooming" timelines to make sure source ranges can be accurrately identified - I'd love it if they could spend that time making the show better instead.

Another piece of metadata that's important is ASC CDL (American Society of Cinematographers Color Decision List) metadata. This can ensure that there is continuity in creative color decisions from set all the way through to finishing.

I think, in at a minimum, anything that we see come in via ALE is something we'd love to be carried along to the OpenTimelineIO export. This makes sure Premiere doesn't break the metadata chain and we don't lose valuable information downstreamfrom editorial - in visual effects, finishing, animation and lighting on animated shows, etc.

Just like metadata that comes from ALE, it would be helpful for XMP metadata from sources to make it on to clips or media references in the OpenTimelineIO. This allows workflows to place any arbitrary metadata that's important to stay attached to the clip on the source and be able to preserve it through to workflows. This is useful for things like database tracking IDs, script supervisor notes, QC notes from dailies processing, and many others.

Right now we see people working around the lack of metadata follow through by doing things like overloading marker names/coments or assiging workflow meaning to marker colors. This creates brittle workflows based on painstaking work editors have to do to curate their markers to match metadata already inside the files, there are even premiere pro panels people have made that dump metadata JSON into marker comments to work around the metadata loss problem.

Aside from unlocking known workflows like above, carrying all the metadata through from/to the OpenTimelineIO is a tool that people can use to design new workflows that may not be feasible or reliable today.

[trevor_7307]

Great news.

I know it's early days but do you plan to include import/export of OTIOZ (media embedded) and/or OTIOD (media in folders)?

If so will there be a trimmed/consolidated option?

Thanks

[Bruce Bullis]

Both OTIOZ and OTIOD are under consideration. It will be Some Time™, before we get there. At this point, we have no idea whether there will be any trim or consolidate functionality, distinct from PPro's Project Manager. 

[trevor_7307]

For me, a robust replacement for Avids consolidated, embedded AAF (that .OTIOZ has potential for) would be useful for archiving short sequences with media- even if it was only fully supported by NLE it was created in initially.