Discussion:
[Live-devel] Live555 DLL rather than static libs
GRINDSTAFF Gene A via live-devel
2018-10-16 20:18:05 UTC
Permalink
To All:

I am trying to build a RTSP source filter for Microsoft Direct Show and Windows Media. In short these components are basically just DLLs. I can use cmake-gui to build the Live555 libraries and construct a decorated module definition file (.DEF) file which allows all of the various classes and entry points to be exported so a source DLL can be built. The decorated exports are ugly, but at least it works. However, when I use the mediasink.hh file to build the video filter DLL, it does not find the class OutPacketBuffer public definition of static unsigned maxSize; If the public static variable was defined as static unsigned DLL_IM_EX_PORT maxSize; where the symbol DLL_IM_EX_PORT is defined to be __declspec(dllimport), then it will build the video source filter.

However, the license precludes me from modifying the source, and a subclass will not solve this problem. If a setter and getter had been written to get to the private maxSize variable then this would not be an issue. Is there any chance that a future version of Live555 libs/source would make this change?

Thanks,
Gene

Gene A. Grindstaff
Executive Subject Matter Expert, SG&I
T: 1.256.730.6983 M: 1.256.566.5376 F: 1.256.730.1717
E: mailto:***@HexagonSI.com

Hexagon Safety & Infrastructure
305 Intergraph Way
Madison, AL, 35758
hexagonsafetyinfrastructure.com | LinkedIn | Facebook | Twitter
Ross Finlayson
2018-10-16 23:10:32 UTC
Permalink
Sorry, but I will never corrupt the source code by adding non-standard Microsoft-specific bullshit.

However, the LGPLv3 license allows you to modify the source code yourself, as long as you distribute your changes along with your product.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
GRINDSTAFF Gene A via live-devel
2018-10-17 11:55:00 UTC
Permalink
Ross,

I agree completely. I would never want you to put Microsoftisms into your code. Neither do I want to modify your code, and maintain and publish it forever.

Would you consider doing the following:

1. Making the public class OutPacketBuffer member "maxSize" in mediaSink.hh private.
2. Add the two methods below.
3. Replace the few references to OutPacket::maxSize with these calls.

This would allow the code to work in all environments, including the strange world of Microsoft.

Thanks,
Gene

static unsigned getMaxSize()
{
return maxSize;
}

static void setMaxSize(unsigned int nSize)
{
maxSize = nSize;
}

-----Original Message-----
From: live-devel <live-devel-***@ns.live555.com> On Behalf Of Ross Finlayson
Sent: Tuesday, October 16, 2018 6:11 PM
To: LIVE555 Streaming Media - development & use <live-***@ns.live555.com>
Subject: Re: [Live-devel] Live555 DLL rather than static libs

Sorry, but I will never corrupt the source code by adding non-standard Microsoft-specific bullshit.

However, the LGPLv3 license allows you to modify the source code yourself, as long as you distribute your changes along with your product.


Ross Finlayson
Live Networks, Inc.
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.live555.com%2F&amp;data=02%7C01%7Cgene.grindstaff%40hexagonsi.com%7Cc7a23f5d826648abf86408d633bdb94b%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C0%7C0%7C636753287308442067&amp;sdata=jNPsdVqBofDD%2FSruwPbJcAC%2FB6EnCw%2FcixwpS5S6Xdw%3D&amp;reserved=0
Ross Finlayson
2018-10-17 14:37:31 UTC
Permalink
> I agree completely. I would never want you to put Microsoftisms into your code. Neither do I want to modify your code, and maintain and publish it forever.
>
> Would you consider doing the following:
>
> 1. Making the public class OutPacketBuffer member "maxSize" in mediaSink.hh private.

I’m confused by this, because there are several other examples of static member variables declared “public:” - e.g.:
include/MPEG2TransportStreamFromESSource.hh: static unsigned maxInputESFrameSize;
include/MPEG2TransportStreamFromESSource.hh static unsigned maxInputESFrameSize;
include/RTSPClient.hh: static unsigned responseBufferSize;
Why do these not also need to be be changed to make Microsoft’s broken compiler happy?

Also, are you aware of the function
static void increaseMaxSizeTo(unsigned newMaxSize)
which most people call to change the value of “maxSize” (because, in reality, most people want to just increase it)?


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
GRINDSTAFF Gene A via live-devel
2018-10-17 15:42:23 UTC
Permalink
Ross,

