Package Details: lib32-libffmpeg 2:5.0.1-2

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: GPL3
Provides: lib32-ffmpeg, libavcodec.so, libavdevice.so, libavfilter.so, libavformat.so, libavutil.so, libpostproc.so, libswresample.so, libswscale.so
Submitter: lano1106
Maintainer: oxalin
Last Packager: oxalin
Votes: 37
Popularity: 0.25
First Submitted: 2013-05-18 04:43 (UTC)
Last Updated: 2022-06-14 12:51 (UTC)

Required by (153)

Sources (3)

Pinned Comments

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

MarsSeed commented on 2022-06-14 20:45 (UTC) (edited on 2022-06-14 20:45 (UTC) by MarsSeed)

No problem at all, my friend :)

But why don't you just define this?

source=("git+https://git.ffmpeg.org/ffmpeg.git#tag=n${pkgver}"

That way, you'll never have to know the commit hash of each tag, and you'll just need to edit the pkgver field.

Using the hash of the tags makes the process more error prone - I don't blame you! :) My aim was to suggest an easier and more maintainer-friendly solution. :)

oxalin commented on 2022-06-14 12:49 (UTC)

@MarsSeed: Well, I've mixed up things yesterday in the PKGBUILD. I was not thinking straight it seems or I had my eyes crossed. The good version should be in in a few minutes.

MarsSeed commented on 2022-06-14 06:29 (UTC) (edited on 2022-06-14 06:30 (UTC) by MarsSeed)

The _tag should be n5.0.1, not 9687cae2b468e09e35df4cea92cc2e6a0e6c93b3. :)

rodrigo21 commented on 2022-06-14 04:50 (UTC)

@oxalin

I think you forgot to update the _tag to 9687cae2b468e09e35df4cea92cc2e6a0e6c93b3

sgt-hartman commented on 2022-05-04 18:00 (UTC) (edited on 2022-05-04 18:01 (UTC) by sgt-hartman)

@oxalin

Ok so i solved the issue by installing "clang" package. Seems it is required as a makedepend (instead of lib32-clang maybe ?)

@oxalin @tomato I think the issue does not occur for you because you already have installed (manually) "clang" package in your system.

sgt-hartman commented on 2022-05-04 17:27 (UTC)

@oxalin

