Issues I found getting this to build about ffmpeg

[oviano]

Another minor issue I noticed was that when building using ffmpeg_deps.sln it initially fails when building gnutls due to a missing nettle/memxor.h file, but I think this just relates to the order things are built; on the second attempt it must have built nettle and then gnutls builds ok.

[oviano]

The final issue I noticed, is that there are a few warnings like this:

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppBuild.targets(1216,5): warning MSB8012: TargetPath(C:\FFmpeg\source\x265\SMP......\msvc\x265d.dll) does not match the Linker's OutputFile property value (C:\FFmpeg\msvc\bin\x86\x265d.dll). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile)."

[Sibras]

Great project by the way.

1. libspeex.def - LIBRARY labelled as libspeex not speex, meaning ffmpeg won’t start as it tries to load the libspeex.dll library instead of speex.dll

Fixed. Not sure how this was never detected before.

2. I encountered issues with libvpx.def mentioned elsewhere where I had to remove the DATA tags.

Fixed

3. It’s necessary to install YASM in addition to NASM for several projects to build.

I made a note in the readme to also check the readmes for each dependency project for any additional requirments

4. speex_header_free comes up as unresolved for libavcodec until I added it manually to libspeex.def

Fixed. I was using the .def supplied by the upstream speex project and apparently even they got it wrong.

5. Had to install the header file from here https://github.com/KhronosGroup/EGL-Registry/tree/master/api/KHR into a KHR include folder for the opengl stuff to build.

Updated the readme to add additional KHR requirement.

Think that’s about it. Only built ReleaseDLL of ffmpeg so not sure if other issues lurk when I build Debug.

This was all with VS2017 on Win 10 and latest git clone of the project.

I retargeted all projects to the latest Win10 SDK via ffmpeg_deps.sln

Unfortunately there is no way to auto retarget projects based on detected SDK. I do have a bat script that is added to some of the dependency projects that once all of them have been updated i will also add to ffmpeg. By default though the release builds in the release section are always built using the latest SDK.

[Sibras]

Another minor issue I noticed was that when building using ffmpeg_deps.sln it initially fails when building gnutls due to a missing nettle/memxor.h file, but I think this just relates to the order things are built; on the second attempt it must have built nettle and then gnutls builds ok.

Not much I can do about this as nettle is already listed as a dependency project of gnutls from within the solution so VS should auto handle the build order (apparently it doesnt always do good job though)

[Sibras]

The final issue I noticed, is that there are a few warnings like this:

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppBuild.targets(1216,5): warning MSB8012: TargetPath(C:\FFmpeg\source\x265\SMP......\msvc\x265d.dll) does not match the Linker's OutputFile property value (C:\FFmpeg\msvc\bin\x86\x265d.dll). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile)."

This can be completely ignored. This is just due to the projects using a unix style output (bin/lib/include folders) which is not how VS wants to do it. Unfortunately I havnt found a way to get VS to just ignore it.

[oviano]

Another issue I found after a clean build was that it failed building ffmpeg.exe with "unable to find mfx.lib" if the first build was ReleaseDLLStaticDeps. Once I'd built ReleaseDLL, then this allowed ReleaseDLLStaticDeps configuration to build too. Maybe this is normal, or maybe there is some kind of mismatch going on with the mfx library name.

[Sibras]

This is to be expected as its a limitation on Visual Studio configuration dependencies. Since ReleaseDLLStaticDeps only applies to the library dlls, the programs however still try and link to full dll's so it will link to mfx.lib while the libraries will link to libmfx.lib (and only 1 can be built at a time).

[oviano]

No problem, I understand. I just thought I'd raise it in case it pointed to a genuine issue.