[gst-devel] caps nego

Ronald Bultje rbultje at ronald.bitfreak.net
Thu Jul 15 10:49:03 CEST 2004


Hi,

On Thu, 15 Jul 2004, Wim Taymans wrote:
> If anyone is objecting, speak
> now :) Above mentioned outline should work as base for the new system,
> it was proven to work better (see previous caps system) than the current
> system and we're even correcting the errors of the old system.
> DirectShow uses a very similar system.

So you're basically saying that the old capsnego system worked better than
the new one? That's completely untrue. The new one just is not perfect.
The old capsnego system did not allow for automated renegotiation; the new
one does. The old capsnego system had many more issues, like too many
allocations required for a GstCaps, overengineered caps referencing,
non-glib types (GST_TYPE_INT, no use of GValue IIRC, ...). The new one
fixes a lot of issues. Not all, but a lot. Note that going back to the old
system breaks anything that is not serial-negotiatable. I believe this
would, amongst others, break automatic resizing of ximagesink when it is
preceeded by a videoscale and the user resizes the video window (or the
player window); this was one of the use cases for which we decided to go
for the new caps system after all. However, there were many more reasons.

What you're looking for is an extension to the current capsnego system
that allows for capsnego forwarding on elements like identity or partial
capsnego forwarding on elements like colorspace for properties like
width/height. Don't redo the system again, because it _will_ have bug
and it _will_ be as imperfect as our current one, although the issues
that it will have will not be the same as now. I said this exact
same thing in january when Dave proposed this and I was right.

Forwarding here means "I am not interested or I am not the preferred
element to fixate on caps at all or to fixate on properties like X and Y".
Demuxers would be preferred highly for fixation, and passthrough elements
would not be preferred at all. Preference is the opposite of forwarding.
Choose whichever term you prefer. Dave proposed this some time ago and it
sounds like a good solution to me. Maybe he even has some code to do this.

Ronald





More information about the gstreamer-devel mailing list