[gstreamer-bugs] [Bug 491501] Reduce usage of base_init in GstElement subclasses

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=491501

  GStreamer | gstreamer (core) | Ver: HEAD CVS

Sebastian Dröge changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #103946|committed                   |none
               Flag|                            |
 Attachment #103949|committed                   |none
               Flag|                            |
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |
   Target Milestone|0.10.18                     |0.11.0




------- Comment #29 from Sebastian Dröge  2008-02-05 14:15 UTC -------
Ok, as showed up after applying the patches there are quite a few elements that
break with these changes. The causes are all ugly hacks but still we should
keep compatibility for this until 0.11.

The problems that showed up are the following (copied from my mail to
gstreamer-devel):

a) The "pango" issue: pango's GstTextOverlay currently has a really ugly
hack to have a pad template in a base class but not in it's subclasses.
It adds the pad template in base_init, but only if the type it is called
with is not GstClockOverlay or GstTimeOverlay. This has the very weird
effect of having a "text_src" pad template in the base class but not in
the subclasses.

I see no way of solving this in a sane way without changing the pango
plugin. IMHO this is a really ugly hack and no documented way of doing
things. Instead the plugin should've been designed to have a
GstPangoOverlay base class without the "text_src" pad template and the
subclasses GstTextOverlay (with the pad template in question) and the
other two classes without it.

If people don't disagree or there are not more cases of this hack I
would say that we can say that this is simply not supported and people
should design their elements properly ;)


b) the "ladspa part I" issue: the ladspa plugin currently creates a
subclass of GstPadTemplate to store some additional information. But
GstElement's base_init "copies" all pad templates by creating a new one
with the same properties. Unfortunately this copy is not ladspa pad
template and doesn't have the special ladspa informations.

The only way to fix this that I currently see is the following: we don't
copy the pad templates in GstElement's base_init but simply take the
same ones as there are already in the base class and increase the
refcount. This has the effect that we must consider instances of
GstPadTemplate immutable, i.e. the properties of it must not be changed
after it was added to a element class.

IMHO we already do this implicitely as
gst_element_class_add_pad_template() takes owernership of the pad
template but I don't know if this is really intended. Oppinions?
I don't know of a single case were a pad template is changed after
adding it (except the replacing which is still supported).

c) the "ladspa part II" issue: the ladspa elements did the following in
the past:

> GstPadTemplate *tmpl = gst_pad_template_new(...);
> ...
> gst_element_class_add_pad_template (klass, tmpl);
> gst_object_unref (tmpl);

In the past this caused no problems as, although the pad template
addition took the ownership of the pad template it was referenced a
second time. Now it isn't anymore and this causes the pad template to be
freed far too early. People always told me to not ever unref the pad
templates after adding it to an element and the semantics already were
like this since forever so it'd say this is a bug in the elements and
should be fixed there (and already was for ladspa in CVS).
I see no way of fixing this in core as we would leak all pad templates
that are not unreferenced after adding.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=491501.