Don't depend on ffmpeg-full

[Atemu]

Issue description

In the process of cleaning up ffmpeg and merging the ffmpeg and ffmpeg-full derivations, I have decided that uses inside Nixpkgs should use the regular ffmpeg; ffmpeg-full being reserved for advanced users to install themselves due to its significantly larger closure:

https://github.com/NixOS/nixpkgs/blob/e2c4c9eafd27af8e5c5e4706834368eda9235470/pkgs/development/libraries/ffmpeg/generic.nix#L7-L22

However, some packages depended and still depend on ffmpeg-full and I have not touched those. This is about to change. I've compiled a list of packages that I will rip ffmpeg-full out of:

• liquidsoap
• corrscope
• obs-studio
• vokoscreen
• ffcast
• escrotum
• audiobookshelf
• audiobookshelf
• jellyfin-ffmpeg
• ffmpegthumbnailer
• handbrake
• imagination
• haruna
• video-trimmer
• peek
• restream
• tone
• tonelib-gfx
• tonelib-jam
• tonelib-zoom
• tonelib-metal
• tonelib-noisereducer
• MIDIVisualizer
• arcanPackages

Of course, some usages of ffmpeg-full might have good reasons behind them that I'm not aware of.

If you've been pinged, you are a maintainer of one of these packages. Please reply why you need ffmpeg-full or, respectively, why regular ffmepg is not enough for your needs such that we can make it fit your needs.

We might also allow some exceptions for ffmpeg-full usage should you require an ffmpeg feature that comes with a huge closure size.

Please either shoot a reply with the reason or react with a rocket if your package doesn't actually require ffmpeg-full. (Or remove yourself from its maintainers if you no longer intend to maintain it.)

While you're at it, please also check whether your package requires ffmpeg's headed playback/capture support (i.e. xorg, wayland, SDL, pipewire) or whether the headless variant is enough. Except for these headed components, ffmpeg-headless should be the exact same.

Additionally, if your package is pinned to i.e. ffmpeg_4 or ffmpeg_5, please also check whether your package actually still requires the older ABI.

You have one month to reply. After that I'll remove ffmpeg-full usages; whether it breaks your package or not.

Maintainer ping

@AndersonTorres @Anton-Latukha @austinbutler @cpcloud @dali99 @dan4ik605743 @deviant @doronbehar @ehmry @ericdallo @jagajaga @jb55 @jojosch @justinas @jvanbruegge @kashw2 @league @materusPL @MP2E @OPNA2608 @orivej @puffnfresh @rasendubi @sikmir @wmertens

[AndersonTorres]

• Arcan: https://github.com/NixOS/nixpkgs/pull/270301

[OPNA2608]

corrscope: Uses ffplay for export preview, which depends on withFullDeps.

https://github.com/NixOS/nixpkgs/blob/e2c4c9eafd27af8e5c5e4706834368eda9235470/pkgs/development/libraries/ffmpeg/generic.nix#L131

[Atemu]

@OPNA2608 thanks. I see no reason why we shouldn't enable ffplay in the small variant. I'll take care of that :)

[doronbehar]

• https://github.com/NixOS/nixpkgs/pull/271876

[Atemu]

@doronbehar thanks. Though as I mentioned, I will be moving all uses where the maintainers didn't object anyways ;)

[justinas]

Regarding jellyfin-ffmpeg: I went over what ffmpeg --version in their official Docker images reports being configured with, and summarized below in the expandable table.

A few libraries seem to be missing altogether from Nix's FFmpeg, although some of them might not be essential for normal use of Jellyfin.

Jellyfin should not need the "head" support (so we could build without FFplay, Xcb, etc.), but it does need some stuff that relates to graphics accelerators (CUDA, OpenCL, etc.) to facilitate hardware-accelerated transcoding.

The few interesting cases are where codecs such as AAC and WebP are gated behind the full flavor. Other than that, we currently require full for GPU acceleration stuff such as libplacebo, opencl, vulkan, as well as a few other libs I'm not familiar with.

Jellyfin-ffmpeg flags vs Nix ffmpeg flavors

| Jellyfin-ffmpeg configure flag | Nix ffmpeg equivalent | Nix FFmpeg type | | --------------------------------- | --------------------- | ---------------- | | --arch=amd64 | | | | --disable-doc | withDocumentation? | inc. in headless | | --disable-ffplay | buildFfplay = false | inc. in full | | --disable-libxcb | withXcb* = false | inc. in full | | --disable-ptx-compression | N/A, added in j-f.nix | | | --disable-sdl2 | withSdl2 = false | inc. in small | | --disable-static | N/A | | | --disable-xlib | withXlib = false | inc. in full | | --enable-amf | N/A? | | | --enable-chromaprint | N/A, added in j-f.nix | | | --enable-cuda | withCuda | full | | --enable-cuda-llvm | withCudaLLVM | full | | --enable-cuvid | withNvdec | headless | | --enable-ffnvcodec | N/A | | | --enable-gmp | N/A | | | --enable-gnutls | withGnutls | headless | | --enable-gpl | withGPL | any | | --enable-libass | withAss | headless | | --enable-libbluray | withBluray | full | | --enable-libdav1d | withDav1d | headless | | --enable-libdrm | withDrm | headless | | --enable-libfdk-aac | withFdkAac | full | | --enable-libfontconfig | withFontconfig | headless | | --enable-libfreetype | withFreetype | headless | | --enable-libfribidi | withFribidi | full | | --enable-libmfx | withMfx | full | | --enable-libmp3lame | withMp3lame | headless | | --enable-libopenmpt | withOpenMpt | full | | --enable-libopus | withOpus | headless | | --enable-libplacebo | withLibplacebo | full | | --enable-libshaderc | N/A | | | --enable-libsvtav1 | withSvtav1 | headless | | --enable-libtheora | withTheora | headless | | --enable-libvorbis | withVorbis | headless | | --enable-libvpx | withVpx | headless | | --enable-libwebp | withWebp | full | | --enable-libx264 | withX264 | headless | | --enable-libx265 | withX265 | headless | | --enable-libzimg | withZimg | headless | | --enable-libzvbi | N/A | | | --enable-lto | N/A | | | --enable-nvdec | withNvdec | headless | | --enable-nvenc | withNvenc | headless | | --enable-opencl | withOpencl | full | | --enable-shared | N/A | | | --enable-vaapi | withVaapi | headless | | --enable-version3 | withGPLv3 | any | | --enable-vulkan | withVulkan | full | | --extra-libs=-lfftw3f | ??? | | | --extra-version=Jellyfin | | | | --prefix=/usr/lib/jellyfin-ffmpeg | | | | --target-os=linux | | |

