ffmpeg5 + ffmpeg6 packages

[th0ma7]

Description

FFMPEG5 Jellyfin optimized package + FFMPEG6 default

Fixes #5085, #5421

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]

@hgy59 and @mreid-tt and all, looking for help!

Having issues specifically with x86_64 and i686 builds... I've created an ffmpeg bug issue at https://trac.ffmpeg.org/ticket/10219 with hope to find a solution.

Getting multiple undefined reference to only on those two archs :

LD	ffmpeg_g
LD	ffprobe_g
libavcodec/libavcodec.so: undefined reference to `ff_h264chroma_init_x86'
libavfilter/libavfilter.so: undefined reference to `ff_spp_init_x86'
libavcodec/libavcodec.so: undefined reference to `ff_ttaencdsp_init_x86'
libswresample/libswresample.so: undefined reference to `swri_audio_convert_init_x86'
...

Hints at solving this issue would be much appreciated 🤷

[hgy59]

Hints at solving this issue would be much appreciated 🤷

Sometime it helps to force cross compilation for i686 (see cross/erlang/Makefile) - just guessing...

[nyanmisaka]

Maybe nasm is too old for the new ffmpeg, which passes the configure check but there's no X86ASM in the ffmpeg5 build logs. Thus all ff_*_x86 asm functions are missing at LD stage. And asm was disabled in ARM builds so those are not affected.

[nyanmisaka]

Disabling x86 asm can be a stopgap but it causes software decoders and encoders to be extremely slow.

Better to figure out how to re-enable it later. The low-power chips on Synology devices can benefit a lot from this.

[th0ma7]

Disabling x86 asm can be a stopgap but it causes software decoders and encoders to be extremely slow.

Better to figure out how to re-enable it later. The low-power chips on Synology devices can benefit a lot from this.

@Nyaran thnx for the pointer. Indeed disabling x86 asm solved the immediate issue. I've updated the ffmpeg track issue to reflect this in hope to get some help.

[nyanmisaka]

I wonder why asm was disabled in arm and ppc?

This is unlikely to be an upstream issue since ffmpeg 5.0 was released more than a year ago.

Maybe --x86asmexe=/path/to/nasm helps.

[th0ma7]

I wonder why asm was disabled in arm and ppc?

This pre-date me taking over the maintenance of ffmpeg. I never touched that portion of the build process. Now that this isn't working all right for x86 neither, perhaps it's a good time to review it... similarly, asm is only available for x86 for x265 as well.

Maybe --x86asmexe=/path/to/nasm helps.

I tried that and it didn't worked out neither.

[nyanmisaka]

NEON asm works for arm processors. Those asm code were written for some DSP and decoders.

https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/arm/Makefile

  --disable-armv5te        disable armv5te optimizations
  --disable-armv6          disable armv6 optimizations
  --disable-armv6t2        disable armv6t2 optimizations
  --disable-vfp            disable VFP optimizations
  --disable-neon           disable NEON optimizations

[th0ma7]

@nyanmisaka I've been playing more & more with ASM on various front and really, it works just well for aarch64 but it simply isn't called at all for i686 and x86_64 even though it normally should... w e i r d 🤷

[hgy59]

This is not a good idea. I propose to keep SPK_NAME = ffmpeg
Otherwise this is a new package and you can start with SPK_REV = 1
But then all packages depending on ffmpeg (SPK_DEPENDS = "ffmpeg") will not use further updates (and we will need to keep the latest ffmpeg package in the repository).

SPK_NAME should stay ffmpeg, only DISPLAY_NAME may be changed to ffmpeg4 (or ffmpeg 4).

[th0ma7]

The issue is more complex than that...

The github build scripts also refers to ffmpeg for it to be pre-process and keept prior to building dependent packages in order to re-use existing libraries. That also needs fixing so a similar behavior is kept for ffmpeg5 and ffmpeg6 which adds complexity as comskip, chromaprint and tvheadend are in various stages of porting over to ffmpeg >= 5.x.

With that in mind, and based on python3 experience, I decided to rename it all to ffmpeg4 along with adjusting dependent packages. Once all dependent packages are migrated over the new naming scheme I'll then be able to start porting them over to a newer ffmpeg. Adding to the blur is jellyfin which requires ffmpeg 5.x for it to run smoothly (and to which there isn't any spk dependencies up until now 🤷 ).

Renaming it all to be ffmpeg<version> is to me the best route as they will have to be maintained in parallel for a while. As for SPK_REV, I can probably switch it to 1 but on the other hand if gives the idea that ffmpeg4 version 48 really is the update from ffmpeg version 47. So I'd rather keeping it as-is.

[hgy59]

@th0ma7 you can name all folders ffmpeg4 only the SPK_NAME sould stay ffmpeg.
This is similar to the python2 package, where SPK_NAME is still python.

[th0ma7]

@hgy59 and @nyanmisaka finally found the build issue... to which we already had a fix for since 4.x era. It hapens that configure script and ffbuild/common.mak uses ARCH variable which in turns gets polluted by spksrc framework usage of ARCH variable... Re-using existing https://github.com/SynoCommunity/spksrc/blob/master/cross/ffmpeg/patches/0001-replace-arch-env-by-ffmpeg_arch.patch solved the matter.

I can now finally move on to next steps 🚀

[nyanmisaka]

@th0ma7 Nice to hear that. I've seen that patch but didn't understand what it does. We are also updating patches for 6.0 but it's not finalized yet.

[th0ma7]

@nyanmisaka if I may recommend, would be nice to keep patches for older ffmpeg releases. I'm still using v4 and now v5 versions of the patches. Pertaining to v6, any insight as of when the patches may be ready? As I'll probably wait for that before releasing it.

