Re: gstreamermm option group does not init

[Murray Cumming <murrayc murrayc com>]

On Thu, 2008-06-19 at 12:48 +0200, 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.

Does gstreamer require any initialization? For instance, do you need to
call any init() function when not using GOption? If not, then it's
unlikely that the documentation means this.

Note that we probably can hook into the GOption stuff if necessary.

>   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
> 
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com