[gst-devel] cvs use

[Ronald Bultje]

Hi,

On Mon, 2003-11-03 at 13:57, Benjamin Otte wrote:
> Tags.

Hm, yeah, forgot that one. Commit it, I want to start implementing
metadata in gst-rec. ;).

> Navigation.

Is already in.

> I encourage all of you to present me your architecture ideas of the core
> that fix SMP and replugging in active pipelines.

Well, if you want comments...

Replugging is easy. It needs no core changes. It just needs slight
plugin changes. Most (codec: that's the ones at issue here) plugins
currently do this in their sinkpad link function:

if (!GST_CAPS_FIXED (caps))
  return GST_LINK_DELAYED;

gst_caps_get (caps,
	      "width",     &me->width,
	      "height",    &me->height,
	      "framerate", &me->fps,
	      NULL);
newcaps = GST_CAPS_NEW ("my_caps", "my_mime/type",
			"width",     GST_PROPS_INT (me->width),
			"height",    GST_PROPS_INT (me->height),
			"framerate", GST_PROPS_FLOAT (me->fps),
			NULL);

return gst_pad_try_set_caps (srcpad, newcaps);

This is fine in unidirectional pipelines. It breaks if capsnego is
triggered from the srcpad-side, because there's no handler there. The
template caps is used, and capsnego fails.
That's why all such plugins need a srcpad-link function (which - when
called - directly does gst_pad_try_set_caps() again with the proper
fixed caps), or a srcpad getcaps function (which returns the fixed caps
of the current media stream, so that capsnego takes care of the rest).
Either will fix it. No core changes are needed. I don't care which of
the two is used, I assume the second is cleaner. It's also simple, it's
less than 10 lines of code per plugin:

1 GstCaps *caps;
2 
3 caps = GST_CAPS_NEW ("getcaps_retval", "my_mime/type",
4		       "width",     GST_PROPS_INT (me->width),
5		       "height",    GST_PROPS_INT (me->height),
6		       "framerate", GST_PROPS_FLOAT (me->fps),
7		       NULL);
8
9 return caps;

It's that simple. This works.

What you're probably aiming at is that the core needs a way to cache the
caps of a plugin when a link is broken (for relinking later on). I don't
know if that's a good thing, I personally feel that a getcaps() function
is cleaner from a design-point-of-view - the core is not supposed to
know whether the plugin wants to cache its pad-caps or not. The plugin
caching only applies to a certain amount of plugins (namely the codec
plugins). Colorspace, ffcolorspace and colorspacelcs (they're based on
each other, so this isn't a coincidence. ;) ) already do the above (they
implement the link-function on both pads), and they work fine when
replugging. Link-functions for each pad is probably the best way for
"filter-caps-plugins", so things like a video scaler, a colorspace
converter, an audio scaler, everything where capsnego on the srcpad-side
is the way of setting caps. The getcaps-function solution works best for
codecs, where no filtered caps is needed and the caps is thus always
decided by whatever comes in from the sinkpad-side. Long story, 10 lines
of code per codec. Anyone want to do this? And yes, I've hit this bug
too. However, I'm not fixing it because I have other priorities. Gst-rec
doesn't need this.

Also see bug #113537. It covers all this. :).

As for SMP, I don't the details of our thread issues (I do know how our
threading works, btw), so I don't have any opinion there. I know "we
have issues", but as long as I don't know or don't care ( ;) ) where the
races are, I can't give comments either.

Ronald

PS your mention of "you guys don't know what issues we have here" is not
true: I do know many issues. Note that you're not the only one working
on the core. I work on it too so now and then, but *only* if I find bugs
related to gst-rec or gst-mixer or whatever I'm working on that need
core fixing. In general, the core design is good enough for me, and my
bug is simply a plugin bug. I don't redesign things because I think it's
fun. I know of other bugs, but I'm not fixing them because we don't see
them in our apps yet. I don't have a testcase, do I don't care yet. I'll
fix it when I hit it. Also, I redesign things because I think it's
needed, not just because I'm hitting a single bug in the current design.
If you want to follow development (I'm serious here!), you *need* to
subscribe to gst-cvs. You said you're not. *That* is an issue. 

You're currently (apparently) assuming that you're the only one working
on things. You're not. However, we're not all working on *your* issues.
Really, you have to start seeing this. This is important. Again, please
subscribe to our CVS/Bugzilla lists, we use them a lot.

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