Standard version: 2.0

Major Change

Alexandre - Natron - Inria

The current ImageEffect architecture abstracts what comes out of the effect as the output clip. 

Thus the A.P.I makes multiple assumptions that are not clearly indicated as to which functions a plug-in may call on the output clip and when.

For instance:

- The clipGetImage function on the output clip takes the same parameters as if it were called on a source clip, however in reality this function may only be called during the render action and at the same time that was passed to the action. 

- Some plug-ins (BCC Boris FX) inspect some properties on the output clip during that same action used to compute the property, e.g:

They ask for the kOfxImageEffectPropFrameRate on the output clip during the kOfxImageEffectActionGetClipPreferences action when this is actually this action that is used to compute that value, thus involving triggering either an infinite recursion or an undefined behaviour. 

- We've seen some other plug-ins calling asking for the kOfxImageEffectPropRegionOfDefinition property on the output clip during the 

kOfxImageEffectActionGetRegionOfDefinition itself! Same as above this leads to infinite recursion and undefined behaviour.

Such plug-ins clearly are making mistakes because the A.P.I is not constrained enough. 

Actually in practise we actually notice that plug-ins only make use of the output clip to 

- Fetch the output image

- Fetch properties on the output clip to get informations about the default host implementation if some actions are not implemented  (e.g: kOfxImageEffectPropRegionOfDefinition)

To solve the output image issue:

The image to render could be passed as an inArg of the render action thus consolidating the context into what things a plug-in is allowed to do.

For properties on the output clip, the spec should clearly document what property is relevant on the output clip and when it is allowed to inspect that property.