Standard version: 2.0
Several aspects of the API were, in their original conception, perceived to be fixed for the whole temporal duration of an effect, and generally under the control of the application. This, unfortunately, is not true, and has caused problems for various plug-in hosts and developers.
Initially this consisted of what pixel formats and data types were present on input clips and how they should be munged for the plugin, thus the the clip preferences action. Various other properties that were thought to be temporally invariant were added to the action.
The changes suggested here would lead to the death of the clip preferences action.
A plug-in still needs to specify the data format on it accepts data in and what it outputs. To this end. This should be done by a new kOfxImageEffectActionGetPixelFormats action. This would be similar to the current kOfxImageEffectActionGetClipPreferences action, except that….
This needs to be worked in with the suggested plane extensions in a consistent way.
A corresponding call is needed in the image effect suite, that reports the data format of a clip at a specific time, something like clipGetPixelFormats
A property should be available on plug-in and host indicating if they support per frame data formats. If not, the behaviour is the equivalent of the old API.
Note that, as they can now vary with time, we should then remove the following properties from clip, as they need to be fetched at a time via the clipGetPixelFormats,
Some effect attributes are temporally invariant, these are the remainder of the properties of the clip preferences argument, being….
This could be done in one of two ways, either by another action, which the host calls when it needs to, or by having properties on the effect instance that are set by the plug-in in response to parameter changes.