New: FFmpeg 8+, CUDA, OpenCL, Vulkan, ShaderC, libplacebo, libVPL

[softworkz]

Major Update - Supports FFmpeg 8.x and beyond

Changes

• Adds support for compilations of fftools/resources via bin2c.exe
  (supersedes Add support for fftools/resources #83)
• Adds a smp_common.props file
  This is imported by all projects and allows to apply changes easily and in a persistent way - i.e. your modifications do not get lost when regenerating the projects
• Adds support for libvpl (OneVPL)
  This is the new dispatcher for Intel QSV hardware acceleration, which replaces libmfx
• Adds support for shaderc dependency
• Adds support for shader (.comp) file conversion to C strings
• Adds support for OpenCL (.cl) file conversion to C strings
• Adds support for CUDA PTX compile via NVCC and conversion to C strings
  (supersedes Add support for CUDA compilation via NVCC #82)
• New option to specify a custom tesseract library name
  (tesseract library naming is messy)
• Detect artifacts from configure in the ffmpeg tree
  The generator doesn't work properly when configure has been run in the FFmpeg source dir.
  Added detection for this case and warning will be shown
• Adds support for Vulkan (filters) and libplacebo
  A repo will be provided with an adapted libplacebo which can be compiled on Windows without MSYS2

Supersedes #82
Supersedes #83
Closes #67
Closes #79
Closes #29
Closes #86

[Sibras]

This all looks very nice. Thanks for the contribution!

To help test and review can you split this into multiple PRs per change (e.g. libvpl, cl+spirv, libplacebo, resources, common_props, cuda, tesseract etc.). They can build off each other if that makes it easier for you, but splitting them makes it easier to get some of the simple changes in quick. The way youve actually split the commits would work fine to create a PR for each of those (Although if you can split the cuda/opencl+spirv that would amke it easier to)

[softworkz]

That's a bit tedious because it causes merge/rebase conflicts when adjacent lines are changing (like in template.rc) - this has bitten me already when preparing the PR, reshaping the commits. They are pretty much building up upon previous ones.

Can't you review commit-by-commit?

I have actually 5 more commits that I haven't pushed yet (to not overwhelm you). The current PR gets all working for FFmpeg 8, but for the current master, additional changes are needed which I can push as well:

Adapt for new config_components.asm file
Add support for compile-time SPIRV (.comp.spv)
Improve project file search (for files in ./compat
Fix dynamic includes
Provision for rename of spirv_compiler to spirv_library

All this doesn't make it easier to separate - I can split out a few simple ones. Not sure whether that makes sense, but I can try to get some of of the history.

[softworkz]

That's a bit tedious because it causes merge/rebase conflicts when adjacent lines are changing (like in template.rc) - this has bitten me already when preparing the PR

What this specifically means is: When I would separate all those commits with resource updates, the following would happen:

• You merge one
• All the other get into conflicted state
• I'd have to rebase all the remaining PRs to the new HEAD and force push each PR branch
• You merge the next one
• All the remaining ones get conflicted again
• etc.

[softworkz]

For libplacebo there are quite some adaptions required, do you want to create a repo for it (fork of libplacebo), then I could push/PR those changes there?
(uses VS Clang, meson and ninja, there's probably no chance to get this compiled with MSVC)

For libvpl, I've just used Visual Studios CMake support to build it, then copied libs and headers manually, but we could create a repo for this as well with adaptions (to auto-copy). I don't think it makes sense trying to turn this into a VS solution.

[softworkz]

Just to illustrate - when I cherry pick onto the current master branch, I get 4 conflcts (because the bin2c commit is missing):

---

It would be much easier for me when you could name something specific that you do not want - then I can carve that out of this PR.

[softworkz]

As noted: This PR is working with FFmpeg up to version 8 (894da5ca7d742e4429ffb2af534fcda0103ef593).
If you want to test with the current master, I can push the other 5 commits that are needed for this.