You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Parts of the codebase assume the existence of a tracks attribute. However, ALE inputs don't have this. This is because the ALE adapter doesn't follow the "Canonical Structure" with a Timeline containing tracks which contain clips. Instead it uses a SerializableCollection containing clips directly.
To Reproduce
otiostat outputs an error for every sample ALE file:
$ otiostat ./contrib/opentimelineio_contrib/adapters/tests/sample_data/*.ale
parsed: True
top level object: SerializableCollection.1
number of tracks: 0
There was a system error: 'opentimelineio._otio.SerializableCollection' object has no attribute 'tracks'
...
otioconvert also attempts to access a tracks attribute on the SerializableCollection:
Adapters should not create data structures that other parts of the library don't know how to handle.
I'm not familiar enough with this library or why the ale adapter was created this way, to know the correct solution. Here are the two options I see:
1. Handle differences and catch errors
The tracebacks above should be inspected and we attempt to proceed as best as possible given the different schemas used. Simple to catch the error in otiostat, but for otioview and otioconvert we may have to add special case code or error with a friendly message explaining this command isn't available with this datatype.
2. Convert to using Canonical Structure
Amend the ALE adapter to create objects in the canonical format. Perhaps behind a flag, for backwards compatibility?
I've amended a few lines, just to test the feasibility of this. See main...tomviner:OpenTimelineIO:ale-adapter-attrib-errors It's totally incomplete, but it does enable the commands to function:
otiostat
Before
$ otiostat ./contrib/opentimelineio_contrib/adapters/tests/sample_data/sample.ale
parsed: True
top level object: SerializableCollection.1
number of tracks: 0
There was a system error: 'opentimelineio._otio.SerializableCollection' object has no attribute 'tracks'
deepest nesting: 1
number of clips: 4
total duration: n/a
total duration in timecode: n/a
top level rate: n/a
clips with cdl data: 0
Tracks with non standard types: 0
With patch
$ otiostat ./contrib/opentimelineio_contrib/adapters/tests/sample_data/sample.ale
parsed: True
top level object: Timeline.1
number of tracks: 1
Tracks are the same length: True
deepest nesting: 4
number of clips: 4
total duration: RationalTime(402, 24)
total duration in timecode: 00:00:16:18
top level rate: 24.0
clips with cdl data: 0
Tracks with non standard types: 0
Diff
Note the error message, which is actually sent to stderr, is fixed. And note the duration is now filled in.
-There was a system error: 'opentimelineio._otio.SerializableCollection' object has no attribute 'tracks'
parsed: True
-top level object: SerializableCollection.1-number of tracks: 0-deepest nesting: 1+top level object: Timeline.1+number of tracks: 1+Tracks are the same length: True+deepest nesting: 4
number of clips: 4
-total duration: n/a-total duration in timecode: n/a-top level rate: n/a+total duration: RationalTime(402, 24)+total duration in timecode: 00:00:16:18+top level rate: 24.0
clips with cdl data: 0
Tracks with non standard types: 0
otioconvert
This now works without an exception. Although round-tripping back to ALE loses a lot of data, as my patch is incomplete.
Bug Report
Broken Functionality
Parts of the codebase assume the existence of a
tracks
attribute. However, ALE inputs don't have this. This is because the ALE adapter doesn't follow the "Canonical Structure" with aTimeline
containingtracks
which containclips
. Instead it uses aSerializableCollection
containingclips
directly.To Reproduce
otiostat
outputs an error for every sample ALE file:otioconvert
also attempts to access atracks
attribute on theSerializableCollection
:otioview
attempts to access atracks
attribute on theClip
, when you click an item in the sidebar:Expected Behavior
Adapters should not create data structures that other parts of the library don't know how to handle.
I'm not familiar enough with this library or why the ale adapter was created this way, to know the correct solution. Here are the two options I see:
1. Handle differences and catch errors
The tracebacks above should be inspected and we attempt to proceed as best as possible given the different schemas used. Simple to catch the error in
otiostat
, but forotioview
andotioconvert
we may have to add special case code or error with a friendly message explaining this command isn't available with this datatype.2. Convert to using Canonical Structure
Amend the ALE adapter to create objects in the canonical format. Perhaps behind a flag, for backwards compatibility?
I've amended a few lines, just to test the feasibility of this. See main...tomviner:OpenTimelineIO:ale-adapter-attrib-errors It's totally incomplete, but it does enable the commands to function:
otiostat
Before
With patch
$ otiostat ./contrib/opentimelineio_contrib/adapters/tests/sample_data/sample.ale parsed: True top level object: Timeline.1 number of tracks: 1 Tracks are the same length: True deepest nesting: 4 number of clips: 4 total duration: RationalTime(402, 24) total duration in timecode: 00:00:16:18 top level rate: 24.0 clips with cdl data: 0 Tracks with non standard types: 0
Diff
Note the error message, which is actually sent to stderr, is fixed. And note the duration is now filled in.
otioconvert
This now works without an exception. Although round-tripping back to ALE loses a lot of data, as my patch is incomplete.
otioview
There's now no sidebar, just a timeline:
Thoughts?
The text was updated successfully, but these errors were encountered: