Don't depend on ffmpeg-full #271863
Comments
Atemu
added
6.topic: closure size
|
|
|
|
@OPNA2608 thanks. I see no reason why we shouldn't enable ffplay in the small variant. I'll take care of that :) |
|
@doronbehar thanks. Though as I mentioned, I will be moving all uses where the maintainers didn't object anyways ;) |
|
Regarding 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 Jellyfin-ffmpeg flags vs Nix ffmpeg flavors
|
|
@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. |
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). |
|
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 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:
Maybe:
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! |
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. |
|
@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. |
|
@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.) |
|
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... |
|
@nagisa in that case, I think regular |
|
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. |
|
This is required for corrscope, also see NixOS#271863 (comment)
The regular ffmpeg now has SVT-AV1 and AOM support enabled by default. NixOS#271863 This effectively reverts 8a3191f
The regular ffmpeg now has SVT-AV1 and AOM support enabled by default. NixOS#271863 This effectively reverts 8a3191f
NixOS#271863 jellyfin-ffmpeg is a rebuild anyways, so we can simply cherry-pick the features that we actually need rather than smashing ffmpeg-full into it. These should be all the "special" features jellyfin expects of it. nvcodec and amf support are already enabled by default in regular ffmpeg.
NixOS#271863 jellyfin-ffmpeg is a rebuild anyways, so we can simply cherry-pick the features that we actually need rather than smashing ffmpeg-full into it. These should be all the "special" features jellyfin expects of it. nvcodec and amf support are already enabled by default in regular ffmpeg.
|
Okay, so life got in the way but with a year of delay, I think we can finally do this. Our ffmpeg now has AV1 encoders, webp support, the If you need any feature from ffmpeg-full that our current non-full ffmpegs currently do not offer, please speak up! I'm planning to remove all usages of ffmpeg-full from Nixpkgs after the 24.11 release. I'll perhaps also look into making ffmpeg-full an alias such that it will throw an eval error when used within Nixpkgs to prevent future usages. If you absolutely must have ffmpeg-full for some reason, please speak up about that reason so that we can fix it or find a workaround. |
NixOS#271863 jellyfin-ffmpeg is a rebuild anyways, so we can simply cherry-pick the features that we actually need rather than smashing ffmpeg-full into it. These should be all the "special" features jellyfin expects of it. nvcodec and amf support are already enabled by default in regular ffmpeg.
NixOS#271863 jellyfin-ffmpeg is a rebuild anyways, so we can simply cherry-pick the features that we actually need rather than smashing ffmpeg-full into it. These should be all the "special" features jellyfin expects of it. nvcodec and amf support are already enabled by default in regular ffmpeg.
NixOS#271863 jellyfin-ffmpeg is a rebuild anyways, so we can simply cherry-pick the features that we actually need rather than smashing ffmpeg-full into it. These should be all the "special" features jellyfin expects of it. nvcodec and amf support are already enabled by default in regular ffmpeg.
|
We still need cudaLLVM for frigate with nvidia hwaccel. #344114 If that is not in the cards, then we must provide ffmpeg-full to users who configure nvidia hwaccel. |
|
I included it in #354952. |
With NixOS#354952, the regular ffmpeg-headless should now have all the deps required for frigate to make use of hardware acceleration on all hardware. This is progress towards NixOS#271863 This reverts commit 7e33e47. This may be surprising as it's quite soon after 7e33e47 was merged but we decided in NixOS#357717 (comment) to merge it quickly to unbreak master and backport to 24.11. Non-full ffmpeg can be pursued in master using a simple revert which is where we are now.
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:nixpkgs/pkgs/development/libraries/ffmpeg/generic.nix
Lines 7 to 22 in e2c4c9e
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
The text was updated successfully, but these errors were encountered: