Compiling a debug version of GStreamer 1.5.2 on Windows

[Harry McKame]

Upgrading from GStreamer 1.4.5 to 1.5.2 on Windows.
I'm testing transcoding, which basically didn't work on 1.4.5, to see if there is an improvement in 1.5.2.

As I'm encountering aborts and the release on Windows is lacking symbols, the non-informative stack dump I can see is:
LIBGSTREAMER-1.0-0! 61495410()
LIBGSTENCODEBIN! 70704e7a()

And the error message is this (memory violation) :
First-chance exception in myexe.exe (UBGSTREAMER-1.0-0.DLL):
0xC0000005: Access Violation.

For better debugging, I need to compile a debug version of GStreamer on Windows.
Although I have managed to compile 1.4.5 in the past, I have new problems with 1.5.2.

It would be much simpler if the maintainer of the Windows port of GStreamer could publish detailed instructions on how to compile it from sources, including which version of Visual Studio he is using, which additional products are required, and what is his directory structure.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Mo, 2015-08-10 at 14:42 +0200, Harry wrote:
> Upgrading from GStreamer 1.4.5 to 1.5.2 on Windows.
> I'm testing transcoding, which basically didn't work on 1.4.5, to see
> if there is an improvement in 1.5.2.
>
> As I'm encountering aborts and the release on Windows is lacking
> symbols, the non-informative stack dump I can see is:

The binaries are built with mingw, and mingw can't generate debug
symbols for Visual Studio unfortunately. You could use gdb for
debugging with the binaries though.

> For better debugging, I need to compile a debug version of GStreamer
> on Windows.
> Although I have managed to compile 1.4.5 in the past, I have new
> problems with 1.5.2.
>
> It would be much simpler if the maintainer of the Windows port of
> GStreamer could publish detailed instructions on how to compile it
> from sources, including which version of Visual Studio he is using,
> which additional products are required, and what is his directory
> structure.

The cerbero build system is used, see here:
http://cgit.freedesktop.org/gstreamer/cerbero/

It also contains a README that explains how to use it.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Harry McKame]

Sebastian,

To my way of thinking, it doesn't make any sense to use mingw for creating Windows DLLs.
We Windows developers normally use Visual Studio, so without distributing a Visual Studio debug version, getting good bug reports on Windows is rather hopeless for you.

I don't mind fixing a reasonable number of Visual Studio compile errors and contributing to the project, but the problems I'm encountering are more serious than that.

- Do you mean to say that the Visual Studio projects found in "...\gstreamer-1.5.2\win32" are useless?
- If they are not, could the person who created them publish some sort of user guide?
 
Harry

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Josh Doe]

On Tue, Aug 11, 2015 at 12:07 PM, Harry <[hidden email]> wrote:
> Sebastian,
>
> To my way of thinking, it doesn't make any sense to use mingw for creating
> Windows DLLs.
> We Windows developers normally use Visual Studio, so without distributing a
> Visual Studio debug version, getting good bug reports on Windows is rather
> hopeless for you.

I'm very grateful the GStreamer developers produce Windows binaries at
all, it's something that until relatively recently was done by others.
Regularly updated Windows binaries are quite valuable in my opinion.
Integrating Visual Studio into the build system is not trivial,
otherwise it would have already been done. Using mingw is very similar
to the other platforms, which makes automating the build system far
easier. You are welcome to improve the build system to support Visual
Studio, I and many other developers would be grateful. The fact that
debugging cannot be done easily in Visual Studio, while unfortunate,
is not a showstopper by any means. The debugging output is quite
verbose and can helpful in most cases. If you have issues with
specific plugins you can always compile them in Visual Studio,
something I have done on occasion.

> I don't mind fixing a reasonable number of Visual Studio compile errors and
> contributing to the project, but the problems I'm encountering are more
> serious than that.
>
> - Do you mean to say that the Visual Studio projects found in
> "...\gstreamer-1.5.2\win32" are useless?
> - If they are not, could the person who created them publish some sort of
> user guide?

Those project files are woefully out of date, and are more or less
useless. There has been a plan for some time to automatically generate
project files, but I don't think it has had any attention yet.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-3]

