AAF Reader: Incorrect Clip Source Times

[andrewmoore-nz]

So, bear with me on this one... it's a little complicated; a little confusing; and I'm still trying to piece together as many of the exact details as I can.

I'm just starting to notice a very serious issue with available_range's in a clip's media_reference (and source_range) coming through from Media Composer AAFs.

There appears to be inconsistency in when the the correct start_time is used from the underlying AAF data. I am yet to see a specific reason/pattern as to when this is happening, so best I can do at this point is just give as much info as I can for the situation.

---

ExampleClip_col_mat12_v025_p005

This clip has source timecode values of In: 00:00:41:21 and Out: 00:01:08:16, but the available_range/source_range object generated by OTIO comes through as:

"available_range": {
    "OTIO_SCHEMA": "TimeRange.1", 
    "duration": {
        "OTIO_SCHEMA": "RationalTime.1", 
        "rate": 23.97602397602398, 
        "value": 643
    }, 
    "start_time": {
        "OTIO_SCHEMA": "RationalTime.1", 
        "rate": 23.97602397602398, 
        "value": 4
    }
},
...
"source_range": {
    "OTIO_SCHEMA": "TimeRange.1", 
    "duration": {
        "OTIO_SCHEMA": "RationalTime.1", 
        "rate": 23.97602397602398, 
        "value": 643
    }, 
    "start_time": {
        "OTIO_SCHEMA": "RationalTime.1", 
        "rate": 23.97602397602398, 
        "value": 4
    }
}

Using this info, we get source timecode values of In: 00:00:00:04 and Out: 00:00:26:23. The correct timecode values above were generated by opening the AAF in Media Composer and exporting EDLs, and the incorrect timecode values (the available_rage object) were generated by reading the same AAF using OTIO.

Consulting this specific clip's info in the Media Composer bin we see:

From this, it appears that the Start (TC) and Aux TC1 fields are being ignored, and simply the frames being used are determining the available_range - frames 4 (00:00:00:04) through 647 (00:00:26:23) of the total 651 available.

---

The inconsistency appears then looking at another version of the same clip that exists below this one on the multi-track timeline....

ExampleClip_col_v024

This clip also has source timecode values of In: 00:00:41:21 and Out: 00:01:08:16, but the available_range/source_range object generated by OTIO comes through correctly as:

"available_range": {
    "OTIO_SCHEMA": "TimeRange.1", 
    "duration": {
        "OTIO_SCHEMA": "RationalTime.1", 
        "rate": 23.97602397602398, 
        "value": 652
    }, 
    "start_time": {
        "OTIO_SCHEMA": "RationalTime.1", 
        "rate": 23.97602397602398, 
        "value": 1000
    }
},
...
"source_range": {
    "OTIO_SCHEMA": "TimeRange.1", 
    "duration": {
        "OTIO_SCHEMA": "RationalTime.1", 
        "rate": 23.97602397602398, 
        "value": 643
    }, 
    "start_time": {
        "OTIO_SCHEMA": "RationalTime.1", 
        "rate": 23.97602397602398, 
        "value": 1005
    }
}

...and this specific clip's info in the Media Composer bin:

---

From this I might think that it perhaps has something to do with the Mark In field that has been set on the clip, but there is also another clip here (again, a different version of the same clip stacked underneath) that has these fields set:

...and again the available_range and source_range objects are not correct, with a value of:

"source_range": {
    "OTIO_SCHEMA": "TimeRange.1", 
    "duration": {
        "OTIO_SCHEMA": "RationalTime.1", 
        "rate": 23.97602397602398, 
        "value": 643
    }, 
    "start_time": {
        "OTIO_SCHEMA": "RationalTime.1", 
        "rate": 23.97602397602398, 
        "value": 4
    }
}

...for both.

I have put together some examples files as best I can given the sensitive content of the AAF that these errors have come from. There is a screen shot of the relevant Media Composer clip info and the OTIO Clip schema for each clip, along with a screenshot of the Media Composer bin and the EDL info that MC exports for these clips.

AAF_SourceReadingError_ExampleFiles_190603.zip

Unsure as to whether this may be more something to address with PyAAF as opposed to here, but figured it worth raising the issue here so everyone's aware and see what the best approach to figuring out a solution might be.

[andrewmoore-nz]

@jminor , @ssteinbach , @freesonluxo ,

