[gst-devel] caps nego

Andy Wingo wingo at pobox.com
Sat Jul 17 01:55:15 CEST 2004


Hey Wim,

Long time. Good to see you on the lists again. When are you vacationing
in Africa? :-)

On Thu, 2004-07-15 at 18:15 +0200, Wim Taymans wrote:
> I'm wasting 70% time on capsnego issues, so there is something wrong.

I find that this is the case now, but recalling to the past, I don't
notice the difference. Capsnego has always been hard.

An uncharitable view would hold that capsnego has always sucked.

I have no preference for the existing system. I feel like I understand
it mathematically better than the old system (i.e., in terms of graph
traversals, sets, etc.) but I don't know that it is *the* system.

For the record, in soundscrape I currently filter all connections. It
shouldn't be necessary, but it is, right now at least.

> - negotiation always goes from left to right, ie upstream elements 
> initiate the negotiation right before they send the first data buffer.
> the element does:

RE: Bejamin's comment, left and right do have a meaning. Perhaps if we
recast them in the guise of "terminal sink" and "terminal src" they will
make more sense. See sort_chain in gstoptscheduler.c for a formal
definition. There is still arbitrariness there, but is it specified in
the algorithm.

> - 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.

How can an element receive a buffer without knowing what kind of
information it has? Perhaps you are speaking of a scheduler level (like
the invented DISCONT engaging events) that elements don't see?

> - 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.

This is an interesting statement. It proposes a language on top of the
simple fixating system. I think this is worthwhile as a default fixating
behaviour, FWIW.

> - a caps doesn't have to be fixed for dataflow to be possible. see
> filesrc. When nobody cares about the format we're not going to waste CPU
> cycles on it.

How do you define "when nobody cares about it"? I'm with you for not
wasting time on capsnego, but when can you prove it's not necessary?

> - no negotiation is needed in the state changes, only at runtime.

You can control state changes, but you can't control running besides
iteration. Meaning, you can force capsnego without any effect on the
output by setting the state to PLAYING, but if you switch to purely
runtime capsnego, we might break any hope of rt-safety. (Don't get
angry, Dave :)

> 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.

Hmm? Please explain.

> > we are forced to bruteforce caps on every link to actually get
> > somewhere, which is a pain in the ass.

This points to a fixation problem. Perhaps the "default format" offered
by wim could solve this?

Cheers,
-- 
Andy Wingo <wingo at pobox.com>
http://ambient.2y.net/wingo/




More information about the gstreamer-devel mailing list