I am equally confused, but I believe it is because none of the other static variables are called/used in your base libraries. If they were, then it would be an issue. I have built numerous examples of your code, and this is the only issue I have found. CMAKE can export the static member variable automatically, but there is no easy way to import the definition in Visual Studio. It is just one of the many strange things about Visual Studio.

Thanks,
Gene

-----Original Message-----
From: live-devel <live-devel-***@ns.live555.com> On Behalf Of Ross Finlayson
Sent: Wednesday, October 17, 2018 9:38 AM
To: LIVE555 Streaming Media - development & use <live-***@ns.live555.com>
Subject: Re: [Live-devel] Live555 DLL rather than static libs

> I agree completely. I would never want you to put Microsoftisms into your code. Neither do I want to modify your code, and maintain and publish it forever.
>
> Would you consider doing the following:
>
> 1. Making the public class OutPacketBuffer member "maxSize" in mediaSink.hh private.

I’m confused by this, because there are several other examples of static member variables declared “public:” - e.g.:
include/MPEG2TransportStreamFromESSource.hh: static unsigned maxInputESFrameSize;
include/MPEG2TransportStreamFromESSource.hh static unsigned maxInputESFrameSize;
include/RTSPClient.hh: static unsigned responseBufferSize;
Why do these not also need to be be changed to make Microsoft’s broken compiler happy?

Also, are you aware of the function
static void increaseMaxSizeTo(unsigned newMaxSize) which most people call to change the value of “maxSize” (because, in reality, most people want to just increase it)?


Ross Finlayson
Live Networks, Inc.
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.live555.com%2F&amp;data=02%7C01%7Cgene.grindstaff%40hexagonsi.com%7C36e61db1a1244eaa25ed08d6343ec121%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C0%7C0%7C636753841493689380&amp;sdata=CIgK0UQKr5pHzkoAHd2jgublXEQ5osO%2FThf%2BmFroAkk%3D&amp;reserved=0
Ross Finlayson
2018-10-17 16:30:35 UTC
Permalink
> I am equally confused, but I believe it is because none of the other static variables are called/used in your base libraries.

The other two examples I noted
maxInputESFrameSize
responseBufferSize
are definitely used in the code.

And unfortunately "OutPacketBuffer::maxSize” appears several times in the code, so I don’t want to change this just to appease one buggy compiler. Sorry.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
Jeremiah Morrill
2018-10-17 16:43:10 UTC
Permalink
I have this project building as a Dlll on Windows without any code changes.

CMake is my build system though (never used CMake GUI) so I can simply set in my main CMakeLists.txt:

set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)

This option does a lot of magic for MSVC that I never cared to look into, but it does work.

-Jer

From: Ross Finlayson<mailto:***@live555.com>
Sent: Wednesday, October 17, 2018 9:33 AM
To: LIVE555 Streaming Media - development & use<mailto:live-***@ns.live555.com>
Subject: Re: [Live-devel] Live555 DLL rather than static libs

> I am equally confused, but I believe it is because none of the other static variables are called/used in your base libraries.

The other two examples I noted
maxInputESFrameSize
responseBufferSize
are definitely used in the code.

And unfortunately "OutPacketBuffer::maxSize” appears several times in the code, so I don’t want to change this just to appease one buggy compiler. Sorry.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
GRINDSTAFF Gene A via live-devel
2018-10-17 17:30:39 UTC
Permalink
Jer,

Thanks!

Gene

Gene A. Grindstaff
Executive Subject Matter Expert, SG&I
T: 1.256.730.6983 M: 1.256.566.5376 F: 1.256.730.1717
E: mailto:***@HexagonSI.com

Hexagon Safety & Infrastructure
305 Intergraph Way
Madison, AL, 35758
hexagonsafetyinfrastructure.com | LinkedIn | Facebook | Twitter

________________________________
From: live-devel <live-devel-***@ns.live555.com> on behalf of Jeremiah Morrill <***@econnect.tv>
Sent: Wednesday, October 17, 2018 11:48 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Live555 DLL rather than static libs

I have this project building as a Dlll on Windows without any code changes.

CMake is my build system though (never used CMake GUI) so I can simply set in my main CMakeLists.txt:

set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)

This option does a lot of magic for MSVC that I never cared to look into, but it does work.

-Jer