Upon further inspection, I seem to have tracked down what appears to be causing the issue... or, at least, what is an indicator to the underlying issue.

For the clips where the available_range and source_range are coming through incorrect, they also have their Tape Name field set in Media Composer. The clips that are coming through correctly have nothing in this field.

I was then able to simply add some text to the Tape Name field of one of the clips, export as an AAF from MC, and it's available_range and source_range fields started coming through incorrectly. I have two example AAFs that I can send through to demonstrate this behaviour.

[ssteinbach]

Hi @andrewmoore-nz, Thanks for the super detailed bug report! Do you know if this a regression from the most recent checkin?

[andrewmoore-nz]

Heya @ssteinbach ... no worries. Trying to give all the info I had was the best way for me to try and make sense of it myself.

Prior to the latest commit - #517 - we weren't able to actually read these AAFs at all, due to the CannotComputeAvailableRangeError we were seeing, which was addressed here - #484 . In order to read these files, I was having to roll back to #462 , and we're seeing the same results there.

Can send through some example AAFs for you to check out, but would prefer to do so through a private channel.

[andrewmoore-nz]

@ssteinbach @freesonluxo

Hey guys. Just wanted to give this issue a bump, as it's something that's just come up again trying to actually use a Media Composer AAF through OTIO.

Any thought perhaps as to what might be happening here with the Tape Name field effecting the source_ranges?

[jminor]

Sorry for the delayed response, @andrewmoore-nz. We're focused on landing the C++ branch and haven't been working on the AAF adapter these past few weeks.

Do you have a work-around for this? Are you able/willing to dive into the AAF adapter code to try to fix this? My suspicion is that either the auxiliary timecode, mark in/out, or structure of how the clip refers to the tape-based media could be the culprit. There are some heuristics in the AAF adapter that attempt to find the correct start timecode which are likely not doing the right thing in this case.

I have reached out to Avid for some guidance on understanding how timecode is represented in cases like this, as well as a few others (timing effects). I'm not sure when we'll hear back from them.

If you can send example AAFs that aren't sensitive that would be ideal.

[andrewmoore-nz]

Hey @jminor ,

Apologies for the delay on this one... just circling back around to look at some of the AAF issues still on our radar.

I've got some examples of this that I'm able to send through, yes. I'd prefer to do it through a private channel though if possible.

[reinecke]

@andrewmoore-nz provided me with some test AAFs. File 1 has the correct timecode values as parsed by OTIO, and File 2 has incorrect values.

I put a breakpoint just after this line:

timecode_info = _extract_timecode_info(last_mob) if last_mob else None in _transcribe under the isinstance(item, aaf2.components.SourceClip) branch.

Looking at the mobs found by _find_timecode_mobs, I discovered the following.

Loading file 1:

(Pdb) p mobs
[<aaf2.mobs.MasterMob "wwo_186_bw_v003.mov" urn:smpte:umid:060a2b34.01010101.01010f00.13000000.060e2b34.7f7f2a80.5aef92da.5714008b at 0x10801e410>, <aaf2.mobs.SourceMob "wwo_186_bw_v003.mov.PHYS" urn:smpte:umid:060a2b34.01010101.01010f00.13000000.060e2b34.7f7f2a80.5aef92da.5726008b at 0x108020590>, <aaf2.mobs.SourceMob "wwo_186_bw_v003.mov" urn:smpte:umid:060a2b34.01010101.01010f00.13000000.060e2b34.7f7f2a80.5aef92da.5727008b at 0x108025110>]

(Pdb) p mobs[0].slots[1].segment
<aaf2.components.EdgeCode EdgeCode at 0x1080a9110>
(Pdb) mobs[0].slots[1].segment.dump()
 AvEdgeType <aafInt16 TypeDefInt> 3
 AvFilmType <aafInt16 TypeDefInt> 0
 Header <aafDataValue TypeDefVarArray> [0, 0, 0, 0, 0, 0, 0, 0]
 CodeFormat <EdgeType TypeDefEnum> EtNull
 FilmKind <FilmType TypeDefEnum> Ft35MM
 Start <aafPositionType TypeDefRename> 1000
 Length <aafLengthType TypeDefRename> 652
 DataDefinition <DataDefinitionWeakReference TypeDefWeakRef> <aaf2.dictionary.DataDef Edgecode d2bb2af0-d234-11d2-89ee-006097116212 at 0x10807a830>

