gstreamer/docs/random/omega/pad-negotiation

When two pads are connected, a negotiation phase is going to have to
happen.  Ideally, the caps of the two pads will both be fully-specified,
and match.  That's the ideal case, but may rarely happen in practice.

It'll work the following way:

1) gst_pad_connect(pad1,pad2) is called by something
2) pad1's negotiate() method is called, with pad2 as argument
3) negotiate() repeatedly calls pad2's set_caps() method

At some point, the two pads will agree on a set of caps, and proceed by
returning TRUE from negotiate(), at which point gst_pad_connect()
finishes.  If it returns FALSE, gst_pad_connect() is forced to fail.

Now, obviously the algorithm used to find matching caps can get
complicated.  But in some cases it'll be simple.  Ideally, if there is no
negotiate() function for pad1, there'll be a function that will go through
the options and try to make pad1 and pad2 meet in the middle, with no
specific knowledge of what the caps actually mean.

Another detail is deciding which pads are pad1 and pad2.  In the autoplug
case, the code will sometimes know which of the pads have the more
specific caps.  In others, you may not.  Either you can guess, and
possibly lose to having the slower of the two pad's negotiate() methods do
the work, or you might be able to actually guess at which is the most
specific set of caps:

For any given typeid in the union of both pads, look at all properties
  For each property, find the smallest range, assign this a 1.0
    For all other instances of this property, assign relative to 1.0
For each pad1,pad2
  Take the assigned value of every property, and multiply together

Whichever value is lower between pad1 and pad2 is most likely to be the
most specific set of caps.  The trick is implementing the above
efficiently, but on the surface there appear to be more than enough
potential optimizations.