AcademySoftwareFoundation / AcademySoftwareFoundation/OpenTimelineIO

Discrepancy in source_range.start_time for Reversed Clips in Premiere Pro OTIO Export

Open
#1,890 6 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.