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.

[Sibras]

Ive cherry picked some of the commits and added them to master (fixed the merge conflicts as I went)

Ill review and cherry pick the remaining commits as I get time.

My current reservations are:

• bin2c and shader2c should probably be compiled from the ffmpeg source being processed as they are periodically updated and could become out of date (also avoids licensing issues due to distributing binaries)
• Can we just have a single shader2c props/targets/etc instead of 2 for spirv and opencl. They dont really need the file extension specifier as they are explicitly set so 1 should be usable for both
• Using some of the functionality of the nvidia provided cuda targets so that we can get include file tracking and compilation on change etc. Also the default ptx arguments for sm versions might be useful to allow changing

[softworkz]

bin2c and shader2c should probably be compiled from the ffmpeg source being processed as they are periodically updated and could become out of date (also avoids licensing issues due to distributing binaries)

bin2c isn't changed regularly and source2c (not shader2c) doesn't even exist in ffmpeg code. This is done differently there.

Can we just have a single shader2c props/targets/etc instead of 2 for spirv and opencl. They dont really need the file extension specifier as they are explicitly set so 1 should be usable for both

The files in the vcxprojects are included like this:

<SPIRVSource2C Include="..\..\source\ffmpeg\libavfilter\vulkan\bwdif.comp">

and in the project properties, you can make adjustments for all files of a certain type:

In the latest master, there's even once another variation, because the files are spirv-compiled directly during compilation, so it gets once another set of files:

This is the proper way to do it with MSBuild. I see not reason to start messing around.

Using some of the functionality of the nvidia provided cuda targets so that we can get include file tracking and compilation on change etc. Also the default ptx arguments for sm versions might be useful to allow changing

This can be done already: