[gst-devel] caps nego

[Benjamin Otte]

On Thu, 2004-07-15 at 16:22, Thomas Vander Stichele wrote:

> However, this is a very simple pipeline example that should be fairly
> trivial to fixate.  If our system can't negotiate it correctly, I'd say
> it's a flaw in our system.
>
It is fixated correctly. It's just not fixated ideally. The definition of
ideally however has been up for discussion for quite a long time.
The only thing we know right now is that the current mess doesn't fixate
ideally.

On Thu, 15 Jul 2004, Wim Taymans wrote:

> - negotiation always goes from left to right, ie upstream elements
> initiate the negotiation right before they send the first data buffer.
>
Cyclic pipelines have no "left" or "right", so this approach has been
known to not work for quite some time now.

> - no automatic negotiation, it's not needed. If an element receives a
> buffer without having a required fixed property, it should fire a signal
> so that somebody can fixate the caps.
> - If an element does try_set_caps with some non fixed properties one can
> fire a signal to let the app fixate them, but it's an app issue.
>
That's how it works right now, though it's a clumsy way. You can easily
connect to all pads' fixate functions right now and have full control over
selecting your ideal format.

> - An element always has a default format it uses when there are multiple
> options. ie osssrc negotiates to a user specified default format, same
> for v4lsrc. This should eventually end up in a to-be-written profile
> system.
>
Example:
ossrc ! audioconvert ! osssink
Assume osssrc supports S16 and U8, osssink only support U8. Since the
preferred format for osssrc is S16, it would negotiate to S16, which would
make audioconvert require a transformation, while with U8 it wouldn't have
to.
So your approach seems suboptimal to me, too.

> - no negotiation is needed in the state changes, only at runtime. our
> previous system tried to do automatic negotiation when the intersection
> between the pads was fixed. This is too complicated and too fragile.
> Better make the element set the caps explicitly. It's a few lines of
> code, it's readable and we can all easily debug it when it fails.
>
Might be an interesting idea for 0.9, but won't probably work right now,
since we're API/ABI compatible.

> I'm figuring out if we can adjust the current system to a more sane
> behaviour or if we should redo caps nego (again). We really need to fix
> this asap, I'm thinking in like 2-3 weeks. If anyone is objecting, speak
> now :)
>
If you supply us with a fully working system in two weeks, that has no
issues, is ABI compatible, solves the above mentioned problems and
optionally ensures world peace, feel free to propose it :)


Benjamin