3. Include files folder-structure

Also for the "#include <gst.h>" include to work without causing multiple errors of file not found, the following paths must currently be added to the compiler's list of include folders:

C:\Program Files (x86)\GStreamer\1.0\x86\include
C:\Program Files (x86)\GStreamer\1.0\x86\include\gstreamer-1.0
C:\Program Files (x86)\GStreamer\1.0\x86\include\gstreamer-1.0\gst
C:\Program Files (x86)\GStreamer\1.0\x86\include\glib-2.0
C:\Program Files (x86)\GStreamer\1.0\x86\lib\glib-2.0\include

The first one should really have been enough. The others are currently required because the #include statements do not include the correct sub-folder names (ie. "#include <gstreamer-1.0\????.h>").

I also found out that gst.h omits video-info.h, so one needs to add:
#include <video/video-info.h>

> Also for the "#include <gst.h>" include to work without causing multiple
> errors of file not found, the following paths must currently be added to the
> compiler's list of include folders:

It should be #include <gst/gst.h>

> C:\Program Files (x86)\GStreamer\1.0\x86\include
> C:\Program Files (x86)\GStreamer\1.0\x86\include\gstreamer-1.0
> C:\Program Files (x86)\GStreamer\1.0\x86\include\gstreamer-1.0\gst
> C:\Program Files (x86)\GStreamer\1.0\x86\include\glib-2.0
> C:\Program Files (x86)\GStreamer\1.0\x86\lib\glib-2.0\include
> 
> The first one should really have been enough. The others are currently
> required because the #include statements do not include the correct
> sub-folder names (ie. "#include <gstreamer-1.0\????.h>").

I think it should be the second and the last two. Check what

  pkg-config --cflags gstreamer-1.0

gives you.


> I also found out that gst.h omits video-info.h, so one needs to add:
> #include <video/video-info.h>

On purpose, the video stuff is in a separate helper library with its own include. The include should be:

  #include <gst/foo/foo.h>

in this case:

  #include <gst/video/video.h>

Thanks for your answer.

I don't have pkg-config.

True: including <gst/gst.h> reduces the required includes-set to the second and the last two, this make three.

For ease-of-use I do believe in one global include folder path. It would be nice if all #include statements everywhere were to follow the <gst/foo/foo.h> convention.

There can't be one global include path, that's just not how things are done customarily in the pkg-config/glib/gstreamer world.

e.g. both gstreamer 0.10 and 1.0 use #include <gst/gst.h> but one would use -Iprefix/include/gstreamer-0.10/ the other -Iprefix/include/gstreamer-1.0

I don't know if the problem merits a long discussion, but just remark that this doesn't cover these funny two folders :
C:\Program Files (x86)\GStreamer\1.0\x86\include\glib-2.0
C:\Program Files (x86)\GStreamer\1.0\x86\lib\glib-2.0\include

If you include the property sheet, you should not have to set these path manually.

I'm not using such a compiler.

Then that means you are using GCC, and should be using pkg-config, just download and install it. And then only one path matter:

C:\Program Files (x86)\GStreamer\1.0\x86\lib\pkgconfig

Note that you need to set the prefix to your relocation (the installer lacks this atm). See pkg-config manual on how to override variables.

(In reply to Harry from comment #1)
> 3. Include files folder-structure
> 
> Also for the "#include <gst.h>" include to work without causing multiple
> errors of file not found, the following paths must currently be added to the
> compiler's list of include folders:
> 
> C:\Program Files (x86)\GStreamer\1.0\x86\include
> C:\Program Files (x86)\GStreamer\1.0\x86\include\gstreamer-1.0
> C:\Program Files (x86)\GStreamer\1.0\x86\include\gstreamer-1.0\gst
> C:\Program Files (x86)\GStreamer\1.0\x86\include\glib-2.0
> C:\Program Files (x86)\GStreamer\1.0\x86\lib\glib-2.0\include
> 
> The first one should really have been enough. The others are currently
> required because the #include statements do not include the correct
> sub-folder names (ie. "#include <gstreamer-1.0\????.h>").
> 
> I also found out that gst.h omits video-info.h, so one needs to add:
> #include <video/video-info.h>

There are property sheets for VS for all this. Check the stuff inside share/vs/2010. They are autogenerated from the pkg-config stuff.

(In reply to Harry from comment #0)

> 2. File-names
> 
> One is obliged to use the Unix path separator (/) instead of the Windows one
> (\), at least on gst-launch-1.0.exe (haven't gotten yet into programming).

Windows-style paths should work on filesrc and others, if not that would be a bug. Make sure to properly escape the backslashes in Windows paths, like you would need to do for any other commandline application too.

For things that expect URIs (e.g. playbin), you must provide a valid URI. Windows does not really make that easy, but like in any other software using URIs you have to do something like file:///C:/Documents%20and%20Settings/davris/FileSchemeURIs.doc

See http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx

Include files:
All I am trying to say is that the lack of consistency fits more version 0.10 than version 1.5 or 2.0, templates or not. It's a minor problem and not urgent, but maybe should be taken into consideration in the future.

File paths:
The URI property being troublesome for files and requiring the pre-processing of file-names for adding "file:///" etc., I would suggest for suitable cases an additional property specifying a native-format file-name (maybe "filesrc"?), just for ease-of-use.

> The URI property being troublesome for files and requiring the
> pre-processing of file-names for adding "file:///" etc., I would suggest for
> suitable cases an additional property specifying a native-format file-name
> (maybe "filesrc"?), just for ease-of-use.

Adding "file:///" at the beginning of a filename is not the correct way to create a URI. Use gst_filename_to_uri() instead. (This is not windows-specific, but true on other operating systems as well).

Just looks a bit inelegant, but that is a matter of taste.

I have found out thru examples, that gst_filename_to_uri() requires g_free(), which is not mentioned in the documentation.

I have previously naively done :

  g_object_set (playbin, "uri", gst_filename_to_uri(path, NULL), NULL);

But now found that I need to do in fact :

  gchar   *uri;
  uri = gst_filename_to_uri (path, NULL);
  if (uri == NULL)
    ?????;
  g_object_set (playbin, "uri", uri, NULL);
  g_free (uri);

I think this is beyond inelegant, even ugly. The ideal would be :

  g_object_set (playbin, "filesrc", path, NULL);

So I maintain that a "filesrc" parameter to playbin and similar would be much more user-friendly.

I have added a comment to the documentation of gst_filename_to_uri() that clarifies that the return value must be freed. For developers familiar with the API conventions that would have been obvious because of the gchar * return value instead of const gchar*, but it's good to make it explicit of course.

Your comments on API aesthetics are noted.

And gst_filename_to_uri() will pretty much always succeed unless you feed it invalid input.

Thanks for your answers.

One more enormous problem.

4. The released DLLs cannot be used without their .lib files, so are basically useless.

However, the .lib files were not included in the release!

For myself, I only needed C Core and I knew how to generate CORE_RL_magick_.lib from CORE_RL_magick_.dll by hand, but not everyone would know that.

It would be nice to have included in the release the *.lib files for the DLLs that are user-callable.

You mean the .lib files are not included in http://gstreamer.freedesktop.org/data/pkg/windows/1.5.1/gstreamer-1.0-devel-x86_64-1.5.1.msi , i.e. you only get the .dll, headers and .a files?

Posted in the wrong forum, how do I delete this one?

Thanks for your comments, but I don't really see anything actionable in here for us.

https://gstreamer.freedesktop.org/documentation/installing/on-windows.html

Has documentation for installing on windows now.

If there are specific things that should be improved in the docs, please file new bugs, thanks!