Le mardi 11 août 2015 à 18:07 +0200, Harry a écrit :
> Sebastian,
>
> To my way of thinking, it doesn't make any sense to use mingw for
> creating Windows DLLs.
> We Windows developers normally use Visual Studio, so without
> distributing a Visual Studio debug version, getting good bug reports
> on Windows is rather hopeless for you.

We are well aware of the issue. Though, you need to understand there is
a community clash. In the Open Source community, it is expect that
solution are proposed, discussed and implemented by people having
interest in it. Most, if not all people from the Windows community,
which unfortunately is often around Close Source, have the habit of
requesting feature and often forget that they could be the one
implementing it (they are the one with the interest).

To one of your remark:
    "It would be much simpler if the maintainer of the Windows port of
    GStreamer could publish detailed instructions on how to compile it
    from sources", it's important to understand that there is no such
    thing as a "Windows port"
There is no such thing as a Windows port, and not specific maintainer
for that. GStreamer is supports Windows, that's it. It's the same
people the develop OSX, iOS, Android, Linux and so.

>
> I don't mind fixing a reasonable number of Visual Studio compile
> errors and contributing to the project, but the problems I'm
> encountering are more serious than that.
>
> - Do you mean to say that the Visual Studio projects found in
> "...\gstreamer-1.5.2\win32" are useless?

These are left over from 0.10. We use to have projects that would let
you build GStreamer using Visual Studio. Sadly, maintaining two build
systems was too much work and many of the dependencies GStreamer rely
on don't have support for Visual Studio. Having only GStreamer built
with Visual Studio but none of the dependencies only moves the problem.
Solving this issue is overwhelming.

The root cause here being interroperability in the debugging symbols.
In theory, Microsoft could solve this issue by opening the debugging
format, which we could then add to mingw. This would likely take less
time, and not cause such a huge overhead on developers.

> - If they are not, could the person who created them publish some
> sort of user guide?

It's not the work of a single person. They where created by hand, using
the Visual Studio UI. The user manual of this software is your guide.
Take note that these dates back to something like Virtual Studio 6.0
(maybe a tad newer). But they are so old, that you may just restart
from scratch.

Nicolas

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Harry McKame]

Thanks to Josh & Nicolas for their explanations.

I have done some research into the question of debugging mingw under VS and have found :

1. The mingw -gcoff option produces debugging information that might be understood by the MS debugger in a limited way (might be worth trying).

2. CMake (http://www.cmake.org/Wiki/CMake#Tutorials) generates native makefiles and workspaces in many compiler environments.
I don't know how applicable it is to your project, or whether you could use it as a future cross-platform solution.

3. The CodeProject article "Automatically Translate makefile C/C++ Project for Visual Studio" offers a rudimentary solution (http://www.codeproject.com/Tips/870845/Automatically-Translate-makefile-C-Cplusplus-Proje).
I mention it even if it is unlikely to be good enough for the job.

4. The cv2pdb project (https://github.com/rainers/cv2pdb) might be useful.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Harry McKame]

I am trying to setup on Windows a portable installation of our 32-bit application, which is to include GStreamer.

I have naively included in my folder all the GStreamer DLLs from "...\GStreamer\1.0\x86\bin".
The result was : "First-chance exception in my.exe (LIBGLIB-2.0-0.DLL): 0xC0000005: Access Violation".

I then deleted the GStreamer DLLs from my folder, installed "gstreamer-1.0-x86-1.5.2.msi" and added the "bin" folder to the PATH, and then everything worked fine.

I have tried to capture the GStreamer installation, and have identified at least this registry location being updated :
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GStreamer1.0\x86
where the InstallDir key contains the installation directory.
However, adding these registry keys, with InstallDir set to my installation directory, has not improved anything.

What else is missing ?
Is the above registry key really necessary ?

In short, how to create a portable installation for GStreamer (or semi-portable if some registry work is required).
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Josh Doe]

On Fri, Aug 21, 2015 at 8:19 AM, Harry <[hidden email]> wrote:
> In short, how to create a portable installation for GStreamer (or semi-portable if some registry work is required).

I've never had issues running GStreamer in this way, at least as of
version 1.4.3, you definitely don't need to touch the registry. I'd
guess you're having an issue with Windows' DLL search order. Before
trying this with your complete app, try it with just gst-launch, with
the exact same environment as your app. Also look into Dependency
Walker, maybe there's some strangeness going on with what DLLs are
being loaded.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Harry McKame]

Trying : gst-launch-1.0 audiotestsrc num-buffers=500 ! avenc_ac3 ! avimux ! filesink
Result : ERROR: pipeline could not be constructed: no element "audiotestsrc".

This corresponds to my problem, where the failing line is constructing my first element :
  pvid->playbin = gst_element_factory_make("playbin", "playbin");

It seems like there is a problem with constructing elements.

More info of what I did:

I copied all the 284 DLLs in the 1.5.2 release to the same folder as are my executable and my DLL that calls GStreamer.
The folder structure is absolutely flat, with no sub-folders.
I can clearly see that libgstaudiotestsrc.dll is inside the folder.

Josh: According to what you said, this should work. Or am I missing something?
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Thornton, Keith]

