Re: gstreamermm on windows

[Mikhail Titov <mlt gmx us>]

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 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? And does it mean that there is no MM
counterpart as of now for directsound sink?

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).

Mikhail