mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-29 21:21:12 +00:00
40 lines
1.9 KiB
Text
40 lines
1.9 KiB
Text
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.
|