[gst-devel] type system (draft2)

[Wim Taymans]

On Sun, 03 Dec 2000 16:36:38 Richard Boulton wrote:
> On Thu, Nov 30, 2000 at 09:29:47PM +0100, Wim Taymans wrote:
> > [snip]
> > Two pads are compatible if:
> > 
> > - The major types are equal
> > - range of the sink pad contains the range of the src pad
> 
> By "contains", do you mean intersects?

Yes

> 
> For example, a sink with a parameter "layer" in range 1,2
> and a src with a parameter "layer" in range 2,3: would they
> be compatible?  If not, then you're preventing things which
> can work from working (can't use these elements to play layer
> 2), but if so you could be causing problems at runtime when 
> a piece of layer 3 data comes along.  If you've built they
> pipeline by autoplugging based on the type system's
> compatibility, there could have been an alternative path
> missed which would have worked even in this case.

They would not be compatible for now. I was thinking about adding
some sort of measurement of compatibility and favour the
elements that more closely match the properties.

We probably need another way to detect if the elements we connected
during autoplugging are in fact compatible with the particular
media stream we are handling. I'm not sure how to do that.

We might attach a signal to those 'might be compatible' pads and 
redo the autoplugging if at runtime they seem to be incompatible
after all.

Luckily, in the immediate future I do not see any element that has
partially overlapping ranges.

> 
> 
> Also, would there be a standard set of parameters which must be
> specified for each particular mime major type? (eg, a pad with
> mime type "audio/mp3" must specify "layer", "bitrate" and
> "framed")  If not, what do you do for defaults?  You could
> either assume that unspecified means "full range possible",
> or that it means "no need to check".

I'm implementing it like this:

property missing in source caps: not compatible (assuming it will output
full range here)
property missing in sink caps: compatible (assuming the sink can handle
the full range)

It looks like the 'full range possible' case might do for now.

The general idea would be:

a sink must accept as much as possible (less properties)
a source must specify its caps as precisely as possible.

but in retrospect that is rather obvious.

> 
> Not sure what the solution to either of these issues is...

We have to try and experiment a bit (I do, anyway) :-)

Wim
> 
> -- 
> Richard
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/gstreamer-devel
> 

-- 
Some men feel that the only thing they owe the woman who marries them
is a grudge.
		-- Helen Rowland