Sorry for delay (i didn't received mail notification..).

Some points:

  • I looked at your patch but it is old (feb. 2021). It is already merged in current version of this AUR package. Nothing to patch here

  • I don't have any Nvidia hardware, just a simple Intel Iris Xe based laptop.

  • The issue remains as of today

This issue is pretty annoying because this package is a dependency for many others.

Hope it helps.

oxalin commented on 2022-03-29 18:25 (UTC)

@sgt-hartman and @Tomato: is patching the source code with https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/52cc323735ced6e8095cfd3acea0e36e35c76eb2 helps?

Tomato commented on 2022-03-28 23:44 (UTC)

I'm getting the ERROR: cuda_llvm requested but not found error too. What's weird is that I'm getting it only when I try to build in a clean chroot (with makechrootpkg -r $CHROOT -I ../lib32-aom/lib32-aom..., but NOT when I build it in my regular OS using yay

oxalin commented on 2022-03-07 00:51 (UTC)

@npfeiler : as it is done for many lib32 packages, there is a dependency on the native package. Mostly, the header files are provided by the native package (64 bit), so if any other lib32 package needs to be built with a dependency on {lib32-}ffmpeg, it needs to have access to the header files.

Other distros sometime provide a specific package for header files (identified by a "-dev" at the end of the package's name), but it is not the way of Arch.

npfeiler commented on 2022-02-20 14:08 (UTC)

I couldn’t figure out what exactly in this package has a dependency on 64 bit ffmpeg, does anyone know?

oxalin commented on 2022-02-19 19:09 (UTC)

@sgt-hartman : I can't seem to reproduce the build error, but I don't have an NVidia gpu. Could you apply the suggested patch and let me know if this helps you? https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/52cc323735ced6e8095cfd3acea0e36e35c76eb2

oxalin commented on 2022-02-19 18:57 (UTC) (edited on 2022-03-29 18:26 (UTC) by oxalin)

@MarsSeed : it seems ffmpeg 4.4 will be temporary, since it is being used by only a few packages that were not updated to use ffmpeg 5.0.

@sgt-hartman : makedependencies and dependencies are (should unless I missed one) be the same as the native package. cuda_llvm should be handled by Clang to the best of my knowledge. I have no personal use of CUDA, but googling the error brought a recent commit that could/should fix it: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/52cc323735ced6e8095cfd3acea0e36e35c76eb2

I'll install the needed optional dependencies to try to trigger the build error and then apply the patch.

sgt-hartman commented on 2022-02-19 10:49 (UTC)

I've the following error trying to install lib32-ffmpeg 2:5.0-2: "ERROR: cuda_llvm requested but not found"

Full log:

==> Retrieving sources...
  -> Cloning ffmpeg git repo...
Cloning into bare repository '/home/ben/.cache/yay/lib32-ffmpeg/ffmpeg'...
100   131  100   131    0     0    478      0 --:--:-- --:--:-- --:--:--   479
100 1886k    0 1886k    0     0  2469k      0 --:--:-- --:--:-- --:--:-- 4824k
==> Validating source files with sha256sums...
    1.3.2.tar.gz ... Passed
remote: Enumerating objects: 26685, done.
remote: Counting objects: 100% (26685/26685), done.
remote: Compressing objects: 100% (12726/12726), done.
remote: Total 653169 (delta 21371), reused 16926 (delta 13942)
Receiving objects: 100% (653169/653169), 161.77 MiB | 23.75 MiB/s, done.
Resolving deltas: 100% (525264/525264), done.
  -> Found ffmpeg-vmaf2.x.patch
  -> Found add-av_stream_get_first_dts-for-chromium.patch
==> Validating source files with b2sums...
    ffmpeg ... Skipped
    ffmpeg-vmaf2.x.patch ... Passed
    add-av_stream_get_first_dts-for-chromium.patch ... Passed
 -> amf-headers not satisfied, flushing install queue
==> Making package: lib32-ffmpeg 2:5.0-2 (Sat 19 Feb 2022 11:45:12 AM CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Updating ffmpeg git repo...
Fetching origin
  -> Found ffmpeg-vmaf2.x.patch
  -> Found add-av_stream_get_first_dts-for-chromium.patch
==> Validating source files with b2sums...
    ffmpeg ... Skipped
    ffmpeg-vmaf2.x.patch ... Passed
    add-av_stream_get_first_dts-for-chromium.patch ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Creating working copy of ffmpeg git repo...
Cloning into 'ffmpeg'...
done.
Switched to a new branch 'makepkg'
==> Starting prepare()...
Auto-merging libavcodec/nvenc.c
Auto-merging libavcodec/nvenc.h
patching file configure
Hunk #1 succeeded at 3747 (offset -4 lines).
Hunk #2 succeeded at 6615 (offset -11 lines).
patching file doc/filters.texi
patching file libavfilter/vf_libvmaf.c
patching file libavformat/avformat.h
Hunk #1 succeeded at 1115 (offset 105 lines).
patching file libavformat/utils.c
Hunk #1 succeeded at 92 with fuzz 1 (offset -29 lines).
==> Starting pkgver()...
==> Sources are ready.
==> Making package: lib32-ffmpeg 2:5.0-2 (Sat 19 Feb 2022 11:45:16 AM CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Starting pkgver()...
==> Starting build()...
ERROR: cuda_llvm requested but not found

If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat.
Include the log file "ffbuild/config.log" produced by configure as this will help
solve the problem.
==> ERROR: A failure occurred in build().
    Aborting...

MarsSeed commented on 2022-02-01 04:12 (UTC) (edited on 2022-02-01 04:13 (UTC) by MarsSeed)

It seems even upstream Arch is going to keep ffmpeg 4.4 as a separate package alongside ffmpeg 5.0.

oxalin commented on 2022-01-27 21:55 (UTC)

I'll be updating the package to 5.0 directly once the native package will be available.

misharash commented on 2022-01-05 10:22 (UTC) (edited on 2022-01-05 11:00 (UTC) by misharash)

While building another package (lib32-chromaprint), I was getting the following critical issues:

/usr/bin/ld: warning: libvpx.so.6, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib32/libavcodec.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libx264.so.161, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib32/libavcodec.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib32/libavcodec.so: undefined reference to `vpx_codec_decode'

Solved by reinstalling lib32-libffmpeg. I wonder if there is any way to rebuild package automatically after its dependency libs are updated?

Rojikku commented on 2021-06-02 21:12 (UTC)

@oxalin

So, looked into it, that is decidedly not the issue. My problem I presume ended up being that I built lib32-x265 using aurto, which should chroot. And something must be wrong with their build process, because my PKG_CONFIG_DIR didn't contain x265.pc, which was needed for this process.

The logs did not indicate this, I just discovered it when I went looking for it after it was mentioned. Logs indicated it was found. (I got help in the IRC)

I will complain on lib32-x265, but the issue was solved by just doing a makepkg -sri of that package manually.

oxalin commented on 2021-06-02 04:53 (UTC) (edited on 2021-06-02 04:56 (UTC) by oxalin)

@Rojikku : could it be that your lib32-x265 and your x265 packages are of different versions? The error is usually misleading and pretty useless, but I've seen it before with x265 where the header files (part of x265 package) are from a different version than lib32-x265.

You'll find a trace in one of the log file from the build. Look at MarsSeed's comment from 2021-03-28 about build log src/ffmpeg/ffbuild/config.log

Rojikku commented on 2021-06-02 01:19 (UTC)

==> Starting build()...
ERROR: x265 not found using pkg-config

For the love of god, why. I've been trying to compile lib32-gst-plugins-bad for like four hours.

I just want to sleep.

I can fix this by hacking the PKGBUILD with some random comments and making the configure script immutable after commenting out the part that allows it to error.

But then I get a very similar error from lib32-gst-plugins-bad so it's moot point. I don't even know if this compiled with x265 support or not.

I tried reading the configure script, and I think it relies on this:

pkg-config --exists --print-errors x265 

Which actually seems to return true perfectly fine on my system, which I confirmed about 50 times in a row before doing a list--all | grep x265 and confirming it's there too.

What do you want from me, ./configure? I even guaranteed I'm not doing it wrong by trying x266 and x267, both of which obviously error.

Please, if anyone knows, tell me. I'm going to crash in bed. This is driving me mad.

oxalin commented on 2021-04-11 04:24 (UTC)

@MarsSeed: yes, I've discovered that around the same time you were commenting here. I was relying on an example from ArchLinux' wiki, but without any mention about the epoch. Thanks for notifying me.

I know ffmpeg 4.4 is now available, but I have to wait until ffmpeg package is updated before pushing the appropriate commit. Stay tuned.

ukbeast commented on 2021-04-09 11:22 (UTC)

@Patola

The PKGBUILD requires git to build properly. https://aur.archlinux.org/packages/lib32-x265/

You could try https://wiki.archlinux.org/index.php/unofficial_user_repositories#archlinuxcn for prebuilt aur binaries. Trusting a 3rd party repo is entirely up to you.

Patola commented on 2021-04-08 21:15 (UTC)

how do I get lib32-x265=3.4? Seems a game on Steam is not working due to the lack of lib32-gst-plugins-bad, which wont compile with lib32-x265=3.5.

MarsSeed commented on 2021-03-28 17:40 (UTC) (edited on 2021-03-28 18:03 (UTC) by MarsSeed)

@oxalin: Small note, as I've just realised by trying to upgrade only lib32-ffmpeg without also upgrading x264 and x265:

In PKGBUILD's depends version constraint,

depends=('lib32-x264>=0.161')

does not enforce lib32-x264=3:0.160.r3011.cde9a93-4 to be upgraded to 3:0.161.r3039.544c61f-1.

Reason is: because of the epoch value of 3, any 3:V (V: version string) will be higher than 0.160 because the latter is considered as 0:0.160.

You should try to declare your intended version constraint like below:

depends=('lib32-x264>=3:0.161')

MarsSeed commented on 2021-03-28 16:46 (UTC) (edited on 2021-03-28 16:49 (UTC) by MarsSeed)

@oxalin You wrote:

"As a matter of fact, the native ffmpeg package
doesn't have a version check on these dependencies."

The package might not have that check, but the build config of ffmpeg does have it in case of checking x265 in /usr/lib32:

Quote from my previous build log src/ffmpeg/ffbuild/config.log below (check the command line parameters calling the tests: -L/usr/lib32).

check_func_headers x265.h x265_api_get -L/usr/lib32 -lx265
test_ld cc -L/usr/lib32 -lx265
test_cc -L/usr/lib32
BEGIN /tmp/ffconf.WwFZr5sp/test.c
    1   #include <x265.h>
    2   #include <stdint.h>
    3   long check_x265_api_get(void) { return (long) x265_api_get; }
    4   int main(void) { int ret = 0;
    5    ret |= ((intptr_t)check_x265_api_get) & 0xFFFF;
    6   return ret; }
END /tmp/ffconf.WwFZr5sp/test.c
gcc -m32 -D_FORTIFY_SOURCE=2 -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -march=native -O2 -pipe -fstack-protector-strong -fno-plt -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-traditional -Wno-unused-but-set-variable -std=c11 -fomit-frame-pointer -fPIC -pthread -I/usr/include/p11-kit-1 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/fribidi -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/fribidi -I/usr/include/libmodplug/ -I/usr/include/openjpeg-2.4 -I/usr/include/opus -I/usr/include/opus -D_REENTRANT -I/usr/include/srt -I/usr/include/libvmaf -DX264_API_IMPORTS -L/usr/lib32 -c -o /tmp/ffconf.WwFZr5sp/test.o /tmp/ffconf.WwFZr5sp/test.c
gcc -m32 -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,--as-needed -Wl,-z,noexecstack -L/usr/lib32 -o /tmp/ffconf.WwFZr5sp/test /tmp/ffconf.WwFZr5sp/test.o -lx265
/usr/bin/ld: /tmp/ffconf.WwFZr5sp/test.o: in function `check_x265_api_get':
test.c:(.text+0xc): undefined reference to `x265_api_get_192'
collect2: error: ld returned 1 exit status
ERROR: x265 not found using pkg-config

MarsSeed commented on 2021-03-28 16:38 (UTC) (edited on 2021-03-28 16:40 (UTC) by MarsSeed)

@oxalin: You wrote:

"I specifically updated lib32-x265 and lib32-x264 in par to the
native packages prior to updating lib32-ffmpeg's PKGBUILD and
I cleaned out lib32-ffmpeg's build folder to be sure."

-- I will try to do the same, in that order again. (Though that order was the one that I did it the first time and which caused the build-time failures for my lib32-libffmpeg package.)

I suspect that the other way around would be workable though -- first installing the older x264 and x265, then installing the latest lib32-libffmpeg, then upgrading x264 and x265.

MarsSeed commented on 2021-03-28 16:25 (UTC) (edited on 2021-03-28 16:55 (UTC) by MarsSeed)

@oxalin: Thank you for checking this issue. I've started to have my doubts when I saw that Arch maintainers were able to rebuild the x86_64 version of ffmpeg v4.3.2 against the newer versions of x264 and x265, seemingly without any adaptations on their part.

I will try to do a full rebuild of lib32 versions from AUR PKGBUILDs after making sure I removed the previous versions and cleaned my caches. I use ccache so I will double-check to make sure I cleaned that as well.

Meanwhile I realized that it might be harder to maintain version checks in AUR PKGBUILDs than what binary repo maintainers can do. For each depends=(some_library.so) entry in the PKGBUILD, the makepkg will, during build time, check the installed library file version and hard-code that version in the package tarball - e.g., save it as depends=(some_library.so=1.1) in the .PKGINFO of the binary package.

This same strict locking might not always be viable here on AUR, even less so if dependencies are maintained by different people at different points in time. If a dependency's PKGBUILD does not manually declare provided library versions with something like provides=(somethings.so=1.1), then for the dependant (consumer) package, hard-coding the main pkg version of the dependency is the only other locking option. And that might just be unnecessarily strict and cause more installations to fail due to unsatisfied dependency versions.

I currently use yay, and that seems to not behave too well with strict dependency version locking, even when two or three interrelated AUR packages are selected to be installed as part of the same transaction.*

(*Note: yay can be configured to build all selected AUR packages first, and install them all at once at the end. This could help during install-time, if interrelated, version-locked package dependencies get installed the same time as the dependant (consumer) package. But in that case, if ffmpeg does indeed check already installed library versions in /usr/lib32, then it will have checked the wrong libraries, because they have not yet been updated.)

oxalin commented on 2021-03-28 16:05 (UTC)

@MarsSeed : Hi there. Just to let you know, I specifically updated lib32-x265 and lib32-x264 in par to the native packages prior to updating lib32-ffmpeg's PKGBUILD and I cleaned out lib32-ffmpeg's build folder to be sure.

Also, as another check, I re-installed lib32-ffmpeg from pacaur.

It seems you could either have a remnant of a previous lib32-ffmpeg build or your x265 | lib32-x265 and x264 | lib32-x264 were out of sync.

As a matter of fact, the native ffmpeg package doesn't have a version check on these dependencies. However, maintainers have to provide incremental updates each time the dependies are updated. It was updated a few days ago because of x265 and x264 updates.

What I can do and should have done though (forgot about them) is to update the dependencies' version. This would prevent building lib32-ffmpeg if there is a mismatch with dependies and force ffmpeg to update its configuration at build time. I'll be updating the PKGBUILD file right away.

MarsSeed commented on 2021-03-27 23:45 (UTC) (edited on 2021-03-28 08:33 (UTC) by MarsSeed)

Also in this version (v2:4.3.2-1), build fails if current lib32-x264=0.161 is installed. Build requires lib32-x264=0.160 to succeed.

More specifically, lib32-libffmpeg v2:4.3.2-1 requires libx264.so=160-32 provided by lib32-x264=0.160(.r3039.544c61f-1).

See build log excerpt:

/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_160'
collect2: error: ld returned 1 exit status
make: *** [Makefile:114: ffplay_g] Error 1
make: *** Waiting for unfinished jobs....
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_160'
collect2: error: ld returned 1 exit status
make: *** [Makefile:114: ffprobe_g] Error 1
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_160'
collect2: error: ld returned 1 exit status
make: *** [Makefile:114: ffmpeg_g] Error 1
==> ERROR: A failure occurred in build().
    Aborting...

MarsSeed commented on 2021-03-27 20:14 (UTC) (edited on 2021-03-28 08:36 (UTC) by MarsSeed)

Since the latest update (v2:4.3.2-1), build fails if lib32-x265=3.5 is installed. Build succeeds if lib32-x265=3.4 is installed instead.

A build config test expects the following result from the installed usr/lib32/libx265.so: 'x265_api_get_192'. The lib32-x265=3.4 provides libx265.so=192-32 whereas lib32-x265=3.5 provides libx265.so=199-32.

Log excerpt:

==> Making package: lib32-ffmpeg 2:4.3.2-1 (27 March 2021, 21:09:41 CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Removing existing $pkgdir/ directory...
==> Starting build()...
ERROR: x265 not found using pkg-config

If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
Include the log file "ffbuild/config.log" produced by configure as this will help
solve the problem.
==> ERROR: A failure occurred in build().
    Aborting...

From src/ffmpeg/ffbuild/config.log:

require_pkg_config libx265 x265 x265.h x265_api_get
check_pkg_config libx265 x265 x265.h x265_api_get
test_pkg_config libx265 x265 x265.h x265_api_get
pkg-config --exists --print-errors x265
check_func_headers x265.h x265_api_get -L/usr/lib32 -lx265
test_ld cc -L/usr/lib32 -lx265
test_cc -L/usr/lib32
BEGIN /tmp/ffconf.WwFZr5sp/test.c
    1   #include <x265.h>
    2   #include <stdint.h>
    3   long check_x265_api_get(void) { return (long) x265_api_get; }
    4   int main(void) { int ret = 0;
    5    ret |= ((intptr_t)check_x265_api_get) & 0xFFFF;
    6   return ret; }
END /tmp/ffconf.WwFZr5sp/test.c
gcc -m32 -D_FORTIFY_SOURCE=2 -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -march=native -O2 -pipe -fstack-protector-strong -fno-plt -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-traditional -Wno-unused-but-set-variable -std=c11 -fomit-frame-pointer -fPIC -pthread -I/usr/include/p11-kit-1 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/fribidi -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/fribidi -I/usr/include/libmodplug/ -I/usr/include/openjpeg-2.4 -I/usr/include/opus -I/usr/include/opus -D_REENTRANT -I/usr/include/srt -I/usr/include/libvmaf -DX264_API_IMPORTS -L/usr/lib32 -c -o /tmp/ffconf.WwFZr5sp/test.o /tmp/ffconf.WwFZr5sp/test.c
gcc -m32 -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,--as-needed -Wl,-z,noexecstack -L/usr/lib32 -o /tmp/ffconf.WwFZr5sp/test /tmp/ffconf.WwFZr5sp/test.o -lx265
/usr/bin/ld: /tmp/ffconf.WwFZr5sp/test.o: in function `check_x265_api_get':
test.c:(.text+0xc): undefined reference to `x265_api_get_192'
collect2: error: ld returned 1 exit status
ERROR: x265 not found using pkg-config

oxalin commented on 2021-01-08 19:13 (UTC)

@Cysioland : is it still a problem? Maybe you were in the middle of an update? Maybe lib32-openjpeg2 and openjpeg2 packages were not of the same version (this last option should now be fixed, I just pushed an update to lib32-openjpeg2)?

Cysioland commented on 2021-01-03 12:25 (UTC)

ERROR: libopenjp2 >= 2.1.0 not found using pkg-config

If you think configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the problem to the ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net. Include the log file "ffbuild/config.log" produced by configure as this will help solve the problem.

oxalin commented on 2020-09-30 05:37 (UTC)

@PedroHLC, as stated by DDoSolitary, 32-bit apps are not necessarily old or legacy. Let's take Valve's Steam as an example: the client and some games are running 32 bit code.

As long as there will be needs for some closed source apps, we will be stuck with 32 bit dependencies, even for recent apps.

That being said, I'm mostly mirroring the native package. I could offer a leaner package with less dependencies. However, since the native package offers some functionalities, some may expect them under 32 bit as well.

oxalin commented on 2020-09-28 14:55 (UTC)

There is an issue reported upstream with a commit fixing the issue. I'll update FFMPEG:

Upstream issue: https://trac.ffmpeg.org/ticket/8760

Patch / commit: https://git.videolan.org/?p=ffmpeg.git;a=patch;h=7c59e1b0f285cd7c7b35fcd71f49c5fd52cf9315

DDoSolitary commented on 2020-09-28 13:18 (UTC) (edited on 2020-09-28 13:18 (UTC) by DDoSolitary)

@PedroHLC I don't think it's good idea. While 32-bit binaries are dying out in normal Linux systems, they're still ubiquitous in many places and being 32-bit alone doesn't necessarily mean they're legacy or old-dated things. For example, a large number of modern Windows applications are still delivered as 32-bit binaries for compatibility reasons, and Wine needs these lib32-* packages to run these applications. Removing support for new formats is very likely to break these use cases.

PedroHLC commented on 2020-09-28 12:52 (UTC)

Not calling for any action, but in the future, this package may need some rethinking.

Like, we use lib32-* packages for "legacy" apps that weren't brought to the "x64" era.

Why would a so old-dated app need x265, av1, knows how to use nvenc, etc... These new formats increase dependencies and the frequency we need to rebuild this package. And these features play much nicer in your native arch.

What I mean is: at some point, I think it will be interesting to pick a year and feature freeze this package to that year's formats.

Lakso commented on 2020-09-26 17:20 (UTC) (edited on 2020-09-26 17:21 (UTC) by Lakso)

Can't build the package, returns error


libavformat/libsrt.c: In function ‘libsrt_set_options_pre’:
libavformat/libsrt.c:317:66: error: ‘SRTO_STRICTENC’ undeclared (first use in this function); did you mean ‘SRTO_STATE’?
  317 |         (s->enforced_encryption >= 0 && libsrt_setsockopt(h, fd, SRTO_STRICTENC, "SRTO_STRICTENC", &s->enforced_encryption, sizeof(s->enforced_encryption)) < 0) ||
      |                                                                  ^~~~~~~~~~~~~~
      |                                                                  SRTO_STATE
libavformat/libsrt.c:317:66: note: each undeclared identifier is reported only once for each function it appears in
libavformat/libsrt.c:336:50: error: ‘SRTO_SMOOTHER’ undeclared (first use in this function); did you mean ‘SRTO_SENDER’?
  336 |         (s->smoother && libsrt_setsockopt(h, fd, SRTO_SMOOTHER, "SRTO_SMOOTHER", s->smoother, strlen(s->smoother)) < 0) ||
      |                                                  ^~~~~~~~~~~~~
      |                                                  SRTO_SENDER
libavformat/libsrt.c: In function ‘libsrt_setup’:
libavformat/libsrt.c:409:5: warning: ‘srt_socket’ is deprecated [-Wdeprecated-declarations]
  409 |     fd = srt_socket(cur_ai->ai_family, cur_ai->ai_socktype, 0);
      |     ^~
In file included from libavformat/libsrt.c:24:
/usr/include/srt/srt.h:754:41: note: declared here
  754 | SRT_ATR_DEPRECATED_PX SRT_API SRTSOCKET srt_socket(int, int, int) SRT_ATR_DEPRECATED;
      |                                         ^~~~~~~~~~
make: *** [ffbuild/common.mak:59: libavformat/libsrt.o] Error 1
==> ERROR: A failure occurred in build().
    Aborting...

csts commented on 2020-08-17 16:33 (UTC)

Fixed with:

gpg --keyserver hkp://keys.gnupg.net --recv-keys 7FE6B095B582B0D4

gpg --keyserver hkp://keys.gnupg.net --recv-keys B4322F04D67658D8

csts commented on 2020-08-17 15:13 (UTC)

~ ❯❯❯ gpg --recv-keys 7FE6B095B582B0D4

gpg: keyserver receive failed: No name

~ ❯❯❯ gpg --search-keys 7FE6B095B582B0D4

gpg: error searching keyserver: No name

gpg: keyserver search failed: No name

~ ❯❯❯ gpg --recv-keys B4322F04D67658D8

gpg: keyserver receive failed: No name

~ ❯❯❯ gpg --search-keys B4322F04D67658D8

gpg: error searching keyserver: No name

gpg: keyserver search failed: No name

oxalin commented on 2020-08-15 02:50 (UTC)

@Samega7Cattac update x264 to version 0.160. I'll update the PKGBUILD file to enforce it.

Samega7Cattac commented on 2020-08-14 21:27 (UTC)

/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_160'
collect2: error: ld returned 1 exit status
make: *** [Makefile:114: ffmpeg_g] Error 1
make: *** Waiting for unfinished jobs....
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_160'
collect2: error: ld returned 1 exit status
make: *** [Makefile:114: ffplay_g] Error 1
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_160'
collect2: error: ld returned 1 exit status
make: *** [Makefile:114: ffprobe_g] Error 1

sl1pkn07 commented on 2020-07-15 19:11 (UTC)

Hi

why is splitted? this is arch, no ubuntu

greetings

inverimus commented on 2020-07-15 14:36 (UTC)

@oxalin I'm on Manjaro, so I think that is the issue. I had to match the 64 bit packages that were installed. Once those get updated it shouldn't be an issue anymore.

oxalin commented on 2020-07-14 02:52 (UTC)

@inverimus : I don't have any problem building with the x265 3.4 and aom 2.0. Without any log of your build process, I would be tempted to think that your system's arch packages (64 bit) were not updated to the same versions as your multilib packages (32 bit). Could you make sure both 32 amd 64 bit packages are at the same version before building lib32-ffmpeg packages?

PedroHLC commented on 2020-07-13 12:23 (UTC) (edited on 2020-07-13 12:24 (UTC) by PedroHLC)

Everything from packages_*'s depends must also be on makedepends, otherwise makepkg -s doesn't see all dependencies. You don't need to add extra depends or a global depends, just expose them in makedepends.

inverimus commented on 2020-07-12 15:18 (UTC) (edited on 2020-07-12 16:50 (UTC) by inverimus)

This still fails to build for me without manually reverting lib32-x265 to version 3.3. Not sure if anything can be done about that.

EDIT: Also had to downgrade lib32-aom to v1.0.0-errata1-avif.

oxalin commented on 2020-07-01 01:49 (UTC)

From ArchWiki (https://wiki.archlinux.org/index.php/PKGBUILD#Dependencies) "depends An array of packages that must be installed for the software to build and run. Dependencies defined inside the package() function are only required to run the software."

I'll need to move some dependencies outside of the package so they can be grabbed by "makepkg -s".

About lib32-x264: I had news from the ex-maintainer. It seems they were flagged as orphane almost a year ago. He has no explanation on why the package would have been deleted. I took the ownership and the package is now available once again.

oxalin commented on 2020-06-24 15:15 (UTC)

@DDoSolitary : is the error limited to lib32-ffmpeg or both? Maybe some dependencies (or all) need to be in the general section of PKGBUILD to be honored? I'll have a look at it.

As a follow up on the deletion of lib32-x264, I haven't heard back from the previous maintainer. So I'm considering reverting the package's deletion. I'm not sure if there is an official way of doing it (I'll ask on the mailing list).

DDoSolitary commented on 2020-06-24 11:49 (UTC)

I'm unable to build this package with makepkg -s -r in a clean environment. (In my case the missing lib32-x264 package isn't an issue for now because I've built it and uploaded it to my personal repo before)

Error message:

ERROR: gmp not found

It seems that the dependencies specified in the split package functions won't be installed automatically by makepkg -s. I'm not sure about what's the correct way of fixing this, but probably adding required build-time dependencies to makedepends will work.

oxalin commented on 2020-06-22 02:50 (UTC)

lib32-x264 dependency: I'm investigating why the package was deleted. There is no trace in aur-requests mailing list that could explain its deletion. I contacted the maintainer earlier today. I'll let you know as soon as possible. If needed, I'll recreate lib32-x264 package and maintain it.

oxalin commented on 2020-06-19 16:07 (UTC)

@programegg : that's annoying. I'll see what is going on with it. Last commit (when accessing its git repository) was June 6th 2020. I was able to retrieve the PKGBUILD if for any reason we need to recreate it.

That being said, this could be because the package is being moved elsewhere (multilib). So I'll wait a bit and come back later.

programegg commented on 2020-06-19 15:49 (UTC)

Impossible to build due to missing required package lib32-x264. AUR page for missing package appears to have been deleted.

oxalin commented on 2020-06-09 15:19 (UTC)

@Samega7Cattac : which version of aom and lib32-aom packages is installed?

Samega7Cattac commented on 2020-06-08 14:36 (UTC)

/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `aom_codec_control'
collect2: error: ld returned 1 exit status
make: *** [Makefile:111: ffmpeg_g] Error 1
make: *** Waiting for unfinished jobs....
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `aom_codec_control'
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `aom_codec_control'
collect2: error: ld returned 1 exit status
make: *** [Makefile:111: ffplay_g] Error 1
collect2: error: ld returned 1 exit status
make: *** [Makefile:111: ffprobe_g] Error 1
==> ERROR: A failure occurred in build().

Iglu47 commented on 2020-04-07 07:26 (UTC)

check that lib32-x265 has the same version as x265, else else it will give the error that ~pkg-conf not found x265

oxalin commented on 2019-08-30 19:00 (UTC)

@sl1pkn07 please, how did you come to that conclusion? I asked the same question in another package. Many lib32 packages, even officials, use the provide option without any problem with their native x64 counterparts. On my side, I don't have any drawback causes by the provides option.

sl1pkn07 commented on 2019-08-30 14:47 (UTC)

please remove libavcodec.so, libavdevice.so, libavfilter.so, libavformat.so, libavutil.so, libpostproc.so, libswresample.so, libswscale.so in provides. break ffmpeg package

Strunkenbold commented on 2019-07-20 08:16 (UTC)

@QuartzDragon

Thx for finding the issue. Unfortunately lib32-x265 is still at 3.0...

QuartzDragon commented on 2019-07-17 07:11 (UTC)

Turns out to have been caused by a version mismatch between the 64-bit and 32-bit x265 libraries. I use the testing repos, which supplies x265 3.1. lib32-x265 is 3.0. Upgrading lib32-x265 to 3.1 allowed lib32-ffmpeg to find the library.

lib32-ffmpeg is then seemingly using pkg-config to find the 64-bit x265 version, and derive the 32-bit version from that, so it's no wonder that lib32-ffmpeg couldn't find it...

oxalin commented on 2019-07-16 15:39 (UTC)

Well, everything seems fine. On my side, I removed lib32-x265 and lib32-ffmpeg before reinstalling them and everything went just fine. Could you delete your lib32-ffmpeg build folder in case it is keeping something wrong from a previous installation? It could be under ~/.cache/<yourselectedAURtool>/

QuartzDragon commented on 2019-07-16 14:49 (UTC)

Output is x265 x265 - H.265/HEVC video encoder and 3.0 respectively.

oxalin commented on 2019-07-16 14:45 (UTC)

@QuartzDragon : it seems right. Could you send me what is displayed by the following commands :

pkg-config-32 --list-all | grep x265 pkg-config-32 --modversion x265

QuartzDragon commented on 2019-07-16 00:21 (UTC)

Here we go. I'm using the vanilla x265.pc file

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib32
includedir=${prefix}/include

Name: x265
Description: H.265/HEVC video encoder
Version: 3.0
Libs: -L${libdir} -lx265
Libs.private: -lstdc++ -lm -lgcc_s -lgcc -lgcc_s -lgcc -lrt -ldl -lnuma
Cflags: -I${includedir}

oxalin commented on 2019-07-15 17:42 (UTC)

@QuartzDragon : Nothing was changed from previous version (4.1.3) on that matter. However, some changes were made to a previous version.

Is lib32-x265 installed? If so, is it up to date? lib32-x265 was not correctly setting up its .pc file until recently (when I proposed a fix). Could you share your x265.pc file (/usr/lib32/pkgconfig/x265.pc)?

QuartzDragon commented on 2019-07-14 09:57 (UTC)

Anyone else getting this error, even with the latest lib32-x265 installed?

==> Starting build()...
ERROR: x265 not found using pkg-config

If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
Include the log file "ffbuild/config.log" produced by configure as this will help
solve the problem.
==> ERROR: A failure occurred in build().
    Aborting...

oxalin commented on 2019-04-26 18:13 (UTC)

@QuartzDragon: no, I don't have any problem when rebuilding from scratch. Thanks for the cue about lib32-aom. I'm pushing an updated package right now.

QuartzDragon commented on 2019-04-24 07:58 (UTC)

Also, you can enable lib32-aom now, as it exists. :)

QuartzDragon commented on 2019-04-24 02:31 (UTC)

Does anyone else's build just hang forever trying to link:

LD libswresample/libswresample.so.3

oxalin commented on 2019-04-07 21:41 (UTC)

@mokkurkalve indeed, it still fails. lib32-x264 should be fixed to address the problem: pkgver was not properly updated as it should have.

mokkurkalve commented on 2019-04-03 14:21 (UTC)

The maintainer of lib32-x264 yesterday DID what you asked in your comment over there, he updated to revision 72db437770fd1ce3961f624dd57a8e75ff65ae0b. But by then you had updated lib32-ffmpeg to demand v 157, which he DID NOT update for.... So lib32-ffmpeg can still not be installed, it just throws: ==> Error: Could not find all required packages: lib32-x264>=157 (Wanted by: lib32-ffmpeg)

oxalin commented on 2019-04-01 18:18 (UTC)

@sl1pkn07 : you are right. I dropped it in 4.1.3.

sl1pkn07 commented on 2019-04-01 16:01 (UTC)

Hi

ffmpeg from [extra] not include libavresample (marked as deprecated by upstream). this package should do the same?

greetings

sl1pkn07 commented on 2019-03-04 15:22 (UTC)

ok, is problem of the lib32-x264. see the comments

sorry for the noise

oxalin commented on 2019-03-03 23:55 (UTC)

Hi sl1pkn07. While x264 is installed, you are probably not using the latest version for some reason... or it is not detected correctly. Are you using lib32-x264 package or is it a different package?

Make sure lib32-x246 is installed (or which ever equivalent AUR package you want to use). You can try to reinstall it and look for any problem when compiling it. If you hit something along this path, remove the lib32-x264 package folder so that it will download and build from a fresh folder on the next try.

You can try to do the same with lib32-ffmpeg: delete the lib32-ffmpeg build folder and start fresh.

Let me know if you need further assistance.

sl1pkn07 commented on 2019-03-03 16:53 (UTC)

Hi

i'm not sure why, but:

/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_155'
collect2: error: ld returned 1 exit status
make: *** [Makefile:108: ffplay_g] Error 1
make: *** Waiting for unfinished jobs....
MAN     doc/ffprobe-all.1
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_155'
collect2: error: ld returned 1 exit status
make: *** [Makefile:108: ffmpeg_g] Error 1
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_155'
collect2: error: ld returned 1 exit status
make: *** [Makefile:108: ffprobe_g] Error 1

in fresh lib32-ffmpeg (with dependencies) installation

oxalin commented on 2019-02-18 18:46 (UTC)

I know the package is out-of-date, I'm working on it (I was yesterday night). Something is not working correctly when building against x265 (lib32-x265). I have to see if the problem is caused by the out-of-date lib32-x265 package. I will update accordingly later today.

oxalin commented on 2018-12-14 05:23 (UTC)

Thank you PedroHLC for the missing makedepend on git.

PedroHLC commented on 2018-12-13 18:21 (UTC)

Please add git as a make dependency, it's required when building from clean chroot...

ljrk commented on 2018-10-14 11:31 (UTC)

Same error as here: https://aur.archlinux.org/packages/lib32-zbar/

libv4l2 0.14.2 has a bug as they didn't include sys/sysmacros.h, thus their calls to minor() got interepreted as functions rather than macros, resulting in an undefined reference. They fixed this in 0.16.0

oxalin commented on 2018-10-12 05:55 (UTC)

@cloverskull and @unknown78: you are right, something is wrong. I had no problem last time I modified the package at the end of August. I'll investigate this bug.

cloverskull commented on 2018-10-06 19:39 (UTC)

@oxalin I'm running into the same error about libv4l2 not being found.

I've confirmed all files you've asked about do exist on my filesystem.

$ pkg-config --libs /usr/lib32/pkgconfig/libv4l2.pc -L/usr/lib32 -lv4l2

Please advise, thanks!

oxalin commented on 2018-10-03 15:06 (UTC)

@unknown78: you should have lib32-v4l-utils (and v4l-utils) installed. It is a dependency which should be automatically detected if missing and added if needed.

Can you make sure you have usr/lib32/libv4l2.so and usr/lib/libv4l2.so installed? Also, do you have usr/lib32/pkgconfig/libv4l2.pc and usr/lib/pkgconfig/libv4l2.pc installed which should be used by pkg-config?

unknown78 commented on 2018-09-22 14:56 (UTC)

I get the following error. Can someone help?

ERROR: libv4l2 not found using pkg-config

oxalin commented on 2018-08-21 03:30 (UTC)

GordonGR: Thank you, I'll be updating lib32-ffmpeg package in a few minutes.

GordonGR commented on 2018-08-18 16:17 (UTC)

Just letting you know I created the package lib32-x264 as the equivalent to the renewed extra/x264 that replaced the extra/libx264* packages.

oxalin commented on 2018-06-16 15:16 (UTC)

Zaplo, could you post the error please? I'm not having any problem on my side.

zaplo commented on 2018-06-16 12:02 (UTC)

Build fails in my system, due to libavcodec/x86/vp9lpf_16bpp.asm. It finished succesfully after I compiled this file manually:

yasm vp9lpf_16bpp.asm -I ../../ -mx86 -felf32 -DARCH_X86_64=0 -DARCH_X86_32=1 -DHAVE_CPUNOP=1 -DHAVE_ALIGNED_STACK=1

oxalin commented on 2018-06-12 07:55 (UTC)

@ZIPS: I've asked GordonGR, maintainer of lib32-libx264, to remove the make-dependency against lib32-ffmpeg on his side. This should properly fix the circular dependency encountered recently.

ZIPS commented on 2018-06-03 18:35 (UTC) (edited on 2018-06-03 18:35 (UTC) by ZIPS)

Appear to have a bit of a loop going on as of the last update:

:: Package lib32-ffmpeg not found in repositories, trying AUR...

:: resolving dependencies...

tsort: -: input contains a loop:

tsort: lib32-ffmpeg

tsort: lib32-libx264

oxalin commented on 2018-04-17 05:48 (UTC)

@Enverex: There is no reason why you would need to specify the target OS unless the tools are unable to identify it by themselves. From the error reported in your 2018-04-10 comment, it seems you were encountering an error with AppKit, which you now specifically disable with the proposed modification. AppKit should be needed only under macOS, so the build tools are really identifying your system as such...

Using --pkgconfigdir option is pretty much the same as using PKG_CONFIG_PATH. However, "PKG_CONFIG_PATH is a environment variable that specifies additional paths in which pkg-config will search for its .pc files." Thus, it's a small differentiation between the environmental variable and the use of the option that should have no impact on the result.

When you say that you are now unable to build this package, which versions are you comparing: 3.4.2 against 3.4.1? Nothing special changed, we are mimicking pretty much exactly what is done under the x64/native package.

Could you delete lib32-ffmpeg folder under pacaur's cache (~/.cache/pacaur/lib32-ffmpeg) then reinstall lib32-ffmpeg? This will force to start from scratch and eliminate any problem that could have been related to a corrupted cache folder.

Enverex commented on 2018-04-16 10:57 (UTC)

Found the issue, you need to specify that this is being built for Linux. Something's causing it to build as MacOS now which obviously doesn't work. Adding the following to configure fixes it and also negates the need to export the PKG related variable too:

--target-os=linux --pkgconfigdir=/usr/lib32/pkgconfig --disable-appkit

Enverex commented on 2018-04-10 13:51 (UTC) (edited on 2018-04-12 15:17 (UTC) by Enverex)

Not sure if something's changed my side or whether another package has broken compatibility, but this suddenly won't build. Fails with "ERROR: gnutls not found using pkg-config". Both gnutls and lib32-gnutls are already installed. The actual error appears to be...

gcc -m32 -Wl,-O1,--sort-common,--as-needed,-z,relro -Wl,--as-needed -Wl,-z,noexecstack -I/usr/include/p11-kit-1 -L/usr/lib32 -o /tmp/ffconf.fgfxB5vm/test /tmp/ffconf.fgfxB5vm/test.o -lgnutls -framework AppKit

gcc: error: AppKit: No such file or directory

gcc: error: unrecognized command line option '-framework'

ERROR: gnutls not found using pkg-config

oxalin commented on 2018-03-06 06:04 (UTC)

Thanks for your test. I was about to ask to the lib32-libx264 (and also possibly the libx264) maintainer to have a look on his side. You give me a valid argument.

DarkPhoenixFF4 commented on 2018-03-05 00:12 (UTC)

Just to let you know, the problem seems to be with lib32-libx264, not this package. I removed the dependency on lib32-ffmpeg it had and built it manually with no problems.

oxalin commented on 2018-02-25 09:10 (UTC)

@TemplarGR and @SteelTitanium: well, there was a circular dependency that I read about, but it was from 2014. From your comments, I've been digging again and I found out yesterday that there is a new problem about a circular dependency. I'll investigate it further.

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

TemplarGR commented on 2018-02-24 12:30 (UTC)

There is an error when trying to build this package, it depends on lib32-libx264, yet lib32-libx264 depends on lib32-ffmpeg. I suppose someone who is just updating any of those 2 shouldn't face any issue, but anyone doing a fresh install will encounter this cyclical dependency. The fun part is that lib32-libx264 no longer shows up when searhing for it here (so i couldn't find its maintainer to ask), yet yaourt and packer find the pkgbuild...

oxalin commented on 2018-02-23 18:52 (UTC)

@SteelTitanium: you "can't". In fact, from what I have read on x264 forum, libx264 (the library itself) doesn't depend on ffmpeg. However, x264 have an optional dependency at build time against ffmpeg. Now, that being said, are you getting an error while trying to install the current package?

SteelTitanium commented on 2018-02-19 23:56 (UTC) (edited on 2018-02-19 23:57 (UTC) by SteelTitanium)

How do you break the dependency cycle, lib32-ffmpeg depends on lib32-libx264 and lib32-libx264 depends on lib32-ffmpeg.

oxalin commented on 2017-12-17 21:22 (UTC)

@unknown78: nothing changed since last version except version number and sha256sum.

The first step executed in the build() step is configure, which can take a moment to process. However, it should move to the next step, which is "make".

Could you restart your system and see if that helps if you didn't try it yet?

unknown78 commented on 2017-12-16 09:11 (UTC)

The last minor update seems to break something. makepkg -si output: LC_ALL=C makepkg ==> Making package: lib32-ffmpeg 1:3.4.1-1 (Sat Dec 16 10:08:16 CET 2017) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Downloading ffmpeg-3.4.1.tar.bz2... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 9938k 100 9938k 0 0 1419k 0 0:00:07 0:00:07 --:--:-- 1637k -> Downloading ffmpeg-3.4.1.tar.bz2.asc... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 473 100 473 0 0 473 0 0:00:01 --:--:-- 0:00:01 5255 ==> Validating source files with sha256sums... ffmpeg-3.4.1.tar.bz2 ... Passed ffmpeg-3.4.1.tar.bz2.asc ... Skipped ==> Verifying source file signatures with gpg... ffmpeg-3.4.1.tar.bz2 ... Passed ==> Extracting sources... -> Extracting ffmpeg-3.4.1.tar.bz2 with bsdtar ==> Starting build()...

and than nothing more happens.

oxalin commented on 2017-10-21 19:28 (UTC)

For info: The package will be updated to 3.4.0 in the next few days once I receive my new CPU (I had to have it replaced).

oxalin commented on 2017-08-15 14:54 (UTC)

@carstene1ns: thanks for the info, dependency removed. It will be fixed in the next release that should be made available in a few minutes.

carstene1ns commented on 2017-08-13 19:34 (UTC)

Using hardening-wrapper is deprecated: https://git.archlinux.org/svntogit/community.git/tree/trunk/hardening-wrapper.install?h=packages/hardening-wrapper

DungeonMaster commented on 2017-05-21 17:49 (UTC)

yes, it is a dependency of mpv-full-git. I simply uninstalled it long enough to upgrade lib32-ffmpeg and then reinstalled it. Thank you very much for the help.

oxalin commented on 2017-05-20 23:36 (UTC)

@DungeonMaster: after further research, sio_* are related to sndio. Is this package installed on your system or was it installed at some point?

oxalin commented on 2017-05-19 19:49 (UTC)

@DungeonMaster: after a quick search, I would be tempted to say that it is related to SDL2. However, you should already have the dependency installed... Any specific installation about that package on your side? Do you have SDL and SDL2 installed or just one of them? I have no problem over here and to my knowledge nothing changed about this dependency on FFMPEG's source code...

DungeonMaster commented on 2017-05-19 18:42 (UTC)

LD ffmpeg_g libavdevice/libavdevice.so: undefined reference to `sio_write' libavdevice/libavdevice.so: undefined reference to `sio_getpar' libavdevice/libavdevice.so: undefined reference to `sio_eof' libavdevice/libavdevice.so: undefined reference to `sio_onmove' libavdevice/libavdevice.so: undefined reference to `sio_close' libavdevice/libavdevice.so: undefined reference to `sio_start' libavdevice/libavdevice.so: undefined reference to `sio_open' libavdevice/libavdevice.so: undefined reference to `sio_read' libavdevice/libavdevice.so: undefined reference to `sio_setpar' libavdevice/libavdevice.so: undefined reference to `sio_initpar' collect2: error: ld returned 1 exit status make: *** [Makefile:136: ffmpeg_g] Error 1 Any idea what's going wrong?

oxalin commented on 2017-02-07 01:03 (UTC)

@cosiekvfj: ffmpeg-compat and lib32-ffmpeg-compat are a different packages. They are named "-compat" because they provide a fixed internal version (API/ABI versions). If you look in AUR, you may find more than one "ffmpeg-compat" package providing different versions. On the other hand, lib32-ffmpeg provides the latest ffmpeg version, mirroring the ffmpeg package. So (lib32-)ffmpeg and (lib32-)ffmpeg-compat will always differ and (lib32-)ffmpeg will never provide a previous version. Also, even if this is outside of the scope of the current package, you may consider moving away from steam runtime compat by installing steam-native-runtime, so you'll be able to use Archlinux's native runtime with Steam. Have a look at it.

cosiekvfj commented on 2017-02-05 23:28 (UTC)

For steam runtime compat you need lib32-ffmpeg-compat!

slyscorpion commented on 2017-01-08 06:07 (UTC)

@oxalin Have you taken a look at DistroWatch's RSS feed? They usually post an update to ffmpeg although I am not sure if it's possible to filter out notifications...

slyscorpion commented on 2017-01-08 06:04 (UTC)

@oxalin Thanks for the tip on the keys :)

oxalin commented on 2017-01-08 05:58 (UTC)

@slyscorpion: it is up to you to import the missing public key. This is ffmpeg's project public key. Something like the following should do the trick: gpg --keyserver x-hkp://pool.sks-keyservers.net --recv-keys B4322F04D67658D8 On another subject, I'm updating the package to 3.2.2. I still need to figure out a way to be notified from new releases automatically. The ffmpeg's RSS is unreliable.

slyscorpion commented on 2017-01-08 00:59 (UTC)

This package fails to build due to PGP signature issues: ==> Validating source files with sha256sums... ffmpeg-3.2.1.tar.bz2 ... Passed ffmpeg-3.2.1.tar.bz2.asc ... Skipped ==> Verifying source file signatures with gpg... ffmpeg-3.2.1.tar.bz2 ... FAILED (unknown public key B4322F04D67658D8) ==> ERROR: One or more PGP signatures could not be verified! ==> ERROR: Makepkg was unable to build lib32-ffmpeg.

oxalin commented on 2016-10-23 22:27 (UTC)

Thanks JonnyJD. Patch was first included, and then removed since the dev group released 3.1.5 which already includes the openjpeg2 patch. Sorry for the noise. To be noted: SDL support will be dropped in the next release in favor of SDL2. Stay tuned.

JonnyJD commented on 2016-10-23 11:45 (UTC)

Sorry, I don't have time to maintain the package, currently. I made oxalin the new maintainer (the notification mail is wrong, I disowned).

oxalin commented on 2016-10-21 19:25 (UTC)

@versusvoid It could be added, but that would be up to @JonnyJD to do.

versusvoid commented on 2016-09-22 05:21 (UTC)

@oxalin Adding lib32-openjpeg2 to `depends` also wouldn't be a bad thing.

oxalin commented on 2016-08-31 22:54 (UTC)

@Enverex, there is another (new) known bug about undefinded references to openjpegenc.o after a recent change in the static openjpeg2 library... Briefly, it comes to "The FFmpeg code was setting OPJ_STATIC, and in master, OPJ_STATIC sets API method visibility to hidden (because it is a static build, so visibility not needed)." See https://trac.ffmpeg.org/ticket/5694 The next ffmpeg release should contain the following fix: https://trac.ffmpeg.org/raw-attachment/ticket/5694/ffmpeg_opj2.patch @JonnyJD Meanwhile, maybe we would be better to add and apply that patch to the current package. Proposed patch to PKGBUILD --- diff --git a/PKGBUILD b/PKGBUILD index 00b74d4..a190490 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -35,14 +35,23 @@ provides=( 'libavresample.so' 'libavutil.so' 'libpostproc.so' 'libswresample.so' 'libswscale.so' ) -source=(http://ffmpeg.org/releases/$_pkgbasename-$pkgver.tar.bz2{,.asc}) +source=( + "http://ffmpeg.org/releases/$_pkgbasename-$pkgver.tar.bz2"{,.asc} + "https://trac.ffmpeg.org/raw-attachment/ticket/5694/ffmpeg_opj2.patch" +) validpgpkeys=('FCF986EA15E6E293A5644F10B4322F04D67658D8') -sha256sums=('58bc89c65dd114d874efbf76f76368d03b5e407f0a3f42d5b40801c280968a38' - 'SKIP') +sha256sums=( + '58bc89c65dd114d874efbf76f76368d03b5e407f0a3f42d5b40801c280968a38' + 'SKIP' + 'SKIP' +) build() { cd ${_pkgbasename}-${pkgver} + # Patching FFMPEG to compile againt a change in OpenJPEG2 static library until this patch is integrated in next release + patch -p1 < ../ffmpeg_opj2.patch + export PKG_CONFIG_PATH="/usr/lib32/pkgconfig" ./configure \ --- To fix building against libopenjpeg2, you need both the 32 bit library AND the patch (for now).

Enverex commented on 2016-08-16 13:23 (UTC)

@JonnyJD - Just an FYI, installing lib32-openjpeg2 doesn't fix lib32-ffmpeg failing to build (with the /usr/bin/ld: libavcodec/libavcodec.so.57: hidden symbol `opj_setup_decoder' isn't defined error). Removing openjpeg2 is the only way to have the build complete (doing an -Rdd then reinstalling it after this is built seems to be the easiest way to get around it).

mokkurkalve commented on 2016-08-15 12:57 (UTC)

Build fails for me thus: (....snip....) libavcodec/libopenjpegenc.o: In function `.L150': libopenjpegenc.c:(.text+0xe4e): undefined reference to `opj_set_info_handler' libopenjpegenc.c:(.text+0xe6e): undefined reference to `opj_setup_encoder' libopenjpegenc.c:(.text+0xed4): undefined reference to `opj_stream_default_create' libopenjpegenc.c:(.text+0xefd): undefined reference to `opj_stream_set_write_function' libopenjpegenc.c:(.text+0xf0c): undefined reference to `opj_stream_set_skip_function' libopenjpegenc.c:(.text+0xf1b): undefined reference to `opj_stream_set_seek_function' libopenjpegenc.c:(.text+0xf2b): undefined reference to `opj_stream_set_user_data' libopenjpegenc.c:(.text+0xf3c): undefined reference to `opj_start_compress' libopenjpegenc.c:(.text+0xf4d): undefined reference to `opj_encode' libopenjpegenc.c:(.text+0xfa4): undefined reference to `opj_end_compress' libavcodec/libopenjpegenc.o: In function `libopenjpeg_encode_close': libopenjpegenc.c:(.text.unlikely+0x1c): undefined reference to `opj_image_destroy' libavcodec/libopenjpegenc.o: In function `libopenjpeg_encode_init': libopenjpegenc.c:(.text.unlikely+0x6b): undefined reference to `opj_set_default_encoder_parameters' libopenjpegenc.c:(.text.unlikely+0x138): undefined reference to `opj_image_destroy' libopenjpegenc.c:(.text.unlikely+0x58c): undefined reference to `opj_image_create' /usr/bin/ld: libavcodec/libavcodec.so.57: hidden symbol `opj_setup_decoder' isn't defined /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status make: *** [library.mak:100: libavcodec/libavcodec.so.57] Error 1 make: *** Waiting for unfinished jobs.... ==> FEIL: En feil oppsto i build(). Avbryter...

zhenbo commented on 2016-08-06 04:58 (UTC)

As lib32-libvpx was updated and broke this dependency, I modified PKGBUILD to disable vpx support: https://paste.fedoraproject.org/402477/45942314/

zhenbo commented on 2016-08-06 04:40 (UTC)

$ yaourt -Sua lib32-ffmpeg error: failed to prepare transaction (could not satisfy dependencies) :: Starting full system upgrade... resolving dependencies... looking for conflicting packages... error: failed to prepare transaction (could not satisfy dependencies) :: lib32-ffmpeg: installing lib32-libvpx (1.6.0-2) breaks dependency 'libvpx.so=3-32' This package needs to be updated

RunasSudo commented on 2016-06-06 08:10 (UTC)

Can confirm that installing lib32-openjpeg2 fixes the issue described by remussatala.

JonnyJD commented on 2016-05-08 16:48 (UTC)

It looks like you have openjpeg2 installed and these include files are detected by configure, but you don't have https://aur.archlinux.org/packages/lib32-openjpeg2/ installed so linking fails. So in order to fix your build you either need to install lib32-openjpeg2 or remove openjpeg2. See also: https://trac.ffmpeg.org/ticket/5473

commented on 2016-05-01 15:47 (UTC)

libavcodec/vdpau.h:214:5: note: declared here int av_vdpau_get_profile(AVCodecContext *avctx, VdpDecoderProfile *profile); ^ LD ffmpeg_g libavcodec/libavcodec.so: undefined reference to `opj_stream_default_create' libavcodec/libavcodec.so: undefined reference to `opj_destroy_codec' libavcodec/libavcodec.so: undefined reference to `opj_read_header' libavcodec/libavcodec.so: undefined reference to `opj_end_compress' libavcodec/libavcodec.so: undefined reference to `opj_stream_destroy' libavcodec/libavcodec.so: undefined reference to `opj_stream_set_skip_function' libavcodec/libavcodec.so: undefined reference to `opj_stream_set_read_function' libavcodec/libavcodec.so: undefined reference to `opj_set_error_handler' libavcodec/libavcodec.so: undefined reference to `opj_stream_set_write_function' libavcodec/libavcodec.so: undefined reference to `opj_set_warning_handler' libavcodec/libavcodec.so: undefined reference to `opj_stream_set_user_data' libavcodec/libavcodec.so: undefined reference to `opj_start_compress' libavcodec/libavcodec.so: undefined reference to `opj_stream_set_user_data_length' libavcodec/libavcodec.so: undefined reference to `opj_set_info_handler' libavcodec/libavcodec.so: undefined reference to `opj_stream_set_seek_function' collect2: error: ld returned 1 exit status Makefile:128: recipe for target 'ffmpeg_g' failed make: *** [ffmpeg_g] Error 1

JonnyJD commented on 2016-04-30 12:54 (UTC)

Please don't flag outdated when you have build problems. Please also give the full error message. What you gave is generic and doesn't give me any info. It builds completely fine for me. I suspect a problem a problem with some dependency version, but I need more information. Use gist/pastebin whatever to post the full log if you don't know which message is the important one.

commented on 2016-04-30 12:51 (UTC)

collect2: error: ld returned 1 exit status Makefile:128: recipe for target 'ffmpeg_g' failed make: *** [ffmpeg_g] Error 1

JonnyJD commented on 2016-04-21 22:00 (UTC)

*potentially..

JonnyJD commented on 2016-04-21 21:59 (UTC)

Ah yes, there is a provides missing for lib32-libvpx. See https://bugs.archlinux.org/task/49043 You can just remove the libvpx.so from depends for now. Note that this potentically breaks (parts of) ffmpeg (without notification) when libvpx changes library version.

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

JonnyJD commented on 2015-06-23 22:17 (UTC)

Is there any documentation what the purpose of these keywords is? I this similar to a "tag" or only a "search hint"? I found this keyword on many packages, not sure who started this. Yes, it doesn't help finding the package with a search so it is useless as a "search hint". It does add a direkt link to a search for "lib32" and it would (theoretical) be possible to list only packages specifying the "lib32" keyward/tag.

Det commented on 2015-06-23 22:10 (UTC)

Why "lib32" as a keyword? It's already included in the name.

JonnyJD commented on 2015-06-23 13:03 (UTC)

FYI: lib32-libx264 is provided by https://aur4.archlinux.org/packages/lib32-libx264-stable-git/

JonnyJD commented on 2014-10-22 11:02 (UTC)

Okay, I adopted. Although I am also not a permanent user. I needed it for testing a 32 bit https://aur.archlinux.org/packages/essentia-acousticbrainz/ build. I fixed some more dependencies with the help of namcap. Should be alright now. I built without some features that are enabled in the 64 bit build. These are: libopencore_amrnb, libopencore_amrwb, libopenjpeg, libspeex, libvpx, libx265 Some don't have lib32 packages yet, some have other big dependencies (making it more difficult to build this package). The PKGBUILD is also versioned now in https://github.com/JonnyJD/PKGBUILDs/blob/master/lib32-ffmpeg/PKGBUILD (including the previous-maintainers version) I'll delete the gist. PS: lib32-libx264 was fixed to not depend on lib32-ffmpeg.

lano1106 commented on 2014-10-22 02:24 (UTC)

JonnyJD, very nice work! I do not need lib32-ffmpeg anymore hence I think someone else would make a better maintainer than myself. Please take the responsability if you feel up to the challenge! Have fun!

JonnyJD commented on 2014-10-21 17:49 (UTC)

FYI: It mostly works just updating the PKGBUILD with the current ffmpeg PKGBUILD (2.4.2). I only disabled some things where finding/building the dependencies wasn't easy. I update the depends for what I had to install additionally. There might be something missing, but I didn't want to add things that might not be needed. lib32-libx264 says it depends on lib32-ffmpeg. I doubt that. ffmpeg needs x264. The resulting PKGBUILD is here: https://gist.github.com/JonnyJD/da753b955f22524e1394

smls commented on 2014-08-25 14:29 (UTC)

Steam wants libavformat.so.55, but this package only provides the older libavformat.so.54

lano1106 commented on 2013-05-18 04:45 (UTC)

Very minimalist lib32 build of ffmpeg only containing AC3 encoder. I have done this slim build to be able to recompile lib32-alsa-plugins with a52 plugin to be able to get 5.1 sounds from steam.