Standard version: 2.0

Major Change

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.

Data Formats

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

• it can be called per frame
• the inargs include the effect time to calculate the data format at,
• the out args only consist of the properties to indicate pixel type and component type.

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,

• kOfxImageEffectPropComponents
• kOfxImageEffectPropPixelDepth
• kOfxImageClipPropUnmappedPixelDepth
• kOfxImageClipPropUnmappedComponents

Temporally Invariant Attributes

Some effect attributes are temporally invariant, these are the remainder of the properties of the clip preferences argument, being….

• the frame rate,
• the field order,
• whether the effect can be continuously sampled,
• whether the effect is frame varying.

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.