Have you tried setting the GST_PLUGIN_PATH environment variable to point there ?

-----Ursprüngliche Nachricht-----
Von: gstreamer-devel [mailto:[hidden email]] Im Auftrag von Harry
Gesendet: Montag, 24. August 2015 13:09
An: [hidden email]
Betreff: Re: Portable version of GStreamer 1.5.2 on Windows

Trying : gst-launch-1.0 audiotestsrc num-buffers=500 ! avenc_ac3 ! avimux ! filesink Result : ERROR: pipeline could not be constructed: no element "audiotestsrc".

This corresponds to my problem, where the failing line is constructing my first element :
  pvid->playbin = gst_element_factory_make("playbin", "playbin");

It seems like there is a problem with constructing elements.

More info of what I did:

I copied all the 284 DLLs in the 1.5.2 release to the same folder as are my executable and my DLL that calls GStreamer.
The folder structure is absolutely flat, with no sub-folders.
I can clearly see that libgstaudiotestsrc.dll is inside the folder.

Josh: According to what you said, this should work. Or am I missing something?
_______________________________________________
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

[Josh Doe]

On Mon, Aug 24, 2015 at 7:08 AM, Harry <[hidden email]> wrote:
> I copied all the 284 DLLs in the 1.5.2 release to the same folder as are my executable and my DLL that calls GStreamer.
> The folder structure is absolutely flat, with no sub-folders.
> I can clearly see that libgstaudiotestsrc.dll is inside the folder.

I'm not positive about this but I'm quite sure GStreamer looks for
plugins under lib/gstreamer-1.0 in the directory above the one where
gst-launch-1.0 is located. In other words for
root/mybin/gst-launch-1.0.exe, it will look for plugins in
root/lib/gstreamer-1.0. As Keith said, you could add root/mybin to the
GST_PLUGIN_PATH environment variable and it should work. However I
personally like to keep plugins in a separate directory.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Harry McKame]

Keith : GST_PLUGIN_PATH fixed the problem. Many thanks.

Josh :

The choice of the plugins folder is ill-advised. For a clean deployment all must fit within the single installation folder.

I believe that such artificial mechanisms as looking in ../../lib/gstreamer-1.0 or GST_PLUGIN_PATH should be abandoned in favor of those three automatically supplied by the operating system : executable folder, current folder, PATH environment variable.

GStreamer only loses its simplicity of usage by employing such non-standard "features", not shared by any other application. I believe it's better to let the operating system handle the loading of DLLs/libraries according to the rules that everyone knows.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-3]

Le mardi 25 août 2015 à 10:57 +0200, Harry a écrit :
> I believe that such artificial mechanisms as looking in
> ../../lib/gstreamer-1.0 or GST_PLUGIN_PATH should be abandoned in
> favor of those three automatically supplied by the operating system :
> executable folder, current folder, PATH environment variable.

It's all weird to me, as I don't remember anyone changing this. To
follow Windows rules, the code use to check for plugins (from
executable directory):

  gstreamer-1.0/
  if (basename(curdir) == "bin")
    ../lib/gstreamer-1.0

This ../../ is unknown to me.

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Harry McKame]

Nicolas,

To follow Windows rules, and also Linux rules, the code needs do nothing except of course load the DLL/library.

The OS automatically searches all the possible paths.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Josh Doe]

On Wed, Aug 26, 2015 at 6:35 AM, Harry <[hidden email]> wrote:
> To follow Windows rules, and also Linux rules, the code needs do nothing except of course load the DLL/library.
>
> The OS automatically searches all the possible paths.

