| Git Clone URL: | https://aur.archlinux.org/lib32-ffmpeg.git (read-only, click to copy) |
|---|---|
| Package Base: | lib32-ffmpeg |
| Description: | Complete solution to record, convert and stream audio and video (32 bit) |
| Upstream URL: | http://ffmpeg.org |
| Licenses: | GPL-3.0-only |
| Conflicts: | lib32-libffmpeg |
| Provides: | libavcodec.so, libavdevice.so, libavfilter.so, libavformat.so, libavutil.so, libpostproc.so, libswresample.so, libswscale.so |
| Replaces: | lib32-libffmpeg |
| Submitter: | lano1106 |
| Maintainer: | oxalin |
| Last Packager: | oxalin |
| Votes: | 37 |
| Popularity: | 0.014864 |
| First Submitted: | 2013-05-18 04:43 (UTC) |
| Last Updated: | 2024-09-27 17:48 (UTC) |
And I would also remove lib32-libbluray support.
Consumer x86_64 CPU's entered the marked a few years earlier than Blu-ray disc players. By the time the format wars between it and HD-DVD was over in 2009, virtually everyone was using x86_64 desktops and laptops.
Therefore I see no need whatsoever to provide legacy lib32 Blu-ray support for suspected closed-source 32-bit-only applications that in all likelyhood don't exist without having been superseded by the 64-bit build of the same.
The lib32-vmaf library for "perceptual video quality assessment algorithm" used in analyzing and testing the encoding quality is also safe to drop from this 32-bit build my view.
Also, some people reported build problems with lib32-gsm since Jan 2023.
I can wholeheartedly recommend that you turn off that dependency as well in this build. I cannot imagine anyone wanting to use the old, low-quality GSM mobile audio format, in a 32-bit software or otherwise. VoIP applications are available in 64-bit and support much better codecs as well, and VoIP-to-POTS services also allow other codecs.
(And GSM compressed audio recordings can still be used with 64-bit multimedia software.)
Hi,
I recommend that you drop and disable using lib32-openjpeg2. I did some digging, and it turns out it is only used here for JPEG2000 video stream, but FFMPEG has its own internal JPEG2000 decoder/encoder.
I haven't even see that format ever used in video. But even if someone for some reason has a 32-bit software that needs this, ffmpeg can work for them without the external openjpeg2 codec. (Also I've seen benchmarks claiming that FFMPEG's own JPEG2000 codec is faster.)
This is known, sorry. It was late last night and I was working on lib32-zimg at the same time. Testing locally worked, but not from online, which I hadn't tested until I finished working on zimg.
A patch to relax the version check is ready, I just need to push when I'll get back from work.
Yay refuses to upgrade the lib32-ffmpeg package, it would give me this error and bail:
-> Could not find all required packages:
lib32-libffmpeg=6.0 (Wanted by: lib32-ffmpeg)
Attempting to install the package directly yields the following warning:
warning: cannot resolve "lib32-libffmpeg=6.0", a dependency of "lib32-ffmpeg"
:: The following package cannot be upgraded due to unresolvable dependencies:
lib32-ffmpeg
:: Do you want to skip the above package for this upgrade? [y/N] Selecting Y or N makes no difference, pacman would bail over lib32-libffmpeg missing despite it being there.
I also already tried hacking the MAKEPKG file to make the required package lib32-libffmpeg-2 since that is apparently the real name of the packages generated, but it makes no difference.
Edit 2: Mangled with the PKGBUILD file some more and removed the =6.0 from the dependency list. Package finally installs (is the =6.0 option even doing what it's supposed to do?)
Yep, that worked for me too. Thanks!
that fixed it. thanks for your time.
This should be fixed. Cherry-picked commit eb0455d646 which should solve the missing extensions.
Temporary fix to be removed once FFMPEG release a new version.
Pinned Comments
oxalin commented on 2024-04-09 22:05 (UTC)
For those wondering: I intentionally keep this package as close to the native package as possible, to the extent of the available dependencies. FFMPEG package sees a lot of modifications through time and I prefer to follow the changes applied to the native PKGBUILD as much as possible. The more it goes, the more flags are added and the more often we need to cherrypick commits (until a new release comes in).
This means I'll keep the dependencies around even if there is no obvious usecase for them.
Also, since openjpeg2 is still used with the native package, I'll also keep it around. Last thing I read about the JPEG2000 internal decoder was that it was faster, but that it was still introducing errors in the rendering. This probably explains why it is still enable in the native package. I look at it once in a while and things may have evolved since, but a quick checkup didn't bring up any tangible answer.
Now, if someone would like to take the ownership of this package, I would be more than pleased to hand it over. The same goes for any related packages that I maintain mostly for FFMPEG. lib32-libffmpeg and lib32-ffmpeg could be merged back together to simplify its maintenance.
Let me know if this is something you're interested in.
oxalin commented on 2018-02-25 07:37 (UTC) (edited on 2020-05-25 15:55 (UTC) by oxalin)
About GPG, it is up to you to import the missing public key. If you receive an error about it, this is ffmpeg's project public key. Something like the following should do the trick: gpg --recv-keys B4322F04D67658D8