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 <[email protected]> > 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 _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