From: Ross Finlayson<mailto:***@live555.com>
Sent: Wednesday, October 17, 2018 9:33 AM
To: LIVE555 Streaming Media - development & use<mailto:live-***@ns.live555.com>
Subject: Re: [Live-devel] Live555 DLL rather than static libs

> I am equally confused, but I believe it is because none of the other static variables are called/used in your base libraries.

The other two examples I noted
maxInputESFrameSize
responseBufferSize
are definitely used in the code.

And unfortunately "OutPacketBuffer::maxSize” appears several times in the code, so I don’t want to change this just to appease one buggy compiler. Sorry.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.live555.com%2F&data=02%7C01%7Cgene.grindstaff%40hexagonsi.com%7Cb911e9e633c24e3910d708d634505a7b%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C0%7C0%7C636753917080998334&sdata=MeOJfu8YY%2FoHR3hAc%2FAA7zNXkJlzI8OmRoqlUuzDL3o%3D&reserved=0>
GRINDSTAFF Gene A via live-devel
2018-10-17 18:25:40 UTC
Permalink
Jer,

It turns out that I already have CMake-Gui to do this, and did not realize it. This causes it to generate an export.def file with decorated names of the symbols. Unfortunately, I must generate four of these (x85,x64, debug, release) because the decorated symbols are different for some of the symbols.

Unfortunately, this does not solve the problem when I build any of the testProgs that use the OutPacketBuffer::maxSize variable. Visual Studio expects static public data to have a __declspec(dllimport) in the mediaSink.hh file before the definition of maxSize, or any static data that is defined this way. Otherwise, it is not accessible. I presume that this is for security reasons, but I am not sure. I can always modify the mediaSink.hh file, but I want to avoid that at all cost. In general, our legal staff will never approve the use of modified GNU licensed software. It seems that the WEB is full of trolls which search for corporations which use GNU licensed software, and have failed to publish or comply precisely with the license, and either charge us a fortune, make us publish all of our source code. That is why every GNU license software must be in a DLL to isolate the software.

Thanks,
Gene

From: live-devel <live-devel-***@ns.live555.com> On Behalf Of Jeremiah Morrill
Sent: Wednesday, October 17, 2018 11:43 AM
To: LIVE555 Streaming Media - development & use <live-***@ns.live555.com>
Subject: Re: [Live-devel] Live555 DLL rather than static libs

I have this project building as a Dlll on Windows without any code changes.

CMake is my build system though (never used CMake GUI) so I can simply set in my main CMakeLists.txt:

set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)

This option does a lot of magic for MSVC that I never cared to look into, but it does work.

-Jer

From: Ross Finlayson<mailto:***@live555.com>
Sent: Wednesday, October 17, 2018 9:33 AM
To: LIVE555 Streaming Media - development & use<mailto:live-***@ns.live555.com>
Subject: Re: [Live-devel] Live555 DLL rather than static libs

> I am equally confused, but I believe it is because none of the other static variables are called/used in your base libraries.

The other two examples I noted
maxInputESFrameSize
responseBufferSize
are definitely used in the code.

And unfortunately "OutPacketBuffer::maxSize" appears several times in the code, so I don't want to change this just to appease one buggy compiler. Sorry.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.live555.com%2F&data=02%7C01%7Cgene.grindstaff%40hexagonsi.com%7Cb911e9e633c24e3910d708d634505a7b%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C0%7C0%7C636753917080998334&sdata=MeOJfu8YY%2FoHR3hAc%2FAA7zNXkJlzI8OmRoqlUuzDL3o%3D&reserved=0>
Ross Finlayson
2018-10-17 18:59:17 UTC
Permalink
> In general, our legal staff will never approve the use of modified GNU licensed software. It seems that the WEB is full of trolls which search for corporations which use GNU licensed software, and have failed to publish or comply precisely with the license, and either charge us a fortune, make us publish all of our source code.

The only people who can enforce the copyright on a piece of software (or any other copyrighted thing) are the people who actually hold the copyright on the software. These people are not ’trolls’ - they’re the *owners* of the software. (Perhaps you’re confused with “patent trolls”, who enforce bogus patents on obvious ‘inventions’ - patents that should never have been issued.)

I hope your legal staff doesn’t consider Live Networks, Inc. (the company that owns/licenses this software) to be a ’troll’. (If they haven’t done so already, I hope they’ve read: http://live555.com/liveMedia/faq.html#copyright-and-license )


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
Loading...