[v 0.10] Gst::init() is slow
Locked
 
|
Hi,
Gst::init() takes like 100+ ms, on rare occasions it takes even longer, like over 2-4 seconds. Is it normal? To combat this I do Gst::init() in another pthread for my gui app to show up instantly as usually. Using Ubuntu 12.04 amd64. Intel Core i5. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [v 0.10] Gst::init() is slow
|
|
On 2012-09-08 12:19, Jiergir Ogoerg wrote:
> Hi, > Gst::init() takes like 100+ ms, on rare occasions it takes even longer, > like over 2-4 seconds. Is it normal? > > To combat this I do Gst::init() in another pthread for my gui app to > show up instantly as usually. > > Using Ubuntu 12.04 amd64. > Intel Core i5. > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > Perhaps it is regenerating the registry every time for some reason? Registry regeneration is the only reason I have ever encountered. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [v 0.10] Gst::init() is slow
|
|
In reply to this post by Jiergir Ogoerg
On Sat, 2012-09-08 at 13:19 +0300, Jiergir Ogoerg wrote:
> Hi, > Gst::init() takes like 100+ ms, on rare occasions it takes even > longer, like over 2-4 seconds. Is it normal? Probably. The reason is that Gst::init() not only initializes GStreamer, it also initializes glibmm (which it relies on) and registers methods that wrap C types to correct C++ types for all the GStreamer GObject and GstMiniObject derived types and all the GStreamer plug-in types that gstreamermm makes available to be used in a C++ way. In the process, it must load all the plug-ins that gstreamermm makes available (this is probably the most time consuming part though only for the execution for which the plug-ins have not been loaded; the rest of the executions wont experience so much a delay). We know of no other way to ensure that the C objects handled are correctly differentiated and treated as appropriate C++ classes. > > To combat this I do Gst::init() in another pthread for my gui app to > show up instantly as usually. > > Using Ubuntu 12.04 amd64. > Intel Core i5. > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel -- José _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [v 0.10] Gst::init() is slow
|
|
Thanks,
To my desktop app startup time is critical, so, if I switch to the Gst C interface do you think the gst_init() would never take longer than say 200 milliseconds? Or is it nonetheless possible for it to take much longer like over 1-2 seconds in some cases? On Sun, Sep 9, 2012 at 7:37 AM, José Alburquerque <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [v 0.10] Gst::init() is slow
|
|
On Sun, 2012-09-09 at 09:46 +0300, Jiergir Ogoerg wrote:
> Thanks, > To my desktop app startup time is critical, so, if I switch to the Gst > C interface do you think the gst_init() would never take longer than > say 200 milliseconds? Or is it nonetheless possible for it to take > much longer like over 1-2 seconds in some cases? Actually, I think I spoke too soon in my last post. I was just thinking things through more thoroughly and since plug-in types are not accessible in C. It may be possible to register the wrapping functions for these plug-in types later (when they are constructed) and not at startup (in Gst::init()) since it is not possible to have these plug-in types from some C code and then try to wrap them in a C++ wrapper which is why we go through the process of loading the plug-ins and registering the wrapping functions in the first place. It may not even be necessary to register wrapping functions for these plug-in types. If the above is so, startup time (Gst::init()) will probably never be more than the 100ms you mentioned. I'll be looking into this this week at the end of which a new release should be out. If it this is doable, I'll include it in that release. In the meanwhile, however, I'm sure that using C will never have such a slow start-up time. gst_init() does not load all the possible plug-ins as gstreamermm does right now. > > > On Sun, Sep 9, 2012 at 7:37 AM, José Alburquerque > <[hidden email]> wrote: > On Sat, 2012-09-08 at 13:19 +0300, Jiergir Ogoerg wrote: > > Hi, > > Gst::init() takes like 100+ ms, on rare occasions it takes > even > > longer, like over 2-4 seconds. Is it normal? > > > Probably. The reason is that Gst::init() not only initializes > GStreamer, it also initializes glibmm (which it relies on) and > registers > methods that wrap C types to correct C++ types for all the > GStreamer > GObject and GstMiniObject derived types and all the GStreamer > plug-in > types that gstreamermm makes available to be used in a C++ > way. In the > process, it must load all the plug-ins that gstreamermm makes > available > (this is probably the most time consuming part though only for > the > execution for which the plug-ins have not been loaded; the > rest of the > executions wont experience so much a delay). We know of no > other way to > ensure that the C objects handled are correctly differentiated > and > treated as appropriate C++ classes. > > > > > To combat this I do Gst::init() in another pthread for my > gui app to > > show up instantly as usually. > > > > Using Ubuntu 12.04 amd64. > > Intel Core i5. > > > _______________________________________________ > > gstreamer-devel mailing list > > [hidden email] > > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > -- > José > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel -- José _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [v 0.10] Gst::init() is slow
|
|
Thanks a lot.
On Sun, Sep 9, 2012 at 11:19 AM, José Alburquerque <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [v 0.10] Gst::init() is slow
|
|
In reply to this post by José Alburquerque-3
On Sep 9, 2012, at 4:19 AM, José Alburquerque <[hidden email]> wrote:
> On Sun, 2012-09-09 at 09:46 +0300, Jiergir Ogoerg wrote: >> Thanks, >> To my desktop app startup time is critical, so, if I switch to the Gst >> C interface do you think the gst_init() would never take longer than >> say 200 milliseconds? Or is it nonetheless possible for it to take >> much longer like over 1-2 seconds in some cases? > > Actually, I think I spoke too soon in my last post. > > I was just thinking things through more thoroughly and since plug-in > types are not accessible in C. It may be possible to register the > wrapping functions for these plug-in types later (when they are > constructed) and not at startup (in Gst::init()) since it is not > possible to have these plug-in types from some C code and then try to > wrap them in a C++ wrapper which is why we go through the process of > loading the plug-ins and registering the wrapping functions in the first > place. It may not even be necessary to register wrapping functions for > these plug-in types. Sorry, I'm just wrong here. Though the C types are not available, having one from C code is possible because the plug-ins are created using the GType system. Registering the wrapping functions for plug-ins is thus still vital upon initialization. You're better off using C. I hope I didn't give you false hopes. -Jose > > If the above is so, startup time (Gst::init()) will probably never be > more than the 100ms you mentioned. > > I'll be looking into this this week at the end of which a new release > should be out. If it this is doable, I'll include it in that release. > > In the meanwhile, however, I'm sure that using C will never have such a > slow start-up time. gst_init() does not load all the possible plug-ins > as gstreamermm does right now. >> >> >> On Sun, Sep 9, 2012 at 7:37 AM, José Alburquerque >> <[hidden email]> wrote: >> On Sat, 2012-09-08 at 13:19 +0300, Jiergir Ogoerg wrote: >>> Hi, >>> Gst::init() takes like 100+ ms, on rare occasions it takes >> even >>> longer, like over 2-4 seconds. Is it normal? >> >> >> Probably. The reason is that Gst::init() not only initializes >> GStreamer, it also initializes glibmm (which it relies on) and >> registers >> methods that wrap C types to correct C++ types for all the >> GStreamer >> GObject and GstMiniObject derived types and all the GStreamer >> plug-in >> types that gstreamermm makes available to be used in a C++ >> way. In the >> process, it must load all the plug-ins that gstreamermm makes >> available >> (this is probably the most time consuming part though only for >> the >> execution for which the plug-ins have not been loaded; the >> rest of the >> executions wont experience so much a delay). We know of no >> other way to >> ensure that the C objects handled are correctly differentiated >> and >> treated as appropriate C++ classes. >> >>> >>> To combat this I do Gst::init() in another pthread for my >> gui app to >>> show up instantly as usually. >>> >>> Using Ubuntu 12.04 amd64. >>> Intel Core i5. >> >>> _______________________________________________ >>> gstreamer-devel mailing list >>> [hidden email] >>> >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> >> >> -- >> José >> >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> >> >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > -- > José > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [v 0.10] Gst::init() is slow
|
|
On Sun, 2012-09-09 at 07:01 -0400, José Alburquerque wrote:
> On Sep 9, 2012, at 4:19 AM, José Alburquerque <[hidden email]> wrote: > > > On Sun, 2012-09-09 at 09:46 +0300, Jiergir Ogoerg wrote: > >> Thanks, > >> To my desktop app startup time is critical, so, if I switch to the Gst > >> C interface do you think the gst_init() would never take longer than > >> say 200 milliseconds? Or is it nonetheless possible for it to take > >> much longer like over 1-2 seconds in some cases? > > > > Actually, I think I spoke too soon in my last post. > > > > I was just thinking things through more thoroughly and since plug-in > > types are not accessible in C. It may be possible to register the > > wrapping functions for these plug-in types later (when they are > > constructed) and not at startup (in Gst::init()) since it is not > > possible to have these plug-in types from some C code and then try to > > wrap them in a C++ wrapper which is why we go through the process of > > loading the plug-ins and registering the wrapping functions in the first > > place. It may not even be necessary to register wrapping functions for > > these plug-in types. > > Sorry, I'm just wrong here. Though the C types are not available, having one from C code is possible because the plug-ins are created using the GType system. Registering the wrapping functions for plug-ins is thus still vital upon initialization. > > You're better off using C. I hope I didn't give you false hopes. Okay. I'm going back and forth because the issue is more complicated than what I thought. Could you please ignore this last post. I'll look at this during the week and not rush. If it's possible it will be in the release. If not it wont. Sorry. > > -Jose > > > > > If the above is so, startup time (Gst::init()) will probably never be > > more than the 100ms you mentioned. > > > > I'll be looking into this this week at the end of which a new release > > should be out. If it this is doable, I'll include it in that release. > > > > In the meanwhile, however, I'm sure that using C will never have such a > > slow start-up time. gst_init() does not load all the possible plug-ins > > as gstreamermm does right now. > >> > >> > >> On Sun, Sep 9, 2012 at 7:37 AM, José Alburquerque > >> <[hidden email]> wrote: > >> On Sat, 2012-09-08 at 13:19 +0300, Jiergir Ogoerg wrote: > >>> Hi, > >>> Gst::init() takes like 100+ ms, on rare occasions it takes > >> even > >>> longer, like over 2-4 seconds. Is it normal? > >> > >> > >> Probably. The reason is that Gst::init() not only initializes > >> GStreamer, it also initializes glibmm (which it relies on) and > >> registers > >> methods that wrap C types to correct C++ types for all the > >> GStreamer > >> GObject and GstMiniObject derived types and all the GStreamer > >> plug-in > >> types that gstreamermm makes available to be used in a C++ > >> way. In the > >> process, it must load all the plug-ins that gstreamermm makes > >> available > >> (this is probably the most time consuming part though only for > >> the > >> execution for which the plug-ins have not been loaded; the > >> rest of the > >> executions wont experience so much a delay). We know of no > >> other way to > >> ensure that the C objects handled are correctly differentiated > >> and > >> treated as appropriate C++ classes. > >> > >>> > >>> To combat this I do Gst::init() in another pthread for my > >> gui app to > >>> show up instantly as usually. > >>> > >>> Using Ubuntu 12.04 amd64. > >>> Intel Core i5. > >> > >>> _______________________________________________ > >>> gstreamer-devel mailing list > >>> [hidden email] > >>> > >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > >> > >> > >> -- > >> José > >> > >> _______________________________________________ > >> gstreamer-devel mailing list > >> [hidden email] > >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > >> > >> > >> _______________________________________________ > >> gstreamer-devel mailing list > >> [hidden email] > >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > > -- > > José > > > > _______________________________________________ > > gstreamer-devel mailing list > > [hidden email] > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel -- José _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [v 0.10] Gst::init() is slow
|
|
Alright, thanks, I understand that it's a complex issue.
On Sun, Sep 9, 2012 at 2:31 PM, José Alburquerque <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [v 0.10] Gst::init() is slow
|
Administrator
|
In reply to this post by Jiergir Ogoerg
Hi,
Have you tried creating a minimalistic C++ application which just calls Gst::init() , run it under valgrind --tool=callgrind, and then see in kcachegrind what's actually taking up that much time ? If you're on desktop (which seems to be the case considering the rest of the thread), gst_init (the C version) shouldn't take up that much time (takes <50ms on a more-or-less modern system depending on the number of plugins you have installed). There is room for improvement, but it won't happen easily. Edward On Sat, 2012-09-08 at 13:19 +0300, Jiergir Ogoerg wrote: > Hi, > Gst::init() takes like 100+ ms, on rare occasions it takes even > longer, like over 2-4 seconds. Is it normal? > > To combat this I do Gst::init() in another pthread for my gui app to > show up instantly as usually. > > Using Ubuntu 12.04 amd64. > Intel Core i5. > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [v 0.10] Gst::init() is slow
|
|
// compile with: // c++ gst.cpp -o gst `pkg-config --cflags --libs gtkmm-3.0 gstreamermm-0.10` class Example : public Gtk::Window { public: Example() : gst_loaded_(false) { Glib::signal_idle().connect(sigc::mem_fun(*this, &Example::load_gst)); } private: bool load_gst() { Gst::init(); std::cout << "Finished loading gst!" << std::endl; gst_loaded_ = true;· return false; } bool gst_loaded_; }; int main(int argc, char **argv) { Glib::RefPtr<Gtk::Application> app = Gtk::Application::create(argc, argv, "org.gtkmm.example"); Example example; app->run(example); return 0; } -- Tristan Matthews web: http://tristanswork.blogspot.com _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [v 0.10] Gst::init() is slow
|
|
In reply to this post by José Alburquerque-3
On Sun, 2012-09-09 at 07:31 -0400, José Alburquerque wrote:
> On Sun, 2012-09-09 at 07:01 -0400, José Alburquerque wrote: > > On Sep 9, 2012, at 4:19 AM, José Alburquerque <[hidden email]> wrote: > > > > > On Sun, 2012-09-09 at 09:46 +0300, Jiergir Ogoerg wrote: > > >> Thanks, > > >> To my desktop app startup time is critical, so, if I switch to the Gst > > >> C interface do you think the gst_init() would never take longer than > > >> say 200 milliseconds? Or is it nonetheless possible for it to take > > >> much longer like over 1-2 seconds in some cases? > > > > > > Actually, I think I spoke too soon in my last post. > > > > > > I was just thinking things through more thoroughly and since plug-in > > > types are not accessible in C. It may be possible to register the > > > wrapping functions for these plug-in types later (when they are > > > constructed) and not at startup (in Gst::init()) since it is not > > > possible to have these plug-in types from some C code and then try to > > > wrap them in a C++ wrapper which is why we go through the process of > > > loading the plug-ins and registering the wrapping functions in the first > > > place. It may not even be necessary to register wrapping functions for > > > these plug-in types. > > > > Sorry, I'm just wrong here. Though the C types are not available, having one from C code is possible because the plug-ins are created using the GType system. Registering the wrapping functions for plug-ins is thus still vital upon initialization. > > > > You're better off using C. I hope I didn't give you false hopes. > > Okay. I'm going back and forth because the issue is more complicated > than what I thought. Could you please ignore this last post. I'll look > at this during the week and not rush. If it's possible it will be in > the release. If not it wont. Sorry. I believe I've found a possible work around to get this working but it took longer than I expected to make some patches. I've filed a bug with the patches: https://bugzilla.gnome.org/show_bug.cgi?id=684006 But I'll hold the release off till next week to see if this can be included. Sorry for any inconveniences. > > > > > -Jose > > > > > > > > If the above is so, startup time (Gst::init()) will probably never be > > > more than the 100ms you mentioned. > > > > > > I'll be looking into this this week at the end of which a new release > > > should be out. If it this is doable, I'll include it in that release. > > > > > > In the meanwhile, however, I'm sure that using C will never have such a > > > slow start-up time. gst_init() does not load all the possible plug-ins > > > as gstreamermm does right now. > > >> > > >> > > >> On Sun, Sep 9, 2012 at 7:37 AM, José Alburquerque > > >> <[hidden email]> wrote: > > >> On Sat, 2012-09-08 at 13:19 +0300, Jiergir Ogoerg wrote: > > >>> Hi, > > >>> Gst::init() takes like 100+ ms, on rare occasions it takes > > >> even > > >>> longer, like over 2-4 seconds. Is it normal? > > >> > > >> > > >> Probably. The reason is that Gst::init() not only initializes > > >> GStreamer, it also initializes glibmm (which it relies on) and > > >> registers > > >> methods that wrap C types to correct C++ types for all the > > >> GStreamer > > >> GObject and GstMiniObject derived types and all the GStreamer > > >> plug-in > > >> types that gstreamermm makes available to be used in a C++ > > >> way. In the > > >> process, it must load all the plug-ins that gstreamermm makes > > >> available > > >> (this is probably the most time consuming part though only for > > >> the > > >> execution for which the plug-ins have not been loaded; the > > >> rest of the > > >> executions wont experience so much a delay). We know of no > > >> other way to > > >> ensure that the C objects handled are correctly differentiated > > >> and > > >> treated as appropriate C++ classes. > > >> > > >>> > > >>> To combat this I do Gst::init() in another pthread for my > > >> gui app to > > >>> show up instantly as usually. > > >>> > > >>> Using Ubuntu 12.04 amd64. > > >>> Intel Core i5. > > >> > > >>> _______________________________________________ > > >>> gstreamer-devel mailing list > > >>> [hidden email] > > >>> > > >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > >> > > >> > > >> -- > > >> José > > >> > > >> _______________________________________________ > > >> gstreamer-devel mailing list > > >> [hidden email] > > >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > >> > > >> > > >> _______________________________________________ > > >> gstreamer-devel mailing list > > >> [hidden email] > > >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > > > > -- > > > José > > > > > > _______________________________________________ > > > gstreamer-devel mailing list > > > [hidden email] > > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > > _______________________________________________ > > gstreamer-devel mailing list > > [hidden email] > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > -- José _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [v 0.10] Gst::init() is slow
|
|
Thanks a lot, hopefully your patches will land for both v.0.10 and the upcoming v1.0.
Offtopic: I'm surprised that the you/the gstreamer devs take questions and reports seriously. On other projects one usually needs to wait like a month+ before one even gets attention not to mention a solution. As to callgrind - sorry I'm busy these days plus I'll have to learn about it (valgind/callgrind) to report properly. As to why I use pthreads instead of idle functions - I'm just biased towards them since I'm used to them a lot more than to idle functions though the latter is probably a slightly better solution. On Sat, Sep 15, 2012 at 12:15 AM, José Alburquerque <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |