| OUTDATED, EARLY IDEA |
| -------------------- |
| |
| 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. |