This is true for the common shared library, where an executable or
shared library is linked to another library, and at run-time that
library is found in an OS dependent manner. However, plugins have a
sort of reverse dependency, so the standard OS mechanism is of no use.
GStreamer, along with any other plugin system, must have a way to know
which shared libraries (plugins) it should attempt to load. One way
would be to use a simple list of filenames, another would be to scan a
directory for shared libraries, load each one, and check if the
appropriate symbols are exported. In the case of GStreamer, it does
such a scan, looking for a symbol "gst_plugin_desc that is a struct of
type GstPluginDesc"
(http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstPlugin.html#GstPluginDesc).

Plugins are located in a separate directory for several reasons that I
can think of. First of all, I just think it's cleaner, makes it easier
to know which DLLs/SOs are plugins, and it's easier to
add/remove/upgrade plugins. Also you avoid the extra time it takes to
check all the shared libraries that aren't plugins, which can easily
be in the hundreds. And, if an application reports plugins that didn't
load correctly, this could produce lots of false alarms. Then, at
least on Windows, using LoadLibrary and GetProcAddress to check for
symbols will cause DllMain to be run which could execute slow or
dangerous code (though there seems to be a way to get around
LoadLibrary to check for the presence of symbols).
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Harry McKame]

Josh,

If GStreamer scans my entire folder, this is an argument for separating plugins in a sub-folder.

If my understanding is correct, then there are 3 folders involved :

1. "bin" - which contains the basic software
2. "lib" - which contains the plugins, to which points GST_PLUGIN_PATH
3. The parent folder of both, pointed-to by GSTREAMER_1_0_ROOT_X86,
   through which are found the above two as sub-folders
   (GST_PLUGIN_PATH is then not required).

I suppose that the solution would be to add in my program something like:
  setenv("GSTREAMER_1_0_ROOT_X86", "./gstreamer-1.0");
where my sub-folder gstreamer-1.0 will contain "bin" and "lib".

I note that "bin" and "lib" contain (besides other unrelated files) DLLs in sub-folders :
  modules\libgiognutls.dll
  validate\libgstvalidatefaultinjection.dll

I strongly urge a cleaner folder-structure that is easier for portable deployment.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-3]

Le mercredi 26 août 2015 à 12:35 +0200, Harry a écrit :
> To follow Windows rules, and also Linux rules, the code needs do
> nothing except of course load the DLL/library.
>
> The OS automatically searches all the possible paths.

This statement is wrong for plugins. Plugins resides in their own
folder, they are not simple libraries we link to.

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-3]

Le mercredi 26 août 2015 à 15:38 +0200, Harry a écrit :
> I note that "bin" and "lib" contain (besides other unrelated files)
> DLLs in sub-folders :
>   modules\libgiognutls.dll
>   validate\libgstvalidatefaultinjection.dll
>
> I strongly urge a cleaner folder-structure that is easier for
> portable deployment.

As long as each library have it relative to the executable, this shall
not be an issue. I have tested all this in the past (relocating windows
app) and it all worked as expected, as long as you don't mess up the
way we suggest to install it. Again, it should all be relative to your
executable.

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Harry McKame]

While linking, I get "undefined reference" messages for all functions named `gst_discoverer_*` and also to the following:
gst_video_info_from_caps, gst_video_overlay_expose.

I'm porting from Windows, where my application works, to Kubuntu 16.10 with Gstreamer 1.8.3, and my link contains `pkg-config --libs gstreamer-1.0` which gives :
-lgstreamer-1.0 -lgobject-2.0 -lglib-2.0.

What am I missing in the link ? Or is it a missing package ?
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mailing List SVR]

Il 03/03/2017 13:38, Harry McKame ha scritto:
> While linking, I get "undefined reference" messages for all functions named `gst_discoverer_*` and also to the following:
> gst_video_info_from_caps, gst_video_overlay_expose.
>
> I'm porting from Windows, where my application works, to Kubuntu 16.10 with Gstreamer 1.8.3, and my link contains `pkg-config --libs gstreamer-1.0` which gives :
> -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0.
>
> What am I missing in the link ? Or is it a missing package ?

try

-lgstpbutils-1.0 -lgstvideo-1.0

Nicola

> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel