Fix problems when compiling for/on various platforms and OSes

[JensAc]

Hey there,

I just collected a few changes required when you want to compile for/on various platforms and OSes.
E.g. MSVC would not compile the avx accelerated code with plain casts and [] access in __m128is.

The changes do not change the behavior of the code itself, but make life simpler when (cross) compiling libvmaf.

[JensAc]

Ahh I have not seen that this is more or less a duplicate of #1477 which is even more complete than this version. I am happy to close this once #1477 is merged 🙂 .

[kylophone]

Hey, @JensAc thanks for the patience as I've been working through all these PRs. Can you tell me, is it mainly MSVC support you are looking for? So far we've only officially supported MINGW64 builds on Windows, but I'm trying understand how much value MSVC brings for Windows devs?

[JensAc]

Hi @kylophone,
thanks for the response. I'll try to tell the story behind as that might help to understand the use case.
We integrated libvmaf into our encoders to measure video quality while encoding. We build for Windows (x64 and arm), OS X, and Linux (x64 and arm) . For that reason, we compile libvmaf with the appropriate toolchain for the target OS and CPU architecture.

In particular, with MSVC we ran into issues, and I think these are addressed completely by #1477 , that I did not recognize when opening this PR. I did not want to propose too many changes (e.g. introducing pthreads4win), as I thought the interest might be limited due to already working MINGW64 builds. For that reason, I concentrated on changes that do not alter the functional behavior, but make life easier in case you want to compile with MSVC. From my perspective, you could close this PR, if you don't want to apply the changes or prefer #1477. The other option would be to merge it, as it should not affect the functional behavior.

[StormBytePP]

Hi @JensAc, I am the original author of the PR you referenced.

First of all, thanks for the mention and for looking at my PR.

As you can see there, the PR is not monolithic and depends on other little PRs which address more atomic items needed first (like avx).

You are right onto mentioning pthreads4win, it can also be implemented in a way that it can be used externally while I bundled it for the new CI tests to pass and to help non experienced users.

Moreover, vmaf's codebase changed a bit and it needs to be rebased to work with the latest changes. Though the changes are minimal I did not wanted to touch more the PR in order to wait for @kylophone to have time to look at it as said so he does not feel pressured, a thing that of course I will do to make the PR to work again.

However, I would recommend to close this PR (and I will take the little changes for those atomic PRs too crediting you of course) because I also include doc and CI tests to ensure that MSVC build will never break with the future changes.

Cheers,

David.

[JensAc]

Hi David, @StormBytePP ,

I fully agree with your comment and your recommendation is totally fair. Also, I like the effort you put into MSVC support very much. However, I will leave it up to @kylophone to decide how to proceed and not close this for the moment.

Best regards
Jens

[StormBytePP]

Hi Jens, @JensAc,

Yes, I am also waiting for his review/instructions. I have just rebased and updated all the code to work with the latest master so the review can be done properly.

Specially I've fixed the problems you had here too in the CI tests (the same ones that appeared with the latest master) by changing the intrinsics to properly support plain x86 code:

/usr/bin/ld: adm_avx2.c:(.text+0xe5a3): undefined reference to `_mm_extract_epi64'
/usr/bin/ld: adm_avx2.c:(.text+0xe5e5): undefined reference to `_mm_extract_epi64'
/usr/bin/ld: adm_avx2.c:(.text+0xe5fb): undefined reference to `_mm_extract_epi64'
/usr/bin/ld: adm_avx2.c:(.text+0xe63d): undefined reference to `_mm_extract_epi64'

Additionally, I have added a new option -Dbundled_winpthreads (default: true). This allows using either the bundled pthread-win32 implementation or an external Windows pthreads library. You can find more details in the updated Windows documentation.

If you have the chance, it would be greatly appreciated if you could test the external pthreads mode (-Dbundled_winpthreads=false) to see whether it fits the needs of your projects. Any feedback would be very valuable.

Best regards,
David