[gst-devel] caps nego

[Wim Taymans]

On Thu, 2004-07-15 at 19:46, Benjamin Otte wrote:
> 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.

I'm not really interested in global pipeline optimisation with
end-to-end optimal formats. Just something that runs, where each element
is able to find a format it can use to talk to the next element.
Although it can be done on a pipeline level when we implement a
convert_to function.

> 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.
> 
Can you give an example? Does it involve feedback loops? I can see how
getting the list of possible types could end in an endless loop when the
element forwards the call.

something like this? :

-----> mixer --> delay -------->
        !          !
        <----------<

I can think of an easy way to solve this, fully negotiate the output pad
but not the feedback pad. We could also mark the pads when their nego
functions are called and stop when we find a marked pad... 


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

That's what we basically do now by using filtered connections. It would
be nice though that when not using filtered connections, the plugins
could manage to negotiate a format all by themselves. 

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

When osssrc requests a list of supported formats on audioconvert,
audioconvert will request the list from osssink, which returns U8.
audioconvert then appends all the formats it can convert from. osssrc
doesn't have to choose, it picks U8 since it's the first on the list
that works. 

> 
> > - 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 :)
> 
First I want to know what specific use cases the current system solves
that are really hard, please provide something concrete. Dave?

> 
> Benjamin
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel