[Bug 739010] [PLUGIN MOVE] Move GstAggregator to gstreamer (core)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=739010
  GStreamer | gstreamer (core) | git

--- Comment #36 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-12-31 17:20:11 UTC ---
(In reply to comment #34)

> > One thing I'm not so sure about is the GstAggregatorClass::sinkpads_type
> > member: is this really a good idea? And good for bindings? It seems to be only
> > used for creating a pad, why not just make a vfunc for that instead then?
> 
> It should not be an issue for bindings, at least for python. The user can
> already override the request_new_pad vmethod from core and do everything
> himself, it is really just an helper where we handle padname and that kind of
> things.

This GType stuff is always a bit awkward for bindings, I would prefer a vfunc
for it too that allows to use all the magic from GstAggregator to create a pad
but allows the subclass to create a pad itself.

> > It would be good to move the sink pad iteration to core perhaps if we can agree
> > on a reasonable API. I wouldn't mind adding something like
> > gst_iterator_once_foreach_pad / gst_iterator_once_foreach_element (so the
> > callback gets the real type pointer instead of a GValue), for example.
> 
> I agree with that, opening a bug right now.

I think that should be convenience API in GstElement / GstBin, not stuff in
GstIterator. Unless you make it a gst_iterator_foreach_once() that is
independent of the type.

> > Another minor thing I was wondering about: why is gint64 latency from the
> > property in the public structure? I think it should be in the private
> > structure. Nothing uses it and we would have to define access
> 
> No sure, slomo?

No reason, move it. Everything should be moved to the private structures unless
it's actually used by subclasses.

> (In reply to comment #33)
> > And I don't think all of Olivier's comments have been addressed, e.g. what
> > about GAP event support?
> 
> That can be added later fmpov

See Mark's comment. No GAP support and no support for sparse streams would be a
blocker for this to be moved to core.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.