Creating AAF from OTIO does not work when imported into DaVinci Resolve

[stefanschulze]

Converting an AAF to OTIO and back to AAF, importing the created AAF works fine in Media Composer, but can't be imported into DaVinci Resolve. The Error is "no primary timecode track found. Violates AAF edit protocol 6.3"

Section 6.3 of the edit protocol states (besides some other requirements): "A top-level composition shall contain one or more timecode tracks and include a Primary timecode track. Timecode tracks shall use the MobSlot::PhysicalTrackNumber property to distinguish their type, as shown in the Table below."

Seems the current AAF writer does not create such Timecode track and Media Composer is more forgiving, but DaVinci Resolve is not.

[Jameclarke]

Was this tested with Resolve 16.2.5 because this update has an AAF fix https://www.blackmagicdesign.com/support

[stefanschulze]

I was testing it with with 16.2.2. I just upgraded to 16.2.5 and I still get the same error.

[donquibeats]

Tests-2020-12-16.zip

I am still able to reproduce this error in DaVinci Resolve 17.0B build 13.

The above attachment contains an example AAF (and equivalent FCP XML and OTIO). The AAF file imports fine into Premiere but not Resolve, giving the error message described above.

[donquibeats]

This is unfortunately still an issue with Resolve 17.3 and 18.0.

Because of a separate Resolve bug with how it no longer likes to conform image sequences from FCPXML files (as of 17.4), being able to import AAF into Resolve is now more desirable for us. Is there anyone who could help point us in the right direction for this? We might be able to rustle up a small amount of funds to pay someone to help address the issue, but I wouldn't know where to start myself. Is this in OpenTimelineIO code, or PyAAF?

[jminor]

This is likely a change needed in the OTIO AAF adapter. Specifically in here: https://github.com/PixarAnimationStudios/OpenTimelineIO/blob/main/contrib/opentimelineio_contrib/adapters/aaf_adapter/aaf_writer.py It probably needs to call create_timecode_slot and attach it to the right place. Hopefully that's enough of a start that someone else could jump in and give it a try.

[markreidvfx]

Adding a Primary Timecode track to the toplevel composition fixes the file for me. Here is some rough example pyaaf2 code that fixes the aaf otio generates. Attached is the fixed file too, I tested this in resolve 18

import sys
import shutil
import os
import aaf2

name, ext = os.path.splitext(sys.argv[1])
fix_file = name + "_fix.aaf"

shutil.copy(sys.argv[1], fix_file)

with aaf2.open(fix_file, 'rw') as f:
    for mob in f.content.toplevel():
        slot = f.create.TimelineMobSlot()
        slot.slot_id = 2
        slot.name = "TC"
        slot['PhysicalTrackNumber'].value = 1
        slot.segment = f.create.Timecode()
        mob.slots.append(slot)

Test-2020-12-16-fix.zip

[donquibeats]

Thanks very much for this! I've just tested this on another AAF generated today, and yes, this turns the AAF generated via otio.adapters.write_to_file() into an AAF file that Resolve is willing to load. It's extremely quick too.

Thanks so much for your help, this is a good step forward

[donquibeats]

Just as a footnote, this fix also works in Resolve 17.4 as well as 18

[markreidvfx]

Great to hear! The adapter just needs to modified somewhere, I'll take a closer look when I get a chance.

[ssteinbach]

Thanks for working through this! @markreidvfx, my apologies, but I know you have a bunch of open PRs that we'd like to assess. did a fix for this ever get worked into one of your open PRs? Just want to make a note of that so that we can link this issue to one of those PRs if so. thanks all!

[markreidvfx]

I haven't opened a PR for this yet, but plan to soon. When I do I'll reference this issue.

[jminor]

Now that Resolve 18.5 supports native OTIO import/export, is this issue still relevant?

[markreidvfx]

I've had a pending pull request in the external adapter that fixes this issue for quite some time. https://github.com/OpenTimelineIO/otio-aaf-adapter/pull/9

[jminor]

Great! Sorry for missing that @markreidvfx - we will have to make sure to include the adapter repos in our project issue/PR reviews more actively now.