After gst_deinit() was called, it's not allowed to call gst_init() again and you won't be able to use GStreamer anymore. gst_deinit() exists only for debugging/memory leak detection reasons.

As such it probably does not make much of a difference if this is reset or not, or does it cause problems in a specific situation for you? If so, please also provide a patch for that change, thanks!

*** Bug 794960 has been marked as a duplicate of this bug. ***

Currently I try to keep things simple and put gst related code in a separate C++ thread. At the very end, I would like to recreate the trhead with a different pipeline. That would require gst_init_check() to be called only once outside the thread, which means to rip the gst related code appart into one part (calling gst_init_check()) and the rest of it (with additional argc argv handling of the new pipeline arguments) inside the thread, which is not good, especially if the following patch could fix the problem.


gst/gst.c
@@ -1228,6 +1228,7 @@ gst_deinit (void)
   g_type_class_unref (g_type_class_peek (gst_promise_result_get_type ()));
 
   gst_deinitialized = TRUE;
+  gst_initialized = FALSE;
   GST_INFO ("deinitialized GStreamer");
 }

(In reply to hermann.fuerntratt from comment #3)
> Currently I try to keep things simple and put gst related code in a separate
> C++ thread. At the very end, I would like to recreate the trhead with a
> different pipeline. That would require gst_init_check() to be called only
> once outside the thread, which means to rip the gst related code appart into
> one part (calling gst_init_check()) and the rest of it (with additional argc
> argv handling of the new pipeline arguments) inside the thread, which is not
> good, especially if the following patch could fix the problem.

I'm not sure I understand. You can't call any GStreamer function after gst_deinit(), including gst_init() or gst_init_check().

But to split things into separate threads that's also not required. You can call gst_init() as many times as you want (it would do nothing for anything but the first call). So each of your threads could call that in the very beginning unless you want to simply place it at the top of your main().

Your problem is that gst_is_initialized() still returns TRUE after gst_deinit(), but what exactly are you doing based on that?


For the patch, please provide it as a 'git format-patch' formatted patch (with a commit message and correct author information), see https://gstreamer.freedesktop.org/documentation/contribute/index.html#how-to-submit-patches

Actually, all I want to do is to call 2 different pipelines in parallel. 
So I thought, gst_init() and gst_deinit() would work together. 
Now I don't call gst_deinit() anymore, and start the first pipeline in a thread with argv 
filesrc location=d:/testvideo1.mp4 ! decodebin ! videoconvert ! autovideosink name=video-sink1

using
g_option_context_parse(ctx, &argc, &argv, &err)

but the next call of 
g_option_context_parse(ctx, &argc, &argv, &err)
in the other thread with the other pipeline

filesrc location=d:/testvideo2.mp4 ! decodebin ! videoconvert ! autovideosink name=video-sink2

fails with 
ERROR: pipeline could not be constructed: no element "filesrc"

So, what am I missing?

Do you pass actual arguments to gst_init() via argv that are somehow relevant to GStreamer?

As long as you don't call gst_deinit(), the second pipeline should work just as the first. However calling g_option_context_parse() multiple times in the same application is generally not a good idea. Why would you want to parse commandline arguments multiple times?

For conveniance the pipelines are stored as space separated comandline strings which can be tested with gst_launch(), but also selected depending on the protocol type (file:// http://..). 

Using g_option_context_parse() allows to define our own options, which are not considered if gst_init() is used..

That's why we thought that this would be a rather straightforward way to deal with a large variety of sources..

May I gently ask, why you think that calling g_option_context_parse() multiple times is a bad idea?

Maybe you can provide a standalone testcase for reproducing the problem you're seeing?

Parsing the commandline multiple times seems rather hackish to me (parsing once into some local data structures that makes sense to your application and then working from those seems nicer), but it should also be unrelated as long as none of the other init functions (like gst_init()) allow being called multiple times. I don't know if GOptionContext explicitly supports this though.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/284.