AcademySoftwareFoundation / AcademySoftwareFoundation/OpenTimelineIO
Discrepancy in source_range.start_time for Reversed Clips in Premiere Pro OTIO Export
- Dominant language
- C++
- Stars
- 2k
- Forks
- 351
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 1
Description
Hi everyone,
I've encountered an interesting behavior when exporting sequences from Premiere Pro to OTIO and then parsing the `.otio` file. It seems that clips which are simply reversed versions of other clips (using the same source in-point and duration in Premiere) are sometimes getting a different `source_range.start_time.value` in the OTIO export.
**Context:**
I have a Premiere Pro sequence where I've placed the same source clip multiple times on the timeline. For example:
* Clip A: Normal speed.
* Clip B: Same source footage as Clip A (same in-point, same duration), but reversed (-100% speed).
* Clip C & D: Same source footage as Clip A, but with other speed effects (e.g., 200%, 50%).
**Expected Behavior:**
I would expect that both Clip A and Clip B in the OTIO file would share the same `source_range.start_time.value`, as they originate from the exact same segment of the source media in Premiere Pro. The reversal on Clip B should ideally be represented by its `LinearTimeWarp.1` effect's `time_scalar: -1.0`, without altering its fundamental source range start.
**Actual Behavior:**
When parsing the exported `.otio` file, I'm finding that Clip A (normal) and Clips C & D (other speeds) correctly show the original `source_range.start_time.value` (e.g., let's say `1148083`). However, Clip B (the reversed one) shows a *different* `source_range.start_time.value` (e.g., `1112076` in my specific test case).
My parsing script then correctly calculates the source timecodes based on the data in the OTIO file. This means that for Clip B, it reports source timecodes that are accurate *for the source range specified in the OTIO*, but this source range doesn't match what I see as the source for that clip in Premiere Pro.
**Example Log Output from Parsing:**
Here's what my script logs when reading the `source_range.start_time.value` for these clips directly from the OTIO file:
* Clip A (normal): `sourceStartTimeValue: 1148083`
* Clip B (reversed): `sourceStartTimeValue: 1112076`
* Clip C (200% speed): `sourceStartTimeValue: 1148083`
* Clip D (50% speed): `sourceStartTimeValue: 1148083`
This confirms the OTIO file itself contains the different `sourceStartTimeValue` for the reversed clip.
**Question:**
Is this a known behavior or a potential issue with how Premiere Pro exports OTIO files for reversed clips? Or perhaps an aspect of the OTIO spec for representing reversed clips that I'm misunderstanding? It feels like the `source_range` should remain consistent if the actual source media segment used in the NLE is the same, with the reversal handled by the time warp effect.
I'm happy to provide the sample `.otio` file that demonstrates this behavior.
Thanks for any insights!
Contributor guide
Research direction
Start by obtaining the sample .otio file offered in the report and inspect the source_range.start_time.value and LinearTimeWarp.1 values for the normal and reversed clips. Compare those values with the reported Premiere Pro source segments and the OTIO representation expectations. Done means determining whether this is an exporter discrepancy or expected reversed-clip behavior, with a reproducible finding.
Written by the indexing model from the issue text.
Assessment
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100