gstreamermm progress



I'm sort of realizing that gstreamermm is sort of moving a bit along so I thought I might ask a few questions about objects not wrapped just to make sure my understanding is fine (or if it needs to be corrected).  >From what I've assessed,  properties, signals and vfunctions need to be checked and docs need to be "perfected" (I can do some this as the work moves along).  Also a method check is needed (I'm waiting until everything is wrapped to do this).

This week I intend to finish up GstTask, look at GstSegment, and seriously look at GstIterator (unless others think something else is more important).  I also want to finish writing tests for Gst::Caps and Gst::Structure.  I'm thinking that it may be necessary to implement a Glib::Value<Fraction> type for cases in which a fraction needs to be stored in a Gst::Caps using the set_simple() method.   For example, the following C code (taken from section 8.3.2 of the GADM Application), where a fraction is stored in the caps, might need to be "implementable" in C++:
  GstCaps *caps;

  caps = gst_caps_new_simple ("video/x-raw-yuv",
  	      "format", GST_TYPE_FOURCC, GST_MAKE_FOURCC ('I', '4', '2', '0'),
	      "width", G_TYPE_INT, 384,
	      "height", G_TYPE_INT, 288,
	      "framerate", GST_TYPE_FRACTION, 25, 1,
	      NULL);
The values are store in a GstStructure belonging to the Gst::Caps, so our Gst::Structure might need some sort of set_fraction() method while the Gst::Caps::set_simple() might need to be able to handle some sort of Glib::Value<Fraction> type.

My actual question for now, though, is what should I do about the following objects which have not been wrapped (or are incomplete)?

1) 
GstGhostPad -- Its parent class GstProxyPad is declared in a *.c file (gstghostpad.c) and thus makes it difficult to be included in the *.hg file.  I imagine this can be fixed by moving the declarations to the *.h file (submitting a patch to gstreamer), but I wonder if they have their reasons for this.
2)
GstImplementsInterface -- I'm not sure whether this should be wrapped.
3)
GstRegistry -- Same as #2
4) 
GstPlugin -- The *GstPluginInitFunc function pointer type does not accept user data so a slot cannot be passed in to the C++ callback.
5) GstTagList -- Same as #4 for the function pointer *GstTagMergeFunc pointer (it doesn't accept user data) .  I've developed a patch for this but I'm not sure that it will be accepted by gstreamer (I can it provide it to be reviewed if necessary)

There's plenty to do so there is no rush, but some input would be useful some time about the above.  Thanks.

-Jose



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]