[Bug 698927] LADSPA improved port to gstreamer 1.0

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Apr 29 17:52:36 PDT 2013


https://bugzilla.gnome.org/show_bug.cgi?id=698927
  GStreamer | gst-plugins-bad | git

--- Comment #4 from Juan Manuel Borges Caño <juanmabcmail at gmail.com> 2013-04-30 00:52:27 UTC ---
Created an attachment (id=242875)
 View: https://bugzilla.gnome.org/attachment.cgi?id=242875
 Review: https://bugzilla.gnome.org/review?bug=698927&attachment=242875

_get_type problems and corrrect derivation

First of all, the patch is very trivial despite the quantity of lines modified,
like 3 batch substitutions for rename collision, real, like 9 line
modifications. Anyway, still better to look at the result that at the patch.
Hoping it works, btw.

Weird, cause here this was not giving it, i indeed find it weird anyway that
the _get_type was not needed, so reported my tests, some theory indicates that
they should be provided, i don't know what kind of cache issue (even on
reboot?) or thing is going on to work here in my 1.0.6 build tests. Anyway as
soon as i tried to derive more theorethically correctly from the GstLADSPA*
classes and not hook directly, your error was exactly happening. While trying
to G_DEFINE_ABSTRACT, a name collision is happening, hence this _instance_ fix
everywhere, also the clean of the interface exposed since is never needed, and
allows now to G_DEFINE_ABSTRACT_TYPE with it's corresponding _get_type. Here is
a picture of the new, i think better, graph:

GObject
 +----GInitiallyUnowned
       +----GstObject
             +----GstElement
                   +----GstBaseSrc
                         +----GstLADSPASource
                               +----ladspasrc-caps-so-click

I've been said that if the class itself does not have an implementation, it
could be an interface, i would have to research about that, but i would like to
notice it for future (FIXME potential). I still does not control interfaces but
having data et all is perhaps not good candidate for interface, and the current
approach is then the better and good in my opinion.

The move of gstmyutils to gstladspautils is not in my opinion really good, if
you take a look at gstladspautils, *all* the functions take a GtsLADSPA or
GtsLADSPAClass as parameter, this is so that a gstlv2utils would mimic this
behaviour, the gstmyutils would remain intact. In fact, gstmyutils is a
suggestion to gstreamer base api itself, as it is direclty interfacing with
basesrc, audiofilter and basesink, and are so generic, perhaps makes sense to
move them there. Anyway, this could move if it causes such a trouble  (which
doesn't to me).

I use/require the type module because the classes *does allocate (and need
currently to) some stuff*, that stuff needs to be deallocated, i noticed that
class_finalize though correctly defined never was getting called, hence i moved
to a typemodule. I fail to understand how when you say gstreamer never unload
plugins memory would remain in good state in this case. Else we could go to the
register_static old style, though i never faced a malloc's, without free's
approach. Here you are the knowledgeable.

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


More information about the gstreamer-bugs mailing list