[nyanmisaka]

@th0ma7 4.4.x is for the old Jellyfin 10.7, it's best to keep the current patches as they are. Downstream only needs to pull the corresponding version of the patch series from the debian/patches folder.

5.1.x will continue to be maintained for a long time since it is LTS and is required by Jellyfin 10.8.

6.x slightly breaks compatibility with Jellyfin 10.8, we will release a new Jellyfin version to adapt it. Before that make the Jellyfin package depend on ffmpeg5.

[nyanmisaka]

Just a FYI some FFmpeg options and runtimes used by Jellyfin are not available in spksrc.

Intel Compute-Runtime
https://github.com/intel/compute-runtime
# required by OpenCL tone-mapping on Intel GPU
# build time deps: 
 * libva https://github.com/intel/libva
 * gmmlib https://github.com/intel/gmmlib
 * level-zero https://github.com/oneapi-src/level-zero
 * intel-graphics-compiler https://github.com/intel/intel-graphics-compiler

--enable-opencl
# required by OpenCL tone-mapping on Intel GPU
# build time deps:
 * headers: https://github.com/KhronosGroup/OpenCL-Headers
 * loader: https://github.com/KhronosGroup/OpenCL-ICD-Loader

--enable-libvpl
# [optional] successor of the libmfx, used by FFmpeg 6+
# build time deps: https://github.com/oneapi-src/oneVPL
# run time:
 * UHD6xx and older: libmfxhw64.so* https://github.com/Intel-Media-SDK/MediaSDK
 * UHD7xx, Xe and newer: libmfx-gen.so* https://github.com/oneapi-src/oneVPL-intel-gpu

--enable-ffnvcodec \
--enable-cuda \
--enable-cuda-llvm \
--enable-cuvid \
--enable-nvdec \
--enable-nvenc \
--disable-ptx-compression
# required by hardware transcoding on NVIDIA GPU (jellyfin 10.8 requires n11.0.10.2+)
# build time deps: https://github.com/FFmpeg/nv-codec-headers

[th0ma7]

@nyanmisaka thnx for sharing this, that will save me quite a bit of time.

From the get go only a fraction of this will be available to all platforms.

Intel:
I already reached the end of the road for gcc<=4.9.* in regards to intel-media-driver which is a mandatory requirement to intel-media-sdk. Therefore I doubt that level-zero, IGC or oneVPL will ever build for DSM6 but still worth a try. Althought that should be relatively feasible for DSM7+ which uses gcc-7.5 and newer.

nVidia:
I have no clue where to start with... additional pointers or examples would be much appreciated. For instance, does it only need the nv-codec-headers for it to enable ffmpeg build options? Also I see there are other branches available for older driver versions which lead to the need of knowing what version Synology uses in theses case to match things up (I own a few Syno NAS but none using nvidia so can't really test or find out).

[nyanmisaka]

Intel: I already reached the end of the road for gcc<=4.9.* in regards to intel-media-driver which is a mandatory requirement to intel-media-sdk. Therefore I doubt that level-zero, IGC or oneVPL will ever build for DSM6 but still worth a try. Althought that should be relatively feasible for DSM7+ which uses gcc-7.5 and newer.

https://gcc.gnu.org/projects/cxx-status.html#cxx14

cpp14 is required by the VPL runtime, which is not fully supported in gcc-4.9 but you can still give it a try.

nVidia: I have no clue where to start with... additional pointers or examples would be much appreciated. For instance, does it only need the nv-codec-headers for it to enable ffmpeg build options? Also I see there are other branches available for older driver versions which lead to the need of knowing what version Synology uses in theses case to match things up (I own a few Syno NAS but none using nvidia so can't really test or find out).

Compiling cuda kernel requires cpp14 too, this part is handled by clang instead of the nvcc that comes with cuda toolkit.

So --enable-cuda-llvm indicates that clang 3.4+ is required https://clang.llvm.org/cxx_status.html

I'm not sure if clang is available in Syno toolchains. You can lower the priority of supporting this as not many people use NVIDIA GPUs on Syno. Other than that you just need to make install the nv-codec-headers header files.

[th0ma7]

This should now good for merging. I'll take one last stab at it upon my return and do further testing.

If @hgy59 you can have one last look at it would be nice. My main fear is at filling up our server online...

[nyanmisaka]

@th0ma7 We updated our patches with some tiny fixes. It'd be great if you can pull the them again before merging.

• 5.1: https://github.com/jellyfin/jellyfin-ffmpeg/tree/jellyfin-5.1
• 6.0: https://github.com/jellyfin/jellyfin-ffmpeg/tree/jellyfin

[th0ma7]

@th0ma7 We updated our patches with some tiny fixes. It'd be great if you can pull the them again before merging.

• 5.1: https://github.com/jellyfin/jellyfin-ffmpeg/tree/jellyfin-5.1
• 6.0: https://github.com/jellyfin/jellyfin-ffmpeg/tree/jellyfin

Sure, will do upon my return.

[th0ma7]

We updated our patches with some tiny fixes. It'd be great if you can pull the them again before merging.

@nyanmisaka all patches are now updated. Finalizing the testing and should be ready for publishing before end of week.

[hgy59]

@th0ma7 there must be something wrong with the changes in the prepare step of the github build action introduced with this PR.

In #5677 I only changed files in native/mono, cross/mono and spk/mono but now it downloads and builds ffmpeg.
https://github.com/SynoCommunity/spksrc/actions/runs/4564982620/jobs/8055461639