[gst-devel] linking pads (was: wingo gstreamer: gstreamer/ gstreamer/gst/)
ds at schleef.org
Wed Mar 10 12:37:55 CET 2004
On Wed, Mar 10, 2004 at 04:37:35PM +0100, Benjamin Otte wrote:
> Quoting Andy Wingo <wingo at pobox.com>:
> > Their directions are not specified, and they can have incompatible caps.
> > Perhaps we should assert that they not be connected already? This is
> > really a question for the autoplug guys, so do speak up...
> I'd like to have gst_pad_can_link_filtered as a function that I can throw any
> two pads at and see if they can connect without having to think about them any
Keep in mind that it's not possible to properly test whether two pads
can be linked without actually linking them. I've tried to keep that
to a minimum while rewriting caps, but it does happen. Perhaps in
0.9 we can make it even more predictable.
gst_pad_can_link() is used in several places (internally) where it would
nice to have a fast function. pad_can_link() currently isn't very fast,
since it calls pad->getcaps(), which it often recursive and expensive.
There were more important things to think about at the time, but I
realized it would be nice to have multiple layers of can_link(), each
being more expensive than the previous. And (at least right now), they
should be called gst_pad_can_probably_link(), to indicate that the link
could still fail.
> > I think that we should assert that gst_pad_can_link_filtered. Anything
> > else would be a programming error. Note that this function can still
> > fail if calling the linkfuncs doesn't work out.
> This sounds like a very good idea. Just g_assert (gst_pad_can_link_filtered
> ()); and you don't have duplicated code anymore.
Most application code does not check gst_pad_can_link() before linking
pads. It's rather silly to have to check if you can do something
before doing something, when the latter can just as easily return
More information about the gstreamer-devel