gstreamer integration in Windows app - DLL dependencies on different PCs

David Ing ding at
Tue Mar 22 19:18:26 UTC 2022

You might try twiddling the environment variables from my prior post.  The
variables named like GSTREAMER_ROOT_... and GSTREAMER_1_0_ROOT_... are how
gstreamer tries to find its home.  You can use GST_PLUGIN_PATH to point to
whatever folder contains the plugins.

It is also possible to use Process Monitor to see which DLLs are failing to

On Tue, Mar 22, 2022 at 12:01 PM MK <pikim at> wrote:

> Sorry, I forgot to mention that I'm already using both current MSVC 32-bit
> packages. They're installed at the default location under C:\gstreamer. To
> deploy 'my' DLL, I threw the necessary gstreamer DLLs into the same folder
> and copied the whole parent directory to another PC.
> Am 22.03.22 um 16:26 schrieb David Ing:
> I don't know what might be causing this, but you might save yourself some
> time by skipping the build and using the MSVC installers to get the build
> artifacts.  (The MSVC is less buggy than the MinGW.)
> What I do is I install the "runtime installer" and "development
> installer", then I copy the components from C:\gstreamer (or wherever) into
> a portable little "package" that my C++ code can reference.
> After you run the installers, check your environment for variable names
> that begin with GST, and your path for anything like "C:\gstreamer\...",
> and purge all of that.
> BTW, my C++ application does a bit of environmental housekeeping just
> before I initialize gstreamer (with gst_init).  I'm not sure if this stuff
> is necessary but it works for us.
>             // This is where the plugins live.            boost::filesystem::path pluginFolder = assemblyFolder / "plugins";            // WARNING: setting an environment variable is only safe at the beginning of the program (before any            // other threads have been spun up).  We do this to maintain strict control over the components that            // we are using.            const char* priorGstPluginPath = g_getenv("GST_PLUGIN_PATH");            std::string gstPluginPath = string::unwiden(pluginFolder.string());            if (priorGstPluginPath && (0 != priorGstPluginPath[0]))            {                gstPluginPath = gstPluginPath + PATHS_SEP_STR + priorGstPluginPath;            }            g_unsetenv("GST_PLUGIN_SYSTEM_PATH_1_0");            g_unsetenv("GST_PLUGIN_SYSTEM_PATH");            g_unsetenv("GST_PLUGIN_PATH_1_0");#if ARCH_32_BIT            g_unsetenv("GSTREAMER_ROOT_X86");
>             g_unsetenv("GSTREAMER_ROOT_MSVC_X86");            g_setenv("GSTREAMER_1_0_ROOT_X86", string::unwiden(assemblyFolder.string()).c_str(), true);            g_setenv("GSTREAMER_1_0_ROOT_MSVC_X86", string::unwiden(assemblyFolder.string()).c_str(), true);#elif ARCH_64_BIT
>             g_unsetenv("GSTREAMER_ROOT_X86_64");            g_unsetenv("GSTREAMER_ROOT_MSVC_X86_64");            g_setenv("GSTREAMER_1_0_ROOT_X86_64", string::unwiden(assemblyFolder.string()).c_str(), true);            g_setenv("GSTREAMER_1_0_ROOT_MSVC_X86_64", string::unwiden(assemblyFolder.string()).c_str(), true);#else  #error "Unknown architecture (32-bit vs. 64-bit)"#endif            g_setenv("GST_PLUGIN_PATH", gstPluginPath.c_str(), true);#if BOOST_OS_WINDOWS            // The nuget package provides some modules that are needed to enable some fancy network encryption stuff, but
>             // I have only seen it available on Windows.  Perhaps it is not required on Linux.  We only need it on Windows            // because it enables a feature that enables WebRTC in our Windows client aplications.            boost::filesystem::path gioModuleFolder = assemblyFolder / "gio_modules";            std::string gioModuleFolderString = string::unwiden(gioModuleFolder.string());            g_setenv("GIO_MODULE_DIR", gioModuleFolderString.c_str(), true);#endif
> On Tue, Mar 22, 2022 at 4:52 AM MK via gstreamer-devel <
> gstreamer-devel at> wrote:
>> Hello,
>> I've written a DLL plugin for a 3rd party application which initially
>> only used libjpeg for motion JPEG support. I used a VisualStudio (2017)
>> template which the 3rd party supplier provides as starting point. That
>> worked fine.
>> To be able to support other stream formats, I switched to gstreamer
>> instead of libjpeg. I can build the plugin and it works fine on the PC
>> where it was compiled (let's call it PC1). When I copy all the files to
>> another PC (PC2), the 3rd party application fails to load the DLL,
>> because of some missing DLL dependencies. When I compile the project on
>> PC2, it works well on PC2. But the version from PC2 fails on PC1.
>> I checked the dependencies with 'Dependencies' and noticed that on PC1
>> the missing DLLs differ from the missing DLLs on PC2. But even the
>> required DLLs differ from PC1 to PC2.
>> Does anyone have an idea what could cause this behavior?
>> Best regards,
>> Michael
>> PS: both versions do not run on PC3.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gstreamer-devel mailing list