Re: gstreamermm option group does not init

[Marcus Brinkmann <marcus brinkmann ruhr-uni-bochum de>]

At Thu, 19 Jun 2008 00:11:16 -0400,
José Alburquerque <jaalburquerque cox net> wrote:
> Marcus Brinkmann wrote:
> > It is my understanding that using the Gst option group together with
> > glib's option parser will automatically cause all necessary
> > initialization in Gst.  This is what the documentation of the
> > get_option_group method says
> 
> I don't think this is exactly right.  Here's what the docs say 
> on get_option_group() <cid:part1.07050600.06080307@cox.net> 
> <cid:part1.07050600.06080307@cox.net>:
> 
>     Returns a Glib::OptionGroup with GStreamer's argument specifications.
> 
>     The group is set up to use standard GOption callbacks, so when using
>     this group in combination with GOption parsing methods, all argument
>     parsing and initialization is automated.
>     ...
> 
> If you read carefully, I think you'll see that the word `initialization' 
> refers to argument initialization and not gstreamermm initialization.  

I respectfully disagree.  I think it is pretty clear that
"initialization" in the gstreamer documentation of
gst_init_get_option_group to mean gstreamer itself.  First, a
clarification:

* It is not gst_init_get_option_group that does the initialization, but the
  actual use of parsing options through this option group.
  Initialization of gstreamer happens implicitely in this case through
  option parsing, which invokes pre and post init hooks.

* The above documentation is cut&pasted from the gstreamer C API, thus
  I will refer to that one only from now on.

Although the documentation could be clearer, please consider the
following facts (for the following analysis, see gstreamer/gst/gst.c):

* The option group returned by gst_init_get_option_group() has init_pre and
  init_post hooks set that take care of necessary initialization
  before and after option parsing.

* gst_init() and gst_init_check() call the pre and the post
  initialization hook.  In fact, they are implemented in terms of
  gst_init_get_option_group().

* After using the option group for option parsing, gst_init() and
  gst_init_check() are a no-op.

* If your interpretation were correct, it would be the application's
  responsibility to call gst_init or gst_init_check along with using
  the option group, but there is no valid sequence in which this can
  happen.  If gst_init(0, NULL) is called before parsing options, the
  options have no effect on the init_post step of gst's
  initialization, which was already completed by gst_init.  If
  gst_init(0, NULL) is called after parsing options, it is a no-op.
  This doesn't work.

* The example program for gst_init_get_option_group that is contained in
  section 4.2 (The GOption interface) the application development
  manual clearly implies that using the option group for argument
  parsing fully initializes gstreamer.  Otherwise, I would expect a
  call to gst_init or some other function in that example program.

  http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/x291.html

Note that although this analysis was done for the C API, some of these
points also apply to gstreamermm.

* Take a typical gstreamer using application, like totem.  In
  totem-2.22.1/src/backend/bacon-video-widget-gst-0.10.c we find:

  /* applications must use exactly one of bacon_video_widget_get_option_group()
   * OR bacon_video_widget_init_backend(), but not both */
   GOptionGroup*
   bacon_video_widget_get_option_group (void)
   {
     return gst_init_get_option_group ();
   }

   void
   bacon_video_widget_init_backend (int *argc, char ***argv)
   {
     gst_init (argc, argv);
   }

> If you look at the same C API docs for gst_init_get_option_group() 
> <http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-Gst.html#gst-init-get-option-group> 
> you'll notice that this function also does not initialize gstreamer for you.

The wording is compatible with both interpretations, but I think it is
a better fit to my interpretation than yours.  Otherwise, it would not
be clear to me what "initialization" is meant in addition to argument
parsing.

> > Note that the C++ program works correctly if I insert a call to
> > Gst::init() with dummy arguments.  I would guess that the wrapper of
> > get_option_group() fails to call an initialization routing of the
> > gstreamermm bindings layer or something.
> 
> No.  Gst::get_option_group() relies on the C API for its functionality, 
> (ie. it simply call gst_init_get_option_group() and returns the 
> GOptionGroup wrapped in a Glib::OptionGroup).  It does nothing more or 
> less than what would be done if its C counterpart is called.

I know that.  The problem is, IMO, that gstreamermm is not extending
the init_pre and/or init_post callback functions of the option group.

I would expect that gstreamermm does provide an option group which
contains or is derived from the gstreamer option group, which does all
necessary initialization, OR that gstreamermm documents how
Gst::get_option_group can be used properly while ending up with a
fully initialized library (For example, by first calling a
hypothetical Gst::init_internal function or whatever, if that is even
possible).

Currently, there is no documented way to use the option group
Gst::get_option_group correctly and ending up with a properly
initialized gstreamermm wrapper.  It *may* be that calling

  int argc_hack = 0;
  char **argv_hack = { 0 };
  Gst::init (argc_hack, argv_hack);

after option parsing using Gst::get_option_group works and initializes
gstreamermm properly, but this includes a useless call to gst_init,
has a quite convoluted syntax (which makes it completely
non-intuitive) and the order matters: If this is called before option
parsing, the gstreamer option parsing does not have the desired effect
on initialization.

> > The core of the complete example I provided is this:
> >
> >   Glib::OptionGroup m_GstOptiongroup = Gst::get_option_group();
> >   m_OptionContext.add_group(m_GstOptiongroup);
> >
> >   Gtk::Main *kit = new Gtk::Main (argc, argv, m_OptionContext);
> >
> > This should implicitely do whatever Gst::init() does as well.  In
> > particular, it should register the type wrappers and what not. 
> 
> No.  None of the C API that the above API wraps would call gst_init() 
> and thus their C++ counterparts should not "initialize" gstreamermm 
> (call Gst::init()) either.  Gst::init() not only initializes the wrapper 
> system, it also initializes gstreamer (by calling gst_init()).  In the C 
> API calling gst_init() would be necessary so Gst::init() takes care of 
> this and initializing the C++ wrapper system also.  A C program can thus 
> be easily translated to C++ by maintaining this consistent parallel.

I think you have a misconception of how gst_init_get_option_group is
supposed to take care of initialization.  It is not the call to that
function which does the necessary initialization, but the init_pre and
init_post hooks contained in the option group at time of option
parsing.

[...]

> I really appreciate your input, but I sincerely must insist on an 
> *actual* equivalent C program to look further into this.  Thanks for 
> your input.

Ok, to make things simple for me and you, please contrast

Section 4.2 of gstreamer 0.10 Application Development Manual

with

examples/optiongroup/main.cc

The first fully initializes gstreamer, while the latter does not
initialize gstreamermm.  I hope this is clear.

Thanks,
Marcus