Doom9's Forum - View Single Post

qyot27 · 1st October 2017, 04:20

So in the interest of trying to resolve this issue that's been (at least partially) holding up the Linux work, here's a few builds:

FFmpeg r87486
FFMS2 C-plugin r1145+104
AviSynth+ r2510 (VS2017)
AviSynth+ r2509 (GCC 7.2.0/MinGW-w64 5.0.2)

Includes both 32-bit and 64-bit in all packages. Windows XP supported by all builds. The 32-bit MSVC build of AviSynth+ and the FFMS2 C-plugin can be used on non-SSE2. The GCC builds of AviSynth+ require SSE2.

THE GCC BUILD IS FOR TESTING. The issue I was referring to above is that the 32-bit GCC build cannot be used by FFmpeg, because of the weirdness that comes with 32-bit builds, calling convention differences on Windows, and function decorations between GCC and MSVC. It's even a tiny lie that the 32-bit build can't be used by FFmpeg; there is a way that it can be made to work, but doing so would make that build of FFmpeg incompatible with the MSVC builds of AviSynth+ (with the possible exception of MSVC builds of FFmpeg being able to use MSVC builds of AviSynth+, but I don't know that for sure). The build of FFmpeg above is a standard build, and will work with the standard MSVC builds of AviSynth+ as well as the 64-bit GCC build of AviSynth+. This only ever affects Windows, since the underlying problems causing this are Windows-specific.

Additionally, the GCC builds of AviSynth+ shouldn't be able to use MSVC-built C++ plugins just due to the incompatibility between C++ implementations, but it is possible for the 64-bit build to use the 64-bit FFMS2 C-plugin (and likely, any other C plugins with 64-bit versions). AVISource also works, so there are at least two source filters that can be used with it. My ability to test under 64-bit Windows is almost non-existent, because I have to run it under a VM on a Silvermont under Ubuntu, running off an external USB 2.0 port. My tests with it under 64-bit Wine are what this information was gleaned from.

I'd like to be able to fix this properly so 32-bit GCC builds can be used with FFmpeg without breaking compatibility with MSVC. My attempts at forcing this have failed thus far. Trying to build as 32-bit with __stdcall ends up breaking compilation, and nothing I tried to force the function decorations into line worked. I'd assume it's actually that if we can fix the code so GCC doesn't choke when using __stdcall on 32-bit builds, it'd probably be okay (so long as I could get the decorations correct, and it wouldn't screw up building under MSVC or the 64-bit GCC build). I'm also really tired of trying to do so, so there's also a part of me that would probably be totally okay with it if we don't support building 32-bit AviSynth+ with GCC on Windows (as I said before, it's a Windows-specific issue; any future Linux support could use 32-bit with no problem, even if the market share for 32-bit Linux is dwindling pretty fast too).

1st October 2017, 04:20	#3635 \| Link
qyot27 ...? Join Date: Nov 2005 Location: Florida Posts: 1,420	So in the interest of trying to resolve this issue that's been (at least partially) holding up the Linux work, here's a few builds: FFmpeg r87486 FFMS2 C-plugin r1145+104 AviSynth+ r2510 (VS2017) AviSynth+ r2509 (GCC 7.2.0/MinGW-w64 5.0.2) Includes both 32-bit and 64-bit in all packages. Windows XP supported by all builds. The 32-bit MSVC build of AviSynth+ and the FFMS2 C-plugin can be used on non-SSE2. The GCC builds of AviSynth+ require SSE2. THE GCC BUILD IS FOR TESTING. The issue I was referring to above is that the 32-bit GCC build cannot be used by FFmpeg, because of the weirdness that comes with 32-bit builds, calling convention differences on Windows, and function decorations between GCC and MSVC. It's even a tiny lie that the 32-bit build can't be used by FFmpeg; there is a way that it can be made to work, but doing so would make that build of FFmpeg incompatible with the MSVC builds of AviSynth+ (with the possible exception of MSVC builds of FFmpeg being able to use MSVC builds of AviSynth+, but I don't know that for sure). The build of FFmpeg above is a standard build, and will work with the standard MSVC builds of AviSynth+ as well as the 64-bit GCC build of AviSynth+. This only ever affects Windows, since the underlying problems causing this are Windows-specific. Additionally, the GCC builds of AviSynth+ shouldn't be able to use MSVC-built C++ plugins just due to the incompatibility between C++ implementations, but it is possible for the 64-bit build to use the 64-bit FFMS2 C-plugin (and likely, any other C plugins with 64-bit versions). AVISource also works, so there are at least two source filters that can be used with it. My ability to test under 64-bit Windows is almost non-existent, because I have to run it under a VM on a Silvermont under Ubuntu, running off an external USB 2.0 port. My tests with it under 64-bit Wine are what this information was gleaned from. I'd like to be able to fix this properly so 32-bit GCC builds can be used with FFmpeg without breaking compatibility with MSVC. My attempts at forcing this have failed thus far. Trying to build as 32-bit with __stdcall ends up breaking compilation, and nothing I tried to force the function decorations into line worked. I'd assume it's actually that if we can fix the code so GCC doesn't choke when using __stdcall on 32-bit builds, it'd probably be okay (so long as I could get the decorations correct, and it wouldn't screw up building under MSVC or the 64-bit GCC build). I'm also really tired of trying to do so, so there's also a part of me that would probably be totally okay with it if we don't support building 32-bit AviSynth+ with GCC on Windows (as I said before, it's a Windows-specific issue; any future Linux support could use 32-bit with no problem, even if the market share for 32-bit Linux is dwindling pretty fast too).