[gst-devel] Ghost pads

[Erik Walthinsen]

I've got some ideas as to how ghost pads should work, but they are still a
little fuzzy.  I'll describe what I've got, and people can comment.

The idea of a ghostpad is to allow a Bin to expose the pads of its
children.  This allows the Bin to be transparently treated like any other
Element (though we need to have argument proxying for this to be complete,
but that's a lot easier to do).

This goal is also a hard requirement to satisfy.  The current method is
pretty simplistic, it simply adds the pad to the main list.  It adds
itself to the pad's list of ghost parents, so it can be found later.  
This makes it easy to find the ghost pads, but breaks one major assertion:
there cannot be two pads with the same name in the pad list.

One option would be to use modified names, in the form of element.pad.  
This has all sorts of problems, since the name of the element is then
required in order to get things to work.  This is ugly, really...

The ideal solution would allow us to set the names of each of the ghost
pads independently from the actual pad's name.  This would let
meta-elements and such to expose whatever names they wish, without
revealing/exposing their innards.

At first glance, one might think that adding a second type of pad object
would cause massive slowdown in the data path, since things would have to
keep checking whether it's a real pad or a ghost pad.  In fact, this isn't
true at all.  The data path doesn't change one bit.  This is because the
ghost pads are entirely fictional, and only exist as connection
points.  The actual data flow and scheduling occurs only on real pads, and
never *cares* about the ghost pads.

This means that we can simply create a ghostpad object (not derived from
GstPad, there's no point) and use that as a proxy for real pads.  When you
add a real pad to an element as a ghost pad, it would create one of these
ghostpad objects and add it to the Bin's list of pads.  Any queries done
on this ghostpad would be dealt with by proxying, and the scheduling code
would simply not care.

I think this is the most correct, if not entirely cleanest, method
possible.  It leaves the data path untouched (the scheduler only looks at
real pads, by definition, so it never sees the ghostpads), yet provides
the application with a completely seamless view of the system.

A test I'd like to pass is as follows:

Given two Elements, it should be impossible to tell which of the two is a
meta-element, except by checking to see if it's a GstBin as well.  That
means all external interfaces (pads, arguments, etc.) should look and act
identically.

I think this ghostpad setup will do that.

Comments?

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_