[gst-devel] caps nego

[Thomas Vander Stichele]

I was getting frustrated with my inability to express what doesn't feel
right about the current caps nego system.

I attached the result from gst-launch for three pipelines.

The first one is videotestsrc ! identity ! ffmpegcolorspace ! identity !
xvimagesink.

This is a very easy pipeline, anyone can see that the only ones who
should ever decide about w, h and fps are the src and the sink element,
and both of them implement a fixation function that also try to fixate
to the exact same values for them.

Yet the pipeline ends up fixating to 16x16 at 1 fps.

I *think* I have some understanding of what goes wrong; some links
between elements that have no preference for fixating do not fixate,
hence the core feels it should help in fixating and ends up fixating to
the lowest int value.

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.

Since the whole capsnego system is too complicated for me to understand
currently, I'd like to know if this is an actual flaw in our system, a
bug in plugins, a bug in core, or something else.  I'd also like to know
what can be done to fix it.  The pipelines we use in the server are
slightly more complex, and hence we are forced to bruteforce caps on
every link to actually get somewhere, which is a pain in the ass.

The other examples exhibit different versions of the same problem, with
some of them reporting caps on pads that are bogus then get corrected,
but the end result still ends up wrong.

Any ideas ?


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
"Would you like my advice ?"
"That depends. Will I like it ?"
"Of course you won't ! My advice is based on reality !"
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/