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

Benjamin Otte in7y118 at public.uni-hamburg.de
Thu Dec 25 06:57:01 CET 2003


On Thu, 25 Dec 2003, Ronald Bultje wrote:

> Now imagine two-sided capsnego. Our video window is resized, so we want
> to rescale the video. videosink sets caps on videoscale. videoscale
> first tries to set caps on its sink pad (ffdec_mpeg4), and if that fails
> (avidemux case), it resizes itself, else it uses the new input (v4l2src
> case with a hardware MPEG-4 card), right?
>
Since renego needs caps and caps don't change for different sizes with
mpeg4 (or do they? - optional properties need to die...), it's just not
possible right now.

> The issue is simple: this needs a rewrite of capsnego in all plugins.
> They all need serialized bidirectional capsnego (so on srclink, I need
> to do new try_set_caps or renegotiate on my sink pad, use that result,
> and re-setup everything. On sinklink, I delay src-renego until the next
> cycle so that I know data size). I also need to be prepared for failure
> (filesrc case) and then I need to go back to where I was without losing
> state. This sounds easy in theory, but it's hard to code. It's really
> not easy. We'll have to think this out carefully before we adapt all
> plugins, because if we do it half-right in one plugin, it'll take us
> double the effort to fix it again in a possible second round. Yes,
> indeed: this is non-trivial, especially if we want to do this correctly
> for all plugins. We'll never get this right for 0.8.0, it's impossible.
> We don't have the time or manpower. And don't forget that we're lagging
> badly in documentation, iternationalization, all things that we promised
> to work on in january before Gnome-2.6.
>
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.

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.

> I want to propose to branch off GSTREAMER_0_8 to right before the caps
> branch was merged. We'll develop caps in HEAD/CVS, we'll develop a
> stable Gnome-2.6 version of GStreamer-0.8 and use GStreamer-0.10 (with
> fully implemented new caps system) for Gnome-2.8 or 3.0 (whichever comes
> first), which gives us another half year to fix everything I've
> enumerated above.
>
I always work on the branch that is the future and not a dead end. I'm not
even really interested in backporting fixes. So if you do this, you'll
probably lose me as a developer on the Gnome 2.6 stuff.
Branching is never a good solution - it's just like forking, without that
bad name. We can either decide to drop the caps merge or we can decide to
make it work. And I personally strongly object to the first.

We still have 2 months time to make all this work. 2 months ago we did
have neither navigation nor interfaces nor tags.

Benjamin


PS: I know it sucks when someone merges things that break stuff. (And this
even compiled... :p) But I know the other side of having done the changes
and wanting them in, too.
After every huge merge there's huge breakage. Noone can make a branch
work perfectly on his own. And it's demotivating like hell to work alone
on a branch...





More information about the gstreamer-devel mailing list