[Adobe/Premiere] Plugin likely incompatible with subclips with non-zero start timecode (same root cause as #25)

[Talla]

Symptom

Applying the Gyroflow effect to a Premiere subclip (non-zero in-point relative to its master clip) produces wrong/shaky stabilization. Applying the same effect to the full master clip on the timeline (same underlying media, same .gyroflow project, trimmed to the identical in/out) stabilizes correctly.

Likely root cause

Same class of bug as #25, but in the Adobe plugin instead of OFX. In adobe/src/premiere.rs, the per-frame timestamp fed to the stabilizer is derived only from:

let mut trim_range = None;
if let Ok(pr::PropertyData::Int64(start)) = filter.video_segment_suite.node_property(media_node.1, pr::Property::Media_InPointMediaTimeAsTicks) {
    if let Ok(pr::PropertyData::Int64(end)) = filter.video_segment_suite.node_property(media_node.1, pr::Property::Media_OutPointMediaTimeAsTicks) {
        let start = filter.video_segment_suite.transform_node_time(clip_node, start)?;
        ...
    }
}
...
let frame = render_params.clip_time() as f64 / fps_ticks;

There's no lookup for a subclip's true source-start-frame relative to the master media (the piece #25 identified as missing for OFX/Resolve, later fixed there via a new Resolve 20 API). Since the .gyroflow project's gyro data is anchored to the master file's own timeline (frame 0 = start of the original media), if clip_time()/in-point ticks resolve relative to the subclip's own local zero instead of the master file's zero, every frame is fed the wrong gyro sample — actively wrong rotation, not just missing stabilization.

Repro

1. Record/import a clip with a working, synced .gyroflow project (external gyro logger, e.g. NiYien/SenseFlow).
2. In Premiere, create a subclip starting partway into the master clip (non-zero in-point).
3. Apply the Gyroflow effect to the subclip → shaky/wrong output, even though the plugin correctly detects/loads the .gyroflow project.
4. Drag the same master clip onto the timeline instead, trim to the identical in/out, apply the effect → stabilizes correctly.

Versions

• Gyroflow-Adobe-windows.aex v2.1.1.178 (2025-08-24 release)
• Premiere Pro, Windows 11
• Source: 3840x2160@50fps, external gyro (SenseFlow/NiYien), .gyroflow v4 project format

Related: #25

[Talla]

Tracked this down — opened #60 with a fix.

Root cause: a bin subclip has its own time domain, so render_params.clip_time() is relative to the subclip's start while gyro data is anchored to master-file time. Every subclip frame therefore gets the gyro sample from Media_ContentStart earlier — an actively wrong rotation per frame, which is why it looks shaky rather than merely unstabilized.

The offset turns out to be reachable: the media node reports Media_ContentStart for a subclip (equal to its Media_InPointMediaTimeAsTicks, i.e. expressed in master-file time), and doesn't report it at all for a plain master clip — which is what makes the correction inherently a no-op there. Unlike the OFX side, there's no Premiere equivalent of Resolve 20's kOfxImageEffectPropSrcFrame, so the offset has to come from the segment properties.

On my footage (50fps, subclip starting 18.08s into the master), instrumented timestamp_us went from a 0–5.84s window to the correct 18.08–23.92s, while a master clip's media_time == clip_time tick for tick. Verified across master clips, trimmed subclips, 50% speed, proxies, "use full clip extents", and both CUDA and OpenCL on Premiere 26.2.0. Full numbers in #60.

Note the fix covers the GPU filter path only — details and reasoning in the PR.