AndersonTorres
commented
10 months ago Open Atemu opened 10 months ago
AndersonTorres
commented
10 months ago 
OPNA2608
commented
10 months ago corrscope: Uses ffplay for export preview, which depends on withFullDeps.
Atemu
commented
10 months ago @OPNA2608 thanks. I see no reason why we shouldn't enable ffplay in the small variant. I'll take care of that :)
doronbehar
commented
10 months ago Atemu
commented
10 months ago @doronbehar thanks. Though as I mentioned, I will be moving all uses where the maintainers didn't object anyways ;)
justinas
commented
10 months ago 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.
Atemu
commented
10 months ago @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
commented
10 months ago 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
commented
10 months ago 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 encoderwithFdkAac ? withFullDeps && withUnfree # Fraunhofer FDK AAC de/encoderwithLibplacebo ? withFullDeps && !stdenv.isDarwin # libplacebo video processing librarywithWebp ? withFullDeps # WebP encoderMaybe:
withCelt ? withFullDeps # CELT decoder
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
commented
10 months ago 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
commented
10 months ago @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
commented
10 months ago @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
commented
9 months ago 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
commented
9 months ago @nagisa in that case, I think regular ffmpeg is warranted. Advanced users can override it with ffmpeg-full if they need it.
Atemu
commented
9 months ago 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
commented
8 months ago 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
commented
6 months ago @OPNA2608 thanks. I see no reason why we shouldn't enable ffplay in the small variant. I'll take care of that :)
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-fullbeing 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:
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-fullor, respectively, why regularffmepgis 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-headlessshould 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-fullusages; 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