Re: gstreamermm on windows

[José Alburquerque <jaalburquerque gmail com>]

On Sun, 2011-08-21 at 22:41 -0500, Mikhail Titov wrote:
> 
> On 08/21/2011 10:49 AM, José Alburquerque wrote:
> > On Sun, 2011-08-21 at 01:30 -0500, Mikhail Titov wrote:
> >> On 08/20/2011 11:38 PM, José Alburquerque wrote:
> >>> Hi Mikhail, thanks for trying:
> >>>
> >>> On Sat, 2011-08-20 at 17:49 -0500, Mikhail Titov wrote:
> >>>> static GLIBMM_API const ClockTime CLOCK_TIME_NONE = GST_CLOCK_TIME_NONE;
> >> I've built glibmm just fine, and I had something defined under this
> >> macro. It was possible to compile either by removing this or by
> >> undeffing and defining empty GLIBMM_API . I just can't imagine what
> >> could be there from VC++ point of view. If it is declared as static it
> >> resides in compiled unit and is of single copy when linked. AFAIK
> >> another alternative is to declare it extern and then export symbol from
> >> shared library.

> > Actually, these variables are designed to be constants that can be used
> > like their equivalent GStreamer constants.  I did something similar to
> > what is done in glibmm's ustring.h with the npos constant.  I'm thinking
> > that these should stay the way they are.  In general, I think we prefer
> > to use variables instead of '#defines' for better type checking.  I
> > could be wrong.  I'll look into this a little more later though.

> I realized that I didn't have GLIBMM_HAVE_ALLOWS_STATIC_INLINE_POS
> defined while compiling. However I get problems when I enable it. Also
> there was an issue about it before
> http://mail.gnome.org/archives/gtkmm-list/2005-November/msg00149.html
> 
> In my understanding if not declare just as static in header file, those
> constants should be declared in some cc file whereas in header file it
> should be made extern without static during gstreamermm building and
> __declspec(dllimport) for applications that use it. I'm not sure why
> gendef tool is preferred in all MM projects instead of
> __declspec(dllexport) as a result of macro expansion. As I mentioned
> before I can't think of anything in place of GLIBMM_API other than
> emptiness that would make it compile with MS VC++.

I'll take this into account now that gstreamermm should build on
Windows.  Thanks.

> >>> I would suggest you use 0.10.9.1 instead.  It has a few bug fixes
> >>> necessary to ensure functionality of the examples and the library in
> >>> general.

> >> I think I used second to the latest.

> > If it's the release right before the latest one then, yes that should be
> > 0.10.9.1.

> I was wrong as I used plain 0.10.9 . I upgraded to 0.10.9.1 before I
> switch to Fedora instead of OBS.

> >>> There are the directdrawsink (in gst-plugins-bad) and the
> >>> directsoundsink (in gst-plugins-good) plugins for rendering video and
> >>> audio in Windows.  I'm not sure that there are others.

> I see mingw32-gst-plugins-good package but I don't see devel one. Is it
> just something wrong with OBS?

I don't think there would be a devel package because the plugins in the
packages providing them are meant to be used generically by creating
them via a GstElementFactory.  On this system (ubuntu) there are no
-devel packages for the gst-plugins-{good,ugly} either.

> And does it mean that there is no MM
> counterpart as of now for directsound sink?

Right now there's no specific class wrapping these plugins but they can
be used generically.  The ogg_player example shows how that could be
done.

> 
> I'm a bit confused as DirectShow is mentioned on gstreamer home page
> however directsound and directdraw are parts of DirectX. I remember
> absence of DirectShow support was the reason I'm using MSVC++ instead of
> gcc (tons of proprietary extensions used in SDK headers for DirectShow).

I don't know enough about these technologies to give you any exact
answer, but I think that what GStreamer does is write plugins to use the
underlying technology not actually implement the technology.

As far as building, I think using MinGW first is better because the
GStreamer build system is designed to use autotools by default and MinGW
allows using the same system.  During the configuration process (using
autotools), the various GStreamer packages detect which plugins are
available for building.  Once things are built there, then things can be
configured for MSVC++.  That's what I think presently.

I've already begun, but you should continue your attempt.  Hopefully you
might be able to provide something useful for others also.

> 
> Mikhail

-- 
José