Proposal: kOfxImageClipPropDisplayOffset about openfx HOT 6 OPEN

This might be better as kOfxImageClipPropDisplayTimeOffset

from openfx.

• 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?

from openfx.

from openfx.

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

from openfx.

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...

from openfx.

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

from openfx.