[ffmpeg] Fix static linking on Windows, FindFFMPEG

[mkroening]

This adds zlib as dependency to make it possible to find in FindFFMPEG.cmake.
Also FFmpeg likes to autodetect zlib for additional features on compilation.
This removes the check for stdint.h, as it is included since MSVC 2010 and does not always find it.
To enable static linking on windows, bcript had to be added:

avutil.lib(random_seed.o) : error LNK2019: unresolved external symbol _BCryptOpenAlgorithmProvider@16 referenced in function _av_get_random_seed
avutil.lib(random_seed.o) : error LNK2019: unresolved external symbol _BCryptCloseAlgorithmProvider@8 referenced in function _av_get_random_seed
avutil.lib(random_seed.o) : error LNK2019: unresolved external symbol _BCryptGenRandom@16 referenced in function _av_get_random_seed

[mkroening]

First I tried to upgrade to 4.2 as well but that failed on Windows on ARM: old vcpkg-Linux-PR

This should now succeed and then be ready for review.

[cbezault]

It's fine since the ffmpeg port already provides a cmake module but just as a note ports should be providing cmake config files not modules.

[mkroening]

Thanks for the quick reply!

So you mean a FFMPEGConfig.cmake.in (like in CMake docs - Package Configuration File using CMakePackageConfigHelpers) would be better than the FindFFMPEG.cmake?

Is there any documentation about this regarding vcpkg? What are the benefits? Would it be worth to switch? Is there a particular port worth looking at regarding best practices?

[cenit]

ports should be providing cmake config files not modules.

? But ffmpeg is not built with CMake... like many other ports! In this case providing a config file would be just hard coding values with no real benefits, while in this case we can just enhance the module step by step and maybe push for it upstream... (to ffmpeg or to cmake)