Proposal: kOfxImageClipPropDisplayOffset

[fxtech]

Background:
Silhouette (and probably other hosts) starts "time" at frame 0, but has a setting to display time with a frame number offset.
kOfxImageEffectPropFrameRange isn't enough to convey this to plugins, so if a plugin has a custom browser that can display frame time, it doesn't know what this time offset should be.

My proposal is to add a new clip property: kOfxImageClipPropDisplayOffset

Type: double X 1
Property Set - an image clip instance (read only)

Normally this would be zero, but on hosts that support it, it would be the human-readable frame offset to be added time values so frame numbers will match the host's user interface.

[fxtech]

This might be better as kOfxImageClipPropDisplayTimeOffset

[garyo]

• This is in frames, not seconds, correct?
• Should it always be an integer or could it be fractional?
• How does it behave when retiming is applied? (If it doesn't that's OK, but let's specify that)
• Just to clarify, a host may set this, and the plugin can only read it. The plugin should add this value to any OFX frame values before displaying to the user, and similarly the plugin should subtract this from any user-supplied frame numbers before passing to OFX.

Do I have that all right?

[fxtech]

On 10/20/19 4:48 PM, GaryO wrote: * This is in frames, not seconds, correct?

Yes. Same units and format as *kOfxPropTime*.

* Should it always be an integer or could it be fractional? * How does it behave when retiming is applied? (If it doesn't that's OK, but let's specify that)

Good question. It could probably be added to both input and output time, since it's merely a reference point for when time starts.

* Just to clarify, a host may set this, and the plugin can only read it. The plugin should add this value to any OFX frame values before displaying to the user, and similarly the plugin should subtract this from any user-supplied frame numbers before passing to OFX.

Yes indeed! In our specific use case, it would only be added to the current time display field in plugins that have their own built-in players.

Do I have that all right?

Yes!

[fxtech]

As per list discussion perhaps this should get rolled into the updated timeline suite.

[revisionfx]

Yes, should be in timelineSuite header file at least.

My new thought on this is the world timeline should refer to a data container to which the clip is parented. Different applications have different words for where the clip resides (e.g. comp, sequence...) and in a way Project in OFX. Timeline happens to be the term Resolve uses for that.

We might consider a sort of utility suite at specs level, e.g. ofxTimeLineIO that gathers all time relevant properties one can query from that parent structure. I am coming to the conclusion that this would be a good model and as well with sibling Spatial Format too (another discussion). You still have the individual properties, but once suitified (or is suitefied) one can check the suite exists and rely on that for everything. This could also allow us to patch how individual host interpret certain properties right now. Like one host at least returns a ratio for FPS instead of an explicit FPS.

The third pion that could be friended here in a complete representation is related to our weak context definition. The example of Vegas two inputs is a general context that requires attention, in a way is also Resolve Edit page - to accomplish the same outcome, BMD selected to allow this when transition is the context. Another example is effect requiring to be first on strack, as they become useless whenever a transform of some sort has been applied... Will make this a pre-github discussion at some point not to be too OT here...

[revisionfx]

Also note Issue #47 as related to this - in practice should be done at once