Add vulkan support to ffmpeg

[th0ma7]

Description

Add vulkan support to ffmpeg

Follow-up to: #6812

Additional changes

• Disable CMAKE_BUILD_WITH_INSTALL_RPATH and fix runpath so binaries are relocatable and executable "in-place" without needing to add extra LD_LIBRARY_PATH by using -DCMAKE_INSTALL_RPATH='$$ORIGIN/../lib'.
• Clean-up build node of unecessary default Ubuntu package set to allow more disk space for spksrc builds

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• Bug fix
• New Package
• Package update
• Includes small framework changes
• This change requires a documentation update (e.g. Wiki)

[th0ma7]

@mreid-tt and @hgy59 I've been struggling since a long time with two things specifically with CMake:

1. Why build-time executables fails to run properly i.e. NATIVE binaries built during the build that are used within the build to proceed?
2. Why native binaries cannot be ran as-is?

I believe I have now solved them both! 🚀

1. Disable CMAKE_BUILD_WITH_INSTALL_RPATH ... this causes the build-time executables to use the same RPATH as the cross-compiled bin|lib expected to run in the destination installation path causing them to fail when executed as unable to find their relative native libraries they were built against.
2. in spksrc.native-cmake.mk Fix runpath so binaries are relocatable and executable "in-place" without needing to add extra LD_LIBRARY_PATH by using -DCMAKE_INSTALL_RPATH='$$ORIGIN/../lib' which translate to:

spksrc@spksrc13:~/vulkan-ffmpeg2/spksrc/native$ readelf -d llvm-14.0-build/work-native/install/usr/local/bin/llvm-ar

Dynamic section at offset 0xed70 contains 30 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libLLVM-14.so]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib]

This PR allowed me to expose this in full, and finally put this to a close :)

@hgy59: Mind preparing an updated native/llvm-14.0 package as this is now fixed and upgraded to LLVM-14.0.6? thnx!

[th0ma7]

@mreid-tt and @hgy59 I was able (thnx to claudeai) to update the build.yml workflow file. The idea was: I know my issue is a storage capacity problem as the job fails but look idle, but how can i monitor this and workaround that?

With the proposed changes in here we now have:

1. Diagnostics zip files are now being generated from uploaded actual build and status logs along with disk space usage. See: https://github.com/SynoCommunity/spksrc/actions/runs/20485467039
2. I've now added a clean-up pre-job to free-up space on the node prior to initiating the actual build.
   Before (no cleanup, prior to build):

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        72G   56G   16G  78% /
tmpfs           7.9G   84K  7.9G   1% /dev/shm
tmpfs           3.2G  1.2M  3.2G   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sdb16      881M   62M  758M   8% /boot
/dev/sdb15      105M  6.2M   99M   6% /boot/efi
/dev/sda1        74G  4.1G   66G   6% /mnt
tmpfs           1.6G   12K  1.6G   1% /run/user/1001

After the cleanup (prior to build):

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        72G   22G   51G  30% /
tmpfs           7.9G   84K  7.9G   1% /dev/shm
tmpfs           3.2G  1.2M  3.2G   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda16      881M   62M  758M   8% /boot
/dev/sda15      105M  6.2M   99M   6% /boot/efi
/dev/sdb1        74G   28K   70G   1% /mnt
tmpfs           1.6G   12K  1.6G   1% /run/user/1001

next:

1. update the disk space utilisation to run du -h directly on spk directories where build occurred.

Honestly I find this really neat 🚀

[th0ma7]

@hgy59 friendly reminder if you have a moment for uploading an updated native llvm 14.0.6 package when your cycles allows it! no rush, its christmas 🎅

[olivierplichta]

Good evening, I'd be happy to help you, however, I should warn you: I'm quite familiar with DSM and the Synology environment, and I can manage a little with the command line, but English isn't my native language (I'm French). I can try to help you, and I'll try to be responsive, but I can't spend all my time on my computer (I own a DS425+). Regarding the alternative drivers that have been made available to enable hardware transcoding under Plex, I have a request: many users believe the problem has been completely resolved, but unfortunately, this is not the case. With 4K HEVC videos, tone mapping does not work, and hardware transcoding fails; the NAS then resorts to software transcoding, which saturates the CPU. For all other video formats (1080p, 720p, etc., whether H264 or H265), there are no tone mapping issues. Perhaps you could also help us resolve this problem. I would very much like hardware transcoding to work on the DS425+ in the same way as on the DS920+, 720+, 1520+, etc.

[th0ma7]

Good evening, I'd be happy to help you, however, I should warn you: I'm quite familiar with DSM and the Synology environment, and I can manage a little with the command line, but English isn't my native language (I'm French). I can try to help you, and I'll try to be responsive, but I can't spend all my time on my computer (I own a DS425+). Regarding the alternative drivers that have been made available to enable hardware transcoding under Plex, I have a request: many users believe the problem has been completely resolved, but unfortunately, this is not the case. With 4K HEVC videos, tone mapping does not work, and hardware transcoding fails; the NAS then resorts to software transcoding, which saturates the CPU. For all other video formats (1080p, 720p, etc., whether H264 or H265), there are no tone mapping issues. Perhaps you could also help us resolve this problem. I would very much like hardware transcoding to work on the DS425+ in the same way as on the DS920+, 720+, 1520+, etc.

Bonjour @olivierplichta - il s'avère que ma langue première est aussi le français 🤷‍♂️ (TZ: UTC−5). Et ma contribution ici est un passe-temps et non pas une obligation, donc idem, mes cycles disponibles et temps de réponse varient selon ma disponibilité.

I may be able to assist, unsure up to what point as I have no clue of what alternative drivers you are referring about, unclear to me if these are the one I package within the SynoCommunity? More info would help.

I suggest we have a longer chat over Discord - you'll be able to find me, same username, on the synocommunity server (there's even a french channel :), link is on our main github page https://github.com/SynoCommunity/spksrc

In the meantime, feel free to have a read at our ffmpeg wiki page https://github.com/SynoCommunity/spksrc/wiki/FAQ-FFmpeg and if interested you can try out the update I've been working on part of this PR in the check tab under Build -> Summary - latest run is here: https://github.com/SynoCommunity/spksrc/actions/runs/20643006573 You can download the x64 package and install the synocli-videodriver followed by the ffmpeg7 package (all within the zip build file).

And thxn for chiming in, your assistance is much welcomed!

[hgy59]

@hgy59 friendly reminder if you have a moment for uploading an updated native llvm 14.0.6 package when your cycles allows it! no rush, its christmas 🎅

Ok, you've already done it...