Package Details: lib32-ffmpeg 2:7.0.2-3

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)

Required by (292)

Sources (2)

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

Latest Comments

« First ‹ Previous 1 .. 15 16 17 18 19 20 21 Next › Last »

mokkurkalve commented on 2016-04-21 11:06 (UTC)

Cannot install the package after build. Getting following message, what's up? loading packages... resolving dependencies... warning: cannot resolve "libvpx.so=3-32", a dependency of "lib32-ffmpeg" :: The following package cannot be upgraded due to unresolvable dependencies: lib32-ffmpeg

JonnyJD commented on 2016-01-30 10:11 (UTC)

I uploaded the 2.8.5 PKGBUILD. This fixes the security issue and I removed the workaround (disabled demuxer). Thanks alucryd.

JonnyJD commented on 2016-01-13 22:34 (UTC)

I uploaded a new PKGBUILD with an *important security fix*. I advise everbody to either update or uninstall the package (in case you have problems building). See: https://bugs.archlinux.org/task/47738 Thanks FadeMind for informing me.

JonnyJD commented on 2016-01-09 13:34 (UTC)

Finally updated to 2.8.4 The package now checks the signature of the source. If you have any problems regarding this, make sure you have a keyserver and possibly "keyserver-options auto-key-retrieve". See https://wiki.archlinux.org/index.php/Makepkg#Signature_checking for further details.

JonnyJD commented on 2015-12-02 17:15 (UTC)

Updated to 2.8.3. I didn't build against libdcadec, since there is no 32 bit version in AUR (keep me updated if one is created).

JonnyJD commented on 2015-11-19 12:15 (UTC)

Updated to 2.8.2. In contrast to the 64 bit version I didn't build against stab.vid, since there is currently no 32 bit package available.

JonnyJD commented on 2015-07-24 14:39 (UTC)

@shamanmonkey: lib32-libx264-stable-git is in general compatible. However, that package isn't recent and you were probably running into the exact same problem as @mokkurcalve at https://aur.archlinux.org/packages/lib32-ffmpeg/ (possibly the other way around when you are running recent git and haven't run "pacman -Syu" in a while) problem in short: libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_148' Note that 148 there which is always the current API version of "libx264". This doesn't necessarily match the API version of "lib32-libx264". solution: the API version (currently 148) of "libx264" and "lib32-libx264" has to match in order to be able to build packages with it. We currently don't force having libx264 and lib32-libx264 to have the same API version because this is only an issue when building packages, not in using the package/library itself. Forcing the same version leads to problems when running "pacman -Syu" (you have to note down the conflicts and then run "pacman -Sud"; ignoring version conflicts; fixing the conflict afterwards). However, the problem comes up very often. We might force the same API version in the future.

shamanmonkey commented on 2015-07-24 14:15 (UTC)

Hi, just a heads up. I had a failure to build for this package due to lib32-libx264 being missing, despite all dependencies being satisfied. It turns out that I had lib32-libx264-stable-git installed which of course provides lib32-libx264. However, this version must not be compatible. So if anyone else is having trouble building this, then the solution is of course to install the package lib32-libx264. You may want to add lib32-libx264>=148.20150717-3 (current aur version) or something similar to the dependency list to avoid confusion in the future. Thanks!

JonnyJD commented on 2015-07-21 20:10 (UTC)

Updated to 2.7.2 and enabled libwebp. lib32-ffmpeg now also includes ".so" provides for all libraries, which are converted to (32 bit) versioned dependencies for the binary package when used (unversioned) as depends for the PKGBUILD. We also have versioned depends for libx264 and libvorbis in the binary package now. So you have to pacman might give a conflict when one of these package raises the so version. This is rare for libvorbis, but can happen multiple times every year for libx264. However, libx264 is also in the AUR. The suggested workflow is: Try "pacman -Syu" as normal and note down any version conflicts. Use "pacman -Sud" to ignore the version conflicts (for now). Re-build all AUR packages with conflicts. Note that rebuilding is usually enough. It is not necessary that the PKGBUILD gets udated. You might have to use "makepkg -f" though. (In the AUR the pkgrel doesn't get pushed on rebuild when there are no changes in the PKGBUILD.) Yes, this is a bit of a hassle, but there is no point in having packages break silently.

JonnyJD commented on 2015-06-24 09:09 (UTC)

@Det: I opened an issue to make more sense of what keywords should actually do: https://bugs.archlinux.org/task/45447

« First ‹ Previous 1 .. 15 16 17 18 19 20 21 Next › Last »