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

[LFarmbot]

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!

[LFarmbot]

Hi all,

I've done some more detailed testing, and the results are quite interesting. It seems the behavior of source_range.start_time might be inconsistent depending on whether the reversed clip is a sub-clip or a full-length clip.

Test Setup:

I created a Premiere Pro sequence with the following clips, all from the same source media (C002C003_241103QA.mov, 23.976fps):

1. Clip A (Partial Reversed - Middle): A 1-second segment from the middle of the source clip, reversed.
   • Premiere Source TC Display: 13:05:24:19 - 13:05:23:20
2. Clip B (Partial Reversed - Start): The first 1-second segment of the source clip, reversed.
   • Premiere Source TC Display: 12:48:38:19 - 12:48:37:20
3. Clip C (Partial Reversed - End): The final 1-second segment of the source clip, reversed.
   • Premiere Source TC Display: 13:20:56:19 - 13:20:55:20
4. Clip D (Full Clip - Forward): The entire source clip, played forward.
   • Premiere Source TC Display: 12:48:37:20 - 13:20:56:19
5. Clip E (Full Clip - Reversed): The entire source clip, reversed.
   • Premiere Source TC Display: 13:20:56:19 - 12:48:37:20

OTIO Export and Parsing Results:

I exported this sequence to OTIO and parsed it. Here's a summary of the source_range.start_time.value from the OTIO for each clip, and the resulting source timecodes calculated by my script (which matches what Premiere displays if the OTIO start_time is as expected):

Clip Description	OTIO source_range.start_time.value	My Script's Calculated Source TC (from OTIO data)	Actual Source TC Displayed in Premiere
A (Partial Rev - Mid)	1129196	13:04:10:19 - 13:04:09:20	13:05:24:19 - 13:05:23:20
B (Partial Rev - Start)	1153340	13:20:56:19 - 13:20:55:20	12:48:38:19 - 12:48:37:20
C (Partial Rev - End)	1106828	12:48:38:19 - 12:48:37:20	13:20:56:19 - 13:20:55:20
D (Full Clip - Fwd)	1106828	12:48:37:20 - 13:20:56:19	12:48:37:20 - 13:20:56:19
E (Full Clip - Rev)	1106828	13:20:56:19 - 12:48:37:20	13:20:56:19 - 12:48:37:20

Observations:

• Full Clips (D & E): For the full clips (forward and reversed), the OTIO source_range.start_time.value is 1106828 (which is 12:48:37:20, the true start of the source media). My script correctly calculates the source timecodes, and these match what Premiere displays. This is perfect.
• Partial Reversed Clips (A, B, C): For the three partial reversed clips, the source_range.start_time.value in the OTIO file is different from what would be expected if it were simply referencing the original segment's start. Consequently, my script (correctly processing the OTIO data it's given) produces source timecodes that do not match what Premiere itself displays as the source range for these clips.

Example - Clip B (Partial Reversed - Start):

• In Premiere, this is the first second of the source (12:48:37:20 to 12:48:38:19, which is frames 1106828 to 1106851).
• Reversed, Premiere correctly displays this as 12:48:38:19 - 12:48:37:20.
• However, the OTIO file gives source_range.start_time.value: 1153340 (which is 13:20:55:20). My script then calculates TC 13:20:56:19 - 13:20:55:20 for this clip.

This suggests that the Premiere Pro OTIO exporter might be altering the source_range.start_time for partial reversed clips in a non-intuitive way, while it handles full-length reversed clips as expected.

It seems the crucial element is whether the reversed clip is a sub-clip or uses the full media extent. My parsing logic correctly handles the source_range and LinearTimeWarp effect as provided by the OTIO file. The discrepancy arises from the OTIO data itself for these specific partial reversed clip cases.

Hope this additional detail helps clarify the behavior I'm seeing! I can provide the OTIO file used for this test if needed.

[jminor]

Thanks for testing this @LFarmbot! Please also see this time warp test suite which includes some reversed clips: https://github.com/jminor/otio-time-warp-test-suite

[LFarmbot]

Thanks for testing this @LFarmbot! Please also see this time warp test suite which includes some reversed clips: https://github.com/jminor/otio-time-warp-test-suite

Hi @jminor, thanks for sharing, I've quickly scanned through the codebase and this looks very helpful to hopefully nail this bug, I'll do a deep dive later tonight and will submit with your provided test files. Thanks again for the quick response, it's much appreciated!