Re: gstreamermm option group does not init

[José Alburquerque <jaalburquerque cox net>]

Marcus Brinkmann wrote:
> 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.  
>   

I don't think this is entirely clear (it could have read '...and 
/gstreamer/ initialization is automated'), but having reviewed the glib 
option parser API, I can see you're reasoning now.

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

I had not understood this.

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

This is all true but having to go through all the source to confirm 
something can sometimes be a bit unproductive.  If you had provided an 
example initially (or mentioned the examples in the GStreamer docs), 
this all could have been confirmed and I would not have doubted you.

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

Yes, this is correct, but, again, providing an example in the first 
place would have been much easier to confirm.

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

They could.  I suppose, as Murray says, we could try to make gstreamermm 
function similarly, but I suspect that the change would have to be made 
outside of gstreamermm because both the gstreamer gst_pre() and 
gst_post() functions are not public.  Maybe we can find a gstreamermm 
specific solution where there would be no conflict in using 
Gst::get_option_group() and using Gst::init(), but as you mentioned, I 
think the docs would have to be very clear about this.

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

Yes.  As I said, I had misunderstood this.

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

I'm sure we'll find a fix somehow.

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

Yes this is correct.  We'll see what we can do.

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

I've also attached a C example that shows that the call to gst_init() is 
not necessary when using the options parser (I had to write it myself, 
since you would not cite or provide one initially).  As can be seen, the 
call to gst_init() is not necessary with option parsing.

--
José Alburquerque
jaalburquerque cox net

#include <gst/gst.h>

int main(int argc, char* argv[])
{
  GOptionContext* context;
  GError* context_error;
  GstElement* element;

  // must initialise the threading system before using any other GLib funtion
  if (!g_thread_supported ())
    g_thread_init (NULL);

  context = g_option_context_new ("- Test GStreamer GOptionGroup parsing");
  g_option_context_add_group (context, gst_init_get_option_group ());
  if (!g_option_context_parse (context, &argc, &argv, &context_error)) {
    g_print ("Error initializing: %s\n", GST_STR_NULL (context_error->message));
    exit (1);
  }

  g_option_context_free (context);

  /* init GStreamer */
  // gst_init(&argc, &argv);

  /* create element */
  element = gst_element_factory_make ("fakesrc", "source");
  if (!element) {
    g_print ("Failed to create element of type 'fakesrc'\n");
    return -1;
  }
  else
    g_print ("Successfully created element of type 'fakesrc'.\n");

  gst_object_unref (GST_OBJECT (element));

  return 0;
}