Re: Building GStreamermm with GStreamer 1.0

[José Alburquerque <jaalburquerque gmail com>]

Unfortunately, I just don't have time to get a release out.  I have made
some changes in git that allow the plug-in generation and the general
gmmproc generation process to succeed and continue on to the build, but
I've not made the build successful thenceforth.

I did look into having Gst::init() preload the plugins via a flag but
found that it is probably not necessary because I think the problem with
the code that I saw that requires preloading plugins is in using a
dynamic cast instead of a static cast which would be the right cast to
use.  Gst::init() can be modified anyway, but I'm not sure it's worth
it.

I did add the appsrc and appsink plug-ins also, but there is quite some
more to be done to get a release out.

If you'd like, you can still submit patches via bugzilla because there
are other maintainers that can review your patches.  I just wont be able
to because of lack of time.  Maybe you can help in getting a release
out.

If you have questions, there are people on this list (particularly the
other maintainer, Murray) who should be able to answer your questions.
Good luck.

-- 
José

On Thu, 2013-06-13 at 11:31 +0200, Dirk Van Haerenborgh wrote:
> Ok, I'll start submitting patches to bugzilla whenever there's a first
> version for gstreamer 1.0
>
>
> Also, I guess the init function would not take that long anymore,
> since the gst registry is now stored in binary format, which,
> presumably, should be much faster to parse...
>
>
> And, just to set the record straight: that code isn't mine, it just
> happened to be what I was looking for.
>
>
>
> Cheers,
> -Dirk
>
>
> On 12 June 2013 01:43, José Alburquerque <jaalburquerque gmail com>
> wrote:
>         On Mon, 2013-06-10 at 14:33 +0200, Dirk Van Haerenborgh wrote:
>         > Hi,
>         >
>         > That sounds great. I'll check back in a few weeks then.
>         > Btw, would the patch in [1] meet the design requirements of
>         > gstreamermm? If so, I'll try to implement this after you
>         finish
>         > porting.
>         
>         
>         First, the changes to the .hg and .ccg files are better dealt
>         with as
>         git patches submitted in bugzilla.  It is easier to look at
>         the changes
>         there, discuss them and decide whether they should be included
>         (with or
>         without changes) or not.
>         
>         As far as the addition of the appsink and appsrc plug-ins I
>         think these
>         will probably be included in the upcoming release.
>         
>         Your test code seems to include calls to the get_type() method
>         of the
>         plug-ins so that the casting of plug-ins created with
>         Gst::ElementFactory::create_element() works.  This was not
>         necessary
>         some time ago, but to speed gstreamermm startup time up
>         plug-in
>         registration was disabled at gstreamermm initialization (see
>         [1][2]).
>         It may be possible to include a flag in the Gst::init()
>         methods
>         signaling that plug-in registration is desired so calling the
>         get_type()
>         methods manually would not be necessary in these cases.  I'll
>         look into
>         this.
>         
>         [1]
>         http://lists.freedesktop.org/archives/gstreamer-devel/2012-September/037199.html
>         [2]
>         https://git.gnome.org/browse/gstreamermm/commit/?id=648b89f5fe715c7c96a5824df999e9f2acb6f220
>         
>         As far as implementing plug-ins in C++ (ie. maybe deriving
>         from a class
>         like PushSrc), ideally there would be no C code at all.  I
>         think that's
>         what gstreamermm would strive for.
>         
>         > Cheers,
>         > -Dirk
>         >
>         >
>         > [1]: https://github.com/peper0/gstreamermm-plugins