For the testing data, we also need to check the retime effects (LinearTimeWarp, FreezeFrame, TimeEffect). Since the method name relates to retiming, this will cover the full range of functions. Great job on practically developing the unittest we really need! I'm thinking about whether we should add the test to the appropriate folder. @kalisp and @antirotor could lend a hand here, especially since ayon-core doesn't have a test folder yet.

Before the introduction of Resolve's native OTIO, we mainly relied on two attributes:

• The clip's source start frame as a relative range to the available media range.
• The clip's media range as an absolute range, including the metadata timecode value.

With Resolve's interpretation of OTIO now in play, we consider:

• The clip's source start frame refers to a trimmed absolute range that is available.
• The media range remains absolute, including metadata.

We reference the media source to an absolute value with included metadata because of FFMPEG. Since we use FFMPEG for video trimming, it's crucial to have the timecode correctly defined.

First, figure out if the clip source range is relative or absolute to the media range. Next, find the relative source frame value and continue as before, making sure to clear up any confusing code that's mistakenly referring to me (old me 😄).

... especially since ayon-core doesn't have a test folder yet.

but it can - I added one for my own tests, see feature/OP-1188_better-representation-model branch.

The method get_media_range_with_retimes is used in collect_timeline_instances.py on line 300 and also in extract_product_resources.py on line 413.

I originally used this method to calculate how much material needs to be prepared for on-the-fly Flame transcoding. While looking into flame_export.py, which handles ocio clip data, I noticed that from line 256, the available frame range on ImageSequenceReference is set by frame number rather than Timecode. This confirms your assumption was correct.

When I wrote the Flame integration two years ago, I faced the challenge of using the embedded TC on the image sequence. From the code in flame_export.py on line 305, I can see that I was using the embedded TC to calculate the true source in/out for the clip, and later for calculating retime speed (though this equation might be incorrect).

I was doing some tests within Hiero editorial and noticed some differences in the resulting calculations. Here is the outcome before and after the fix. Since it's an old publisher, I could only copy and paste some resulting logs.

otio_clip_publish_data_hiero.zip

I was doing some tests within Hiero editorial and noticed some differences in the resulting calculations. Here is the outcome before and after the fix. Since it's an old publisher, I could only copy and paste some resulting logs.

otio_clip_publish_data_hiero.zip

Thanks for the additional tests in Hiero, I've investigated that a bit more.
It looks like the issues comes from AYON native OTIO exporter which introduce a mismatch between the available and source ranges.

When I use Hiero native OTIO exporter, our clips are retimed as expected.
I've made an issue to fix this in ayon-hiero: ynput/ayon-hiero#13

Task linked: OP-8066 Resolve: update to new publisher

I'm not sure what is state of this PR?

For the testing data, we also need to check the retime effects (LinearTimeWarp, FreezeFrame, TimeEffect). Since the method name relates to retiming, this will cover the full range of functions. Great job on practically developing the unittest we really need! I'm thinking about whether we should add the test to the appropriate folder. @kalisp and @antirotor could lend a hand here, especially since ayon-core doesn't have a test folder yet.

I'm not sure what is state of this PR?

I'm waiting on approval on this one.
I have addressed the feedback and added the tests, the Hiero problem that was reported will be tackled as its own in ayon-hiero (ynput/ayon-hiero#13).