[gstreamer-bugs] [Bug 396774] Make GstElementDetails extensible

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #22 from Stefan Kost (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> 2010-08-10 13:35:30 UTC ---
(In reply to comment #19)
> Review of attachment 167500 [details]:
> 
> Looks good, two minor things below
> 
> ::: gst/gstelement.c
> @@ +1240,3 @@
> +
> +  if (klass->meta_data) {
> +    GST_DEBUG ("clear metadata in class %p to %p", klass, klass->meta_data);
> 
> So this means, that the metadata of the parent class is overwritten.
> 
> I think for 0.11 we might want to change that, same for the other element
> details. For example for inheriting the classification of the parent class

We could also use GstTaglist a-like merging. Like we copy the parent meta-data
and replace some value with the new ones.

> 
> @@ +1250,3 @@
> +}
> +
> +/* FIXME-0.11: deperate and remove gst_element_class_set_details*() */
> 
> small typo, deprecate ;)

fixed locally.


(In reply to comment #21)
> (In reply to comment #19)
> > Review of attachment 167500 [details] [details]:
> > 
> > Looks good, two minor things below
> > 
> > ::: gst/gstelement.c
> > @@ +1240,3 @@
> > +
> > +  if (klass->meta_data) {
> > +    GST_DEBUG ("clear metadata in class %p to %p", klass, klass->meta_data);
> > 
> > So this means, that the metadata of the parent class is overwritten.
> > 
> > I think for 0.11 we might want to change that, same for the other element
> > details. For example for inheriting the classification of the parent class
> 
> Oh and you might want to enforce the clearing of the metadata in
> GstElement::base_init to get really the same behaviour as for the other element
> details.
> 
> 
> And if we agree that something like your patch should go in, we should first
> define metadata fields and their usage. Otherwise elements might use different
> fields for the same thing...

This could be also done like for GstTaglist. Right now I would just use it for:
<string> help-uri
I was once thinking of a processor field (CPU, GPU, DSP, ...), this way one
could maybe prefer hw-accelerated elements, but thats not really good either.
Any other thoughts?

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