(Pdb) p mobs[-1].slots[1].segment
<aaf2.components.Timecode Timecode at 0x1080ac590>
(Pdb) mobs[-1].slots[1].segment.dump()
 Drop <Boolean TypeDefEnum> False
 FPS <aafUInt16 TypeDefInt> 24
 Start <aafPositionType TypeDefRename> 1000
 Length <aafLengthType TypeDefRename> 652
 DataDefinition <DataDefinitionWeakReference TypeDefWeakRef> <aaf2.dictionary.DataDef Timecode 7f275e81-77e5-11d2-807f-006008143e6f at 0x1080c96b0>

Loading file 2:

(Pdb) p mobs
[<aaf2.mobs.MasterMob "wwo_186_bw_v003.mov" urn:smpte:umid:060a2b34.01010101.01010f00.13000000.060e2b34.7f7f2a80.5aef92da.5714008b at 0x108460470>, <aaf2.mobs.SourceMob "wwo_186_bw_v003.mov.PHYS" urn:smpte:umid:060a2b34.01010101.01010f00.13000000.060e2b34.7f7f2a80.5aef92da.5726008b at 0x1084636b0>, <aaf2.mobs.SourceMob "TestNm1" urn:smpte:umid:060a2b34.01010105.01010f10.13000000.dc4ad4ac.86379205.9060003e.e1c8be9f at 0x108469d70>]

(Pdb) p mobs[0].slots[1].segment
<aaf2.components.EdgeCode EdgeCode at 0x1084fa1d0>
(Pdb) mobs[0].slots[1].segment.dump()
 AvEdgeType <aafInt16 TypeDefInt> 3
 AvFilmType <aafInt16 TypeDefInt> 0
 Header <aafDataValue TypeDefVarArray> [0, 0, 0, 0, 0, 0, 0, 0]
 CodeFormat <EdgeType TypeDefEnum> EtNull
 FilmKind <FilmType TypeDefEnum> Ft35MM
 Start <aafPositionType TypeDefRename> 1000
 Length <aafLengthType TypeDefRename> 652
 DataDefinition <DataDefinitionWeakReference TypeDefWeakRef> <aaf2.dictionary.DataDef Edgecode d2bb2af0-d234-11d2-89ee-006097116212 at 0x1084c08f0>

(Pdb)  p mobs[-1].slots[-1].segment
<aaf2.components.Sequence Sequence at 0x108510b90>
(Pdb) mobs[-1].slots[-1].segment.dump()
 Components <kAAFTypeID_ComponentStrongReferenceVector TypeDefVarArray>
   <aaf2.components.Timecode Timecode at 0x108599770>
     Drop <Boolean TypeDefEnum> False
     FPS <aafUInt16 TypeDefInt> 24
     Start <aafPositionType TypeDefRename> 0
     Length <aafLengthType TypeDefRename> 10368000
     DataDefinition <DataDefinitionWeakReference TypeDefWeakRef> <aaf2.dictionary.DataDef Timecode 7f275e81-77e5-11d2-807f-006008143e6f at 0x108554bf0>
 Length <aafLengthType TypeDefRename> 10368000
 DataDefinition <DataDefinitionWeakReference TypeDefWeakRef> <aaf2.dictionary.DataDef Timecode 7f275e81-77e5-11d2-807f-006008143e6f at 0x108554bf0>

I don't have any conclusions based on this, but it certainly seems that for some reason the timecode info isn't being hinted correctly, however there are some EdgeCode information. I'm not sure what role that should have in this context. I'll keep digging, but would love some thoughts from those more familiar with the AAF data model.

[ssteinbach]

@markreidvfx might have some insight into this

[ssteinbach]

These PRs still look like they're in progress, going to push them back a release.

[ssteinbach]

@stefanschulze @andrewmoore-nz did this stuff get folded into some of the PRs that were landed? #739 for example?

[andrewmoore-nz]

@ssteinbach Heya. Doesn't look like #739 fixes any of these issues, no. Have just had a quick look at PR and it doesn't appear to be addressing any of the issues that are fixed in my PR. Have tried getting some input from people several times on that but to no avail.

[reinecke]

Referring this over to https://github.com/OpenTimelineIO/otio-aaf-adapter - all new development on the AAF adapter is being done there.

[reinecke]

Here's a branch porting this to the new adapter - @markreidvfx says it still needs some work: https://github.com/markreidvfx/otio-aaf-adapter/tree/AAF_Src_Timecode_Parsing