[gst-devel] why is gst_element_class_set_details only for use in base_init function?

Shixin Zeng zeng.shixin at gmail.com
Mon Oct 29 21:09:21 CET 2007


Filed as http://bugzilla.gnome.org/show_bug.cgi?id=491501

On 10/29/07, Stefan Kost <ensonic at hora-obscura.de> wrote:
> Hi,
>
> can you please file a bug about this in http://bugzilla.gnome.org.  I will look
> at this real soon.
>
> Stefan
>
> Shixin Zeng schrieb:
> > Yes, I think I find a case that this happens:
> > GstPipeline is derived from GstBin which is derived from GstElement
> >
> > In GstBin's base_init function:
> > static void
> > gst_bin_base_init (gpointer g_class)
> > {
> >   GstElementClass *gstelement_class = GST_ELEMENT_CLASS (g_class);
> >
> >   gst_element_class_set_details (gstelement_class, &gst_bin_details);
> > }
> >
> > in GstPipeline's base_init function:
> > gst_pipeline_base_init (gpointer g_class)
> > {
> >   GstElementClass *gstelement_class = GST_ELEMENT_CLASS (g_class);
> >
> >   gst_element_class_set_details (gstelement_class, &gst_pipeline_details);
> > }
> >
> > So, during registering the type GstPipeline,
> > gst_element_class_set_details will firstly be call via
> > gst_bin_base_init () and secondly via gst_pipeline_base_init().
> >
> > And there might be some other cases.
> >
> > Actually, there is no other harm doing in base_init() instead of doing
> > in class_init() except for some unnoticeable efficiency loss, as far
> > as I understand.
> >
> > However, I didn't test this, this is just the judgment from my
> > knowledge of GOjbect system. Please correct me if I'm wrong.
> >
> > On 10/26/07, Stefan Kost <ensonic at hora-obscura.de> wrote:
> >> hi,
> >> Shixin Zeng schrieb:
> >>> Hi, all
> >>>
> >>> When I'm trying to write a source element, I read this on the
> >>> documentation of the gst_element_class_set_details. I'm a bit
> >>> confused. As far as I understand, in Gobject system, base_init is used
> >>> for dynamic data member initialization. However, the field "details"
> >>> in GstElementClass is not a dynamic allocated space, so it should be
> >>> initialized in class_init function instead of base_init function.
> >>>
> >>> For example, a class A derived from GstElement, then when class A is
> >>> registered, it will involve:
> >>> 1. Allocate space
> >>> 2. call GstElement's base_init
> >>> 3. call A's base_init, /* it calls gst_element_class_set_details to
> >>> set the field "details" */
> >>> 4. call A's class_init
> >>>
> >>> Now, another B is derived from A, then the sequence will be like:
> >>> 1. Allocate space,
> >>> 2. call A's base_init; /* set field "details" as mentioned above */
> >>> 3. call B's base_init; /* set filed "details" again */
> >>> 4. call B's class_init
> >>>
> >>> So, apparently, "details" was set twice in case of B. However, if we
> >>> call gst_element_class_set_details, this kind of redundancy can be
> >>> avoid. So, any particular reason why this function should be call in
> >>> base_init instead of class_init?
> >>>
> >>> Thanks.
> >> None of the baseclasses call gst_element_class_set_details and we don't subclass
> >> finaly elements currently. Did you found a case where it actually happens twice.
> >> I don't remember it there was technical reason for doing it in base_init
> >> (registry or so). I will investigate.
> >>
> >> Stefan
> >>
> >
> >
>
>


-- 
Best Regards

Shixin Zeng




More information about the gstreamer-devel mailing list