Package Base Details: lib32-ffmpeg

Git Clone URL: https://aur.archlinux.org/lib32-ffmpeg.git (read-only, click to copy)
Submitter: lano1106
Maintainer: oxalin
Last Packager: oxalin
Votes: 31
Popularity: 0.94
First Submitted: 2013-05-18 04:43
Last Updated: 2021-04-02 19:58

Pinned Comments

oxalin commented on 2018-02-25 07:37

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 ... 7 8 9 10 11 12 13 Next › Last »

mokkurkalve commented on 2016-04-21 11:06

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

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

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

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

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

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

@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

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

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

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