AAF Reader: Global Start Time not being set for various files

[andrewmoore-nz]

Still coming across many scenarios where the global_start_time field is not being set when it should be. I see that this was supposedly addressed in #478 , and the test file included (.../sample_data/simple.aaf) seems to generate a valid global_start_time RationalTime object, but perhaps this being done in a too-specific way?

An example here of an AAF from Premiere that starts at 05:00:00:00, but when read in to an OTIO, the global_start_time comes through as null. For reference, the .xml that was exported from the same project/timeline comes through with the correct field set of:

    "global_start_time": {
        "OTIO_SCHEMA": "RationalTime.1", 
        "rate": 23.976023976023978, 
        "value": 432000
    }, 

Files attached here:

FullTestSeq_v02_TimeshiftExport_5hours_AAF_XML.zip

Also seeing this with AAFs coming from Media Composer as well. This following example should start at 01:00:00:00 but is coming through with a global_start_time of null.

ClipMutingTest_1hours_AAF.zip

[ssteinbach]

The first file has two problems:

1. Instead of containing "Timecode" objects, it contains "LegacyTimecode" objects, but our code was only looking for "Timecode" objects so they were being ignored. This issue is here:
   https://github.com/PixarAnimationStudios/OpenTimelineIO/blob/0f9a4262dc433e13711fe932c3be45e329123c92/opentimelineio_contrib/adapters/advanced_authoring_format.py#L529
2. It looks like the edit rate of both files is 24000/1001, but the time code tracks are all 24fps, so we ignore them. This issue is here:
   https://github.com/PixarAnimationStudios/OpenTimelineIO/blob/0f9a4262dc433e13711fe932c3be45e329123c92/opentimelineio_contrib/adapters/advanced_authoring_format.py#L537

#1 is a straightforward bug. #2 I need to ask about.

[ssteinbach]

The second file has problem problem 2 in it:
edit rate is: 24000/1001, FPS is: 24

[ssteinbach]

After analyzing this further, the heuristics we're using to pick the global start time don't seem to hold with your use case, with several places where your example breaks our assumptions. I'm not sure what heuristic is correct to determine that information more robustly.

[andrewmoore-nz]

@ssteinbach - Okay... good to get some clarification on that. In all scenarios, these are files that have come straight out of Media Composer/Premiere, so it's certainly not an abnormal situation... that's how they're being generated. It looks like the scope of the information that is being accepted to determine this needs to be increased? The fact that we're unable to get correct time codes for either the master or the source values makes it practically unusable at this stage.

[reinecke]

I just took a peek at this. Looking at AAF edit protocol section 6.3, it appears that there is a concept of a "Primary" timecode track as denoted by a PhysicalTrackNumber of 1.
That seems like it should address point 2.

[thecargocultnz]

We were looking at this just now.
Am I right in thinking that the framerate equality check is done using strings?
Would it be better to compare frame rates as doubles, with a bit of tolerance thrown in?

[reinecke]

Based on the AAF spec, I think we can skip even needing do that comparison. That appeared to be a way to select the "Best" timecode from a list of all possible timecodes. Given that it appears the AAF spec declares a "Primary" that is required (PhysicalTrackNumber of 1), I think we can use that as our if case.

For the record, here is an example of the start timecode from a 29.97 DFTC AAF starting at 5 hours:

  "Name": "TC1",
  "ClassName": "TimelineMobSlot",
  "Origin": 0,
  "EditRate": "30000/1001",
  "Segment": {
    "Drop": true,
    "FPS": 30,
    "Start": 539460,
    "Length": 2989,
    "DataDefinition": {
      "Identification": "7f275e81-77e5-11d2-807f-006008143e6f",
      "Description": "Timecode data (legacy)",
      "Name": "DataDef_LegacyTimecode"
    }
  },
  "PhysicalTrackNumber": 1,
  "SlotID": 8,
  "SlotName": "TC1",
  "MediaKind": "LegacyTimecode"
}

So it looks like we can use Start as value and EditRate as rate to construct a global start RationalTime.

[jminor]

Oh good. That comparison was just a heuristic that we added because we didn't know how to distinguish between them. I'd trust the spec over our guess any day :)