[Atemu]

@justinas thanks a bunch.

With cuda we'll have to see how much it bloats closure size. Is it actually required though? HW transcode should only require cuvid, no?

I don't think you need opencl to HW transcode either.

Most of the other stuff is either unimportant, should be enabled in headless too or is proprietary AFAICT.

We could also think about making jellyfin's fork a regular variant of the ffmpeg package.

[justinas]

With cuda we'll have to see how much it bloats closure size. Is it actually required though? HW transcode should only require cuvid, no?

I don't think you need opencl to HW transcode either.

Jellyfin's hardware acceleration covers all the major GPUs, and OpenCL is one of the options for HDR-to-SDR tonemapping on Intel and AMD hardware (I was previously told to add opencl for this reason).

CUDA was also previously requested by the upstream maintainers, and seems to be used for tonemapping, subtitle burn-in, etc.

@nyanmisaka could probably answer any jellyfin-ffmpeg question better than me :slightly_smiling_face: (hope they don't mind the mention).

[dali99]

liquidsoap is a framework for interacting with media tools programmatically. It's very hard to know what features consumers use and so the package has (at least until now) aimed at being as feature complete as possible.

The closure of the package is 2.2G, switching to ffmpeg or ffmpeg-headless makes that 1.7G.

Looking at the ffmpeg package commit you've provided I've made a list of features gated behind full which I think are reasonable for liquidsoap users to care about:

• withAom ? withFullDeps # AV1 reference encoder
• withFdkAac ? withFullDeps && withUnfree # Fraunhofer FDK AAC de/encoder
• withLibplacebo ? withFullDeps && !stdenv.isDarwin # libplacebo video processing library
• withWebp ? withFullDeps # WebP encoder

Maybe:

• withCelt ? withFullDeps # CELT decoder
  • I've at least seen this mentioned while working with liquidsoap

I don't know much about HW transcoding, but I imagine it's important for us as well, whatever you land on in the discussion above.

I'd argue an AV1 encoder should be in the default ffmpeg package regardless of what liquidsoap needs.

Again it's hard to know what all users of liquidsoap use, but since nix makes it easy to override I think we can move forward to replace the dependency. Thanks for the initiative!

[nyanmisaka]

With cuda we'll have to see how much it bloats closure size. Is it actually required though? HW transcode should only require cuvid, no? I don't think you need opencl to HW transcode either.

Jellyfin's hardware acceleration covers all the major GPUs, and OpenCL is one of the options for HDR-to-SDR tonemapping on Intel and AMD hardware (I was previously told to add opencl for this reason).

CUDA was also previously requested by the upstream maintainers, and seems to be used for tonemapping, subtitle burn-in, etc.

@nyanmisaka could probably answer any jellyfin-ffmpeg question better than me 🙂 (hope they don't mind the mention).

CUDA and OpenCL are act as the off-screen 2D image processor to run the programmable kernel/shader to modify (pixel format conversion/HDR tone-mapping/subtitle-burn-in) the HW decoded video before sending it to the HW encoder. Imagine not having OpenGL on a Linux desktop, or DirectX on Windows, it would be a disastrous GUI experience.

[Atemu]

@dali99 Do usages of libquidsoap also include interacting with headed components (SDL, pipewire, xorg etc.)? If so, I think it should depend on the regular ffmpeg by default with an option to use ffmpeg-full.

Enabling celt, webp etc. is a no-brainer as long as they don't bloat closure by many megabytes.

[Atemu]

@nyanmisaka thanks for the input.

Given that jellyfin appears to have put in a lot of work specifically to make heavy use of accelerated processing, I think a dependence on a fully-featured variant is justified. We'll either make an exception or introduce a jellyfin/hwaccel ffmpeg variant (jellyfin-ffmpeg uses a forked source anyways).

(You can unsubscribe from this thread now if you'd like, we'll ping you directly should further questions arise.)

[nagisa]

liquidsoap definitely has functions to just "output" audio to ALSA, JACK, etc. This functionality is commonly suggested to be used during development and testing of liquidsoap pipelines. Now whether that requires headed components, I can’t really say...

[Atemu]

@nagisa in that case, I think regular ffmpeg is warranted. Advanced users can override it with ffmpeg-full if they need it.

[Atemu]

We might also be able to enable opencv in regular ffmpeg if we switched opencv to ffmpeg-headless. I'm unsure whether opencv needs headed components though. If anyone knows, let me know.

[orivej]

I've compiled a list of packages that I will rip ffmpeg-full out of

tonelib-* packages do not depend on any variant of ffmpeg.

[SuperSandro2000]

@OPNA2608 thanks. I see no reason why we shouldn't enable ffplay in the small variant. I'll take care of that :)

https://github.com/NixOS/nixpkgs/pull/296128