Gnome-2.6, GStreamer-0.8 and caps [was: Re: [gst-devel] more caps]

[Ronald Bultje]

hi,

On Thu, 2003-12-25 at 15:56, Benjamin Otte wrote:
> We got into this problem the moment we allowed Julien to use reverse caps
> nego. From that moment on _every_ plugin needed to support it. That's not
> a caps issue. The caps merge only made this huge bug more visible.

I know. I didn't say my solution was perfect. I just said the current
situation is even worse than compared to what we had. Stuff worked, even
though it wasn't as perfect as it could be (or 'broken' as some of us
called it). Currently, stuff doesn't work at all.

> A short fix might be to make try_set_caps set the (now unused) pad->caps
> value and give every pad (or only every src pad?) a default link function
> that does this:
> {
>   guint ret;
>   GstCaps *intersect;
> 
>   if (!pad->caps)
>     return GST_PAD_LINK_DELAYED;
>   intersect = gst_caps_intersect (pad->caps, caps);
>   if (!gst_caps_is_empty (intersect))
>     ret = GST_PAD_LINK_OK;
>   else
>     ret = GST_PAD_LINK_REFUSED;
>   gst_caps_free (intersect);
>   return ret;
> }
> which should essentially make caps nego work just like before.
> And then we can focus on implementing this stuff correctly.

This specific thing! But this is not the only issue.
* many elements use GST_PAD_CAPS() - they all don't work
* gst_pad_try_set_caps() on an unlinked pad doesn't cache - many
elements use this - they all don't work
* caps are fixated before calling link functions. They link as soon as
they can with these fixated caps. This means that they have completed
capsnego before the previous element set caps on it. Every element
depending on this doesn't work.
* probably more reasons that I didn't track yet, I only tested 3
elements so far.

Don't get me wrong: this caps system is cool. But *all* our elements
need fixage right now. *That's* what I'm affraid of. Most of our
elements used to work. Sure, not all (ffmpeg ;) ), but we could play
back most common video formats by now, most common audio formats, etc.
These are not compile failure, these are runtime failure, they're hard
to track down and solve. It's not as obvious as you'd wish.

*All* of this needs re-testing now. We're two weeks before the Gnome-2.6
feature freeze and suddenly, we have to start testing each and every
combination of plugins again, after having fixed each of them.

*That's* what I'm affraid of.

And every day that our CVS doesn't work, all our app (as opposed to
core) developers will lose a day of their precious time.

If you're affraid of a dev.split if we branch, then I could as well
propose to reverse the patch and continue developing it in the CAPS
branch until all of the above issues are fixed. I choose to propose to
branch off 0.8 because I know Dave will kill me if I 'send him back' to
his own branch. Sure I know it sucks. It's just *a* proposed solution,
not *the* solution. There *is* no *the* solution right now. If others
know a better solution, go ahead. But we've been broken for four days
now, that's too much already. We'll be broken for another four days or
weeks, if we don't watch out.

I'm just saying that I don't think our current situation is very
positive.

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>
Linux Video/Multimedia developer