[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 #32 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2014-12-31 12:41:52 UTC ---
Thibault, I don't think I commented on introspectability anywhere? I just added
a dependency on bug #731301 yesterday. I don't think it's going to be a
problem, and I agree there's no point in adding a short-lived typelib in bad
for nothing.

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?

What else needs to be done IMHO:

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.

We should also try to port a muxer over. I started with oggmux yesterday.

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

-- 
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.