[gst-devel] Linking pads in 0.9

[Wim Taymans]

On Wed, 2005-04-27 at 16:10 -0700, David Schleef wrote:
> We need to make a collective decision about how pads work while
> linking in 0.9.  Two choices:
> 
>  1) Linking succeeds or fails based only on the pad template
>     caps.
> 
>  2) Linking succeeds of fails based on the current caps of the
>     pad.
> 
> The benefit of doing 1) is that linking 2 particular elements
> will always have the same result, independent of the state or
> what else the elements are connected to.  The downside is that
> any two elements can be connected merely by putting an identity
> between them.

I'd rather make the linking use all the available information for 
deciding if the link can succeed. This helps greatly for autoplugging
and for any other practical purpose in a running pipeline. the
downside is a potential O(n^2) operation as the getcaps function
can potentially call the getcaps of the peer pad(s).

Also, the pad template is mostly used to describe possible pads on 
elements and aid in choosing the right element when autoplugging.
After a real pad is created from the template, the pad caps are the
only means of getting capabilities of the pad. We currently have a
link to the template in the pad because it helps in detecting errors
when some element tries to set something incompatible with the 
template caps, but that is merely for debugging purposes.

It is also possible for pad to not have been created from a padtemplate,
when they are internal to an element and thus don't need to expose a
template. In these cases the linking cannot be checked sanely if
only use pad templates (but it can with getcaps).

> 
> The benefit of doing 2) is that applications find out sooner
> if they contructed an unnegotiable pipeline.  They will still
> need to check if negotiation failed for some other reason.  The
> downside of 2) is that there is additional bookkeeping that
> needs to take place during the _linking_ step.
> 
> The last point may need a bit of explanation -- in 1), the core
> uses existing information (template caps) only.  In 2), it is
> required to keep each element updated with the equivalent of
> 0.8's getcaps() information.  In 0.8, this causes the O(n^2)
> negotiation issues with large numbers of elements in a pipeline.
> Hopefully the O(n^2) issue can be mitigated somewhat -- adding
> N identities can easily be O(n), but worst case is still O(n^2).
> When done all at once for an entire pipeline, negotiation should
> be O(n).

> 
> I'm strongly leaning toward 1), since 2) only provides limited
> information at an expensive price.  Moreover, 2) requires app
> developers to check twice if negotiation failed, once during
> linking and again via a callback.

er, 1) provides limited information, a link can succeed while at
runtime it can fail again, the app developer needs to check twice,
even in a running pipeline. For 2) in a running pipeline there is 
more information and if the link succeeds there is a high chance that
the pipeline can further negotiate and run correctly. 

I'm strongly leaning towards taking the expensive price to ease
autoplugging, and I don't say that very often :)

Alternatives would be for the developer to call getcaps explicitly
before linking, or make a lightweight link function that only does
1). 

Wim
> 
> 
> 
> dave...
> 
-- 
Wim Taymans <wim at